如何使用 CrUX BigQuery 資料集

Rick Viscomi

你可以在 BigQuery (Google Cloud 上的資料庫) 中取得 Chrome 使用者體驗報告 (CrUX) 的原始資料。使用 BigQuery 需具備 GCP 專案，且須對 SQL 有基本知識。

在本指南中，您將瞭解如何使用 BigQuery 撰寫查詢 CrUX 資料集，以擷取有關網路使用者體驗狀態的深入分析結果：

  • 瞭解資料整理方式
  • 編寫基本查詢來評估來源效能
  • 撰寫進階查詢來追蹤長期成效

資料整理

從基本查詢開始：

SELECT COUNT(DISTINCT origin) FROM `chrome-ux-report.all.202206`

如要執行查詢，請在查詢編輯器中輸入查詢內容，然後按下「執行查詢」按鈕：

在編輯器中輸入簡單的查詢，然後按下「執行」。

這項查詢包含兩個部分：

  • SELECT COUNT(DISTINCT origin) 是指查詢資料表中的起點數。大致來說，如果兩個網址的配置、主機和通訊埠都相同，這些網址就屬於相同來源。

  • FROM chrome-ux-report.all.202206 會指定來源資料表的地址，其中包含三個部分：

    • 包含所有 CrUX 資料的 Cloud 專案名稱 chrome-ux-report
    • 資料集 all，代表所有國家/地區的資料
    • 202206 表格，代表資料的年份和月份，格式為 YYYYMM

還有各個國家/地區的資料集。舉例來說，chrome-ux-report.country_ca.202206 只代表源自加拿大的使用者體驗資料。

每個資料集內都會有自 201710 年起每個月的資料表。系統會定期發布前一個月的新資料表。

資料表的結構 (也稱為「結構定義」) 包括：

  • 來源 (例如 origin = 'https://www.example.com')，代表該網站所有網頁的綜合使用者體驗分佈情形
  • 網頁載入當時的連線速度，例如 effective_connection_type.name = '4G'
  • 裝置類型，例如 form_factor.name = 'desktop'
  • 使用者體驗指標本身
    • first_ Paint (FP)
    • first_contentful_pag (FCP)
    • dom_content_load (DCL)
    • onload (OL)
    • 實驗.first_input_delay (FID)

每個指標的資料都會整理成物件陣列。在 JSON 標記法中，first_contentful_paint.histogram.bin 看起來與下列內容類似：

[
    {"start": 0, "end": 100, "density": 0.1234},
    {"start": 100, "end": 200, "density": 0.0123},
    ...
]

每個特徵分塊都包含開始和結束時間 (以毫秒為單位)，以及代表該時間範圍內使用者體驗百分比的密度。換句話說，就此假設來源、連線速度和裝置類型而言，有 12.34% 的 FCP 體驗不到 100 毫秒。所有特徵分塊密度的總和為 100%。

瀏覽 BigQuery 中的資料表結構。

評估成效

我們可以運用對資料表結構定義的瞭解，編寫擷取這項成效資料的查詢。

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

在 BigQuery 中查詢 CrUX FCP

結果為 0.01115，表示在 4G 和手機上，此來源有 1.115% 的使用者體驗介於 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

在 BigQuery 上加總 CrUX FCP

結果為 0.05355，也就是所有裝置和連線類型的 5.355%。我們可以稍微修改查詢，然後加總「快速」上所有特徵分塊的密度FCP 範圍介於 0 至 1000 毫秒：

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

在 BigQuery 上查詢快速的 FCP

得到了 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

在 BigQuery 上查詢 CrUX FCP 時間序列

由此可見，快速 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，而不是其他工具？

只有在 CrUX 資訊主頁和 PageSpeed Insights 等工具無法接收相同的資訊時，才需要使用 BigQuery。舉例來說，BigQuery 可讓您以有意義的方式切割資料，甚至能與 HTTP 封存等其他公開資料集彙整，執行一些進階資料採集。

使用 BigQuery 是否有任何限制？

是，最重要的限制是根據預設，使用者每月只能查詢 1 TB 的資料。除此之外，價格為每 TB $5 美元的標準費率。

可以在哪裡進一步瞭解 BigQuery？

詳情請參閱 BigQuery 說明文件。