Chrome UX レポート(CrUX)の元データは、Google Cloud 上のデータベースである BigQuery で入手できます。BigQuery を使用するには、GCP プロジェクトと SQL の基本的な知識が必要です。
このガイドでは、BigQuery を使用して CrUX データセットに対するクエリを作成し、ウェブ上のユーザー エクスペリエンスの状態について有益な結果を抽出する方法について説明します。
- データの整理方法を理解する
- 送信元のパフォーマンスを評価する基本的なクエリを作成する
- パフォーマンスの推移を追跡する高度なクエリを作成する
データ編成
まず、基本的なクエリを見てみましょう。
SELECT COUNT(DISTINCT origin) FROM `chrome-ux-report.all.202206`
クエリを実行するには、クエリエディタにクエリを入力し、[クエリを実行] ボタンをクリックします。
このクエリは 2 つの部分で構成されています。
SELECT COUNT(DISTINCT origin)
は、テーブル内のオリジンの数をクエリすることを意味します。大まかに言うと、2 つの URL が同じスキーム、ホスト、ポートを持つ場合、オリジンは同じになります。FROM chrome-ux-report.all.202206
は、次の 3 つの部分から構成されるソーステーブルのアドレスを指定します。- すべての CrUX データが編成される Cloud プロジェクト名
chrome-ux-report
- すべての国のデータを表す
all
データセット - テーブル
202206
。データの年と月(YYYYMM 形式)
- すべての CrUX データが編成される Cloud プロジェクト名
各国のデータセットもあります。たとえば、chrome-ux-report.country_ca.202206
はカナダで発生したユーザー エクスペリエンス データのみを表します。
各データセットには、2017 年以降の毎月のテーブルがあります 10。前月の新しいテーブルは定期的にパブリッシュされます。
データテーブルの構造(スキーマとも呼ばれます)には、次のものが含まれます。
- オリジン(例:
origin = 'https://www.example.com'
)。そのウェブサイトのすべてのページのユーザー エクスペリエンス分布の集計を表します。 - ページの読み込み時の接続速度(例:
effective_connection_type.name = '4G'
) - デバイスタイプ(例:
form_factor.name = 'desktop'
) - UX 指標自体
各指標のデータは、オブジェクトの配列として編成されます。JSON 表記では、first_contentful_paint.histogram.bin
は次のようになります。
[
{"start": 0, "end": 100, "density": 0.1234},
{"start": 100, "end": 200, "density": 0.0123},
...
]
各ビンには、ミリ秒単位の開始時間と終了時間、およびその時間範囲内のユーザー エクスペリエンスの割合を表す密度が含まれます。言い換えれば、この仮定の送信元、接続速度、デバイスタイプに対する FCP エクスペリエンスの 12.34% は 100 ms 未満です。すべてのビン密度の合計は 100% です。
パフォーマンスを評価する
テーブル スキーマの知識を活用して、このパフォーマンス データを抽出するクエリを作成できます。
SELECT
fcp
FROM
`chrome-ux-report.all.202206`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
effective_connection_type.name = '4G' AND
form_factor.name = 'phone' AND
fcp.start = 0
結果は 0.01115
になります。これは、このオリジンのユーザー エクスペリエンスの 1.115% が、4G とスマートフォンで 0 ~ 100 ミリ秒だったことを意味します。任意の接続やデバイスタイプに対してクエリを一般化したい場合は、WHERE
句からそれらを省略し、SUM
アグリゲータ関数を使用してそれぞれのビン密度を合計します。
SELECT
SUM(fcp.density)
FROM
`chrome-ux-report.all.202206`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
fcp.start = 0
結果は 0.05355
で、すべてのデバイスと接続タイプで 5.355% です。クエリを少し変更して、「fast」レベルにあるすべてのビンの密度を加算できます。0 ~ 1,000 ミリ秒の FCP 範囲:
SELECT
SUM(fcp.density) AS fast_fcp
FROM
`chrome-ux-report.all.202206`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
fcp.start < 1000
これにより、0.6977
が得られます。つまり、web.dev の FCP ユーザー エクスペリエンスの 69.77% は、FCP の範囲の定義に基づいて「高速」と見なされます。
パフォーマンスのトラッキング
オリジンに関するパフォーマンス データを抽出できたので、それを古いテーブルで利用可能な過去のデータと比較します。そのためには、テーブル アドレスを前の月に書き換えるか、ワイルドカード構文を使用してすべての月をクエリします。
SELECT
_TABLE_SUFFIX AS yyyymm,
SUM(fcp.density) AS fast_fcp
FROM
`chrome-ux-report.all.*`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
fcp.start < 1000
GROUP BY
yyyymm
ORDER BY
yyyymm DESC
この例では、高速な FCP エクスペリエンスの割合が毎月数パーセント ポイントの差で変化しています。
yyyymm | fast_fcp |
---|---|
202206 | 69.77% |
202205 | 70.71% |
202204 | 69.04% |
202203 | 69.82% |
202202 | 67.75% |
202201 | 58.96% |
202112 | 41.69% |
... | ... |
これらの手法により、オリジンのパフォーマンスを調べ、高速なエクスペリエンスの割合を計算して、それを経時的に追跡できます。次のステップとして、複数のオリジンに対してクエリを実行し、それらのパフォーマンスを比較してみましょう。
よくある質問
CrUX BigQuery データセットに関するよくある質問をいくつかご紹介します。
他のツールではなく BigQuery を使用する場合
BigQuery は、CrUX ダッシュボードや PageSpeed Insights などの他のツールから同じ情報を取得できない場合にのみ必要です。たとえば、BigQuery ではデータを意味のある方法でスライスしたり、HTTP Archive などの他の一般公開データセットと結合して高度なデータマイニングを行ったりできます。
BigQuery の使用に制限はありますか?
はい。最も重要な制限事項は、デフォルトではユーザーが 1 か月あたりクエリできるデータの量が 1 TB に制限されていることです。1 TB を超えると、1 TB あたり 5 米ドルの標準料金が適用されます。
BigQuery の詳細はどこで確認できますか?
詳細については、BigQuery のドキュメントをご覧ください。