如何使用 CrUX BigQuery 資料集

Chrome 使用者體驗報告 (CrUX) 的原始資料可在 Google Cloud 的 Google Cloud 資料庫 BigQuery 上取得。您需要有 GCP 專案以及 SQL 的基本知識,才能使用 BigQuery。

本指南將說明如何使用 BigQuery 針對 CrUX 資料集撰寫查詢,以便擷取有關網頁使用者體驗狀態的深入分析結果:

  • 瞭解資料的彙整方式
  • 撰寫用於評估來源效能的基本查詢
  • 撰寫進階查詢以追蹤長期成效

資料整理

請先查看基本查詢:

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

如要執行查詢,請在查詢編輯器中輸入該查詢,然後按下 [Run query] (執行查詢) 按鈕:

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

這項查詢包含兩個部分:

  • SELECT COUNT(DISTINCT origin) 表示查詢資料表中的來源數量。大致來說,如果兩個網址採用相同的通訊協定、主機和通訊埠,則屬於同一來源。

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

    • Cloud 專案名稱 chrome-ux-report,其中包含所有 CrUX 資料的資料
    • 資料集 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_paint (FCP)
    • dom_content_載入 (DCL)
    • onload (OL)
    • Experimental.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,表示在本來源上,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

在 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。換句話說,根據 FCP 範圍的定義,69.77% 的 web.dev 使用者體驗屬於「快速」。

追蹤成效

擷取來源成效資料後,我們可以將其與舊表格提供的歷來資料做比較。為此,我們可以將資料表位址改寫為更早的月份,或是使用萬用字元語法查詢所有月份:

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 說明文件