CrUX 現已提供導覽類型

Barry Pollard
Johannes Henkel
Johannes Henkel
X GitHub Mastodon

自 2024 年 3 月資料集起，Chrome 使用者體驗報告 (CrUX) 會提供 navigation_types 指標。取得所查詢維度中網頁載入導覽類型的匯總統計資料。

不同的導覽類型都會導致成效指標出現差異，因此查看網站成效時，最好先瞭解這幾種瀏覽方式的相對頻率。舉例來說，如果導覽使用向前 (bfcache)，通常會產生近乎即時的導覽，且會反映在極小的 LCP 和 FCP 指標中，並減少 CLS 和 INP 指標。

透過公開導覽類型細目，我們希望網站擁有者進一步瞭解自己網站上使用的導覽類型，並藉由查看快取設定、bfcache 攔截器和預先轉譯等方式，鼓勵加快一些速度的類型。

每日 CrUX API、CrUX History API (一開始提供 3 週記錄，接下來 6 個月內會逐週增加資料)、最新的 CrUX BigQuery 資料集和 CrUX 資訊主頁都有提供 navigation_types 指標。一旦擁有記錄，網站擁有者就能查看瀏覽類型使用隨時間的變化。有助於追蹤改善情形 (例如移除 bfcache 封鎖)。另外，即使未修改網站本身，這項工具也能解釋指標變化。

CrUX 區分如下的導覽類型：

類型 說明
navigate 網頁載入並不屬於任何其他類別。
navigate_cache 從 HTTP 快取提供主要資源 (主要 HTML 文件) 的網頁載入。網站通常會使用快取功能處理子資源，但主要的 HTML 文件通常快取較少。如果可以，就可能無法在本機和 CDN 快取，大幅改善效能。
reload 使用者透過以下方式重新載入網頁：按下重新載入按鈕、按下網址列中的 Enter 鍵，或是取消關閉分頁。網頁重新載入時，通常會重新驗證伺服器，確認主頁面是否有所變更。頁面重新載入的比例偏高，可能表示使用者感到不悅。
restore 網頁在瀏覽器重新啟動後重新載入，或是因為記憶體問題而遭到移除的分頁。如果是 Android 版 Chrome，則改為回報為 reload。
back_forward 瀏覽記錄，也就是使用者最近瀏覽過該網頁，然後返回查看的網頁。採用正確的快取後，這類體驗就能讓使用者體驗在合理且快速的情況下，但仍須讓網頁經過處理和執行 JavaScript，兩種 bfcache 都能避免。
back_forward_cache bfcache 提供的記錄導覽。將網頁最佳化以充分運用 bfcache ，可以帶來更快速的體驗。網站應移除 bfcache 攔截器，提高此類別導覽的比例。
prerender 網頁預先算繪類似 bfcache，這可能導致網頁近乎即時載入。

在某些情況下，網頁載入可以結合多種瀏覽類型。在這種情況下，CrUX 會以反向順序 (由下至上) 回報第一個相符項目。

CrUX 中導覽類型的限制

由於 CrUX 是公開資料集，因此報表精細程度有限。許多來源和網址的合格流量不足，因此無法使用 navigation_types 指標。詳情請參閱 CrUX 方法。

此外，CrUX 無法依瀏覽類型提供其他指標的細目，因為這樣會進一步減少 CrUX 中可用的來源和網址。

建議網站導入自己的即時使用者監控 (RUM)，以便依瀏覽類型等條件劃分流量。請注意，視回報的類型和包含哪些網頁瀏覽而定，這些解決方案中的導覽類型可能會有所差異，請參閱「為什麼 CrUX 資料與 RUM 資料不同？」一文。

RUM 還可以提供更詳細的特定效能問題詳細資訊。舉例來說，雖然 CrUX 可能表示提高 bfcache 資格條件是值得的，但 bfcache notRestoredReasons API 可以明確指出為何無法透過 bfcache 執行特定網頁的載入。

CrUX API 中的導覽類型

如要在 API 中查看導覽類型，請在要求中加入 navigation_types 指標，或者不設定指標來納入所有指標：

export API_KEY="[YOUR_API_KEY]"
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=$API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{"origin": "https://example.com", metrics: ["navigation_types"]}'

如要進一步瞭解申請格式，請參閱 API 說明文件，包括如何取得 API 金鑰的說明和 API 指南。這樣會傳回以下物件：

{
  "record": {
    "key": {  "origin": "https://example.com" },
    "metrics": {
      "navigation_types": {
        "fractions": {
          "navigate": 0.5335,
          "navigate_cache": 0.2646,
          "reload": 0.0885,
          "restore": 0.0023,
          "back_forward": 0.0403,
          "back_forward_cache": 0.0677,
          "prerender": 0.0031
        }
      }
    },
    "collectionPeriod": {
      "firstDate": { "year": 2024, "month": 3, "day": 6 },
      "lastDate": { "year": 2024, "month": 4, "day": 2 }
    }
  }
}

在回應中，CrUX 會將 navigation_types 指標回報為物件，針對各導覽類型載入的頁面片段。每個分數都是介於 0.0 (表示網頁載入的 0%) 到 1.0 之間的值 (表示網頁載入的 100%)。

透過此回應，您可以看到自 2024 年 3 月 6 日開始的收集期間，截至 2024 年 4 月 2 日為止，系統經由瀏覽器的 bfcache 提供 6.77% 的導覽 (載入網頁) 內容。同樣地，部分其他分數有助於找出網頁載入最佳化的機會。請注意，對於任何指定鍵 (包括網址/來源和板型規格的組合)，navigation_types 分數的加總結果會是大約 1.0。

CrUX History API 中的導覽類型

CrUX History API 可以為導覽類型提供時間序列，每個分數最多包含 25 個資料點，讓您隨著時間的推移以視覺化的方式呈現分數。如要將要求從 CrUX API 變更為 CrUX History API，請對 queryHistoryRecord 端點執行要求，而非 queryRecord。舉例來說，CrUX History Colab 會將 navigation_types 指標繪製成堆疊長條圖：

堆疊長條圖顯示過去 3 週以來的導覽類型記錄，且多數導覽為「導覽」而且在三週內沒有重大變更
歷來導覽類型

在上一張螢幕截圖中，系統僅提供 3 個集合期間 (每個 28 天，相隔 7 天) 的記錄。系統完全填入後，就會涵蓋全部 25 個收集時段。以圖表呈現此記錄，即可確認最佳化調整已生效或已迴歸。這對 HTTP 快取設定而言尤其重要，因為系統能為網頁進行 bfcache 和預先轉譯。

CrUX BigQuery 中的導覽類型

CrUX BigQuery 資料表現在包含每種類型的 navigation_type 記錄，摘要具體化檢視表則含有多個 navigation_types_* 資料欄 (每種類型各有一個資料欄)。

詳細資料表

CrUX BigQuery 中提供詳細的資料表結構定義，提供網站成效指標的詳細直方圖，可讓我們透過這個範例，瞭解特定導覽類型與即時載入效能/良好載入效能之間的關聯性。

舉例來說，我們觀察 back_forward_cache 分數及其與立即載入網頁的頻率 (instant_lcp_density 定義為 LCP <= 200 毫秒) 和發現良好 LCP 的頻率 (good_lcp_density 定義為 LCP <= 2500 毫秒) 之間的關聯性。我們觀察到 back_forward_cache 和 instant_lcp_density 之間具有顯著的統計關聯 (如以下圖表所示)，且 back_forward_cache 與 good_lcp_density 之間有中度相關性 (happy=0.29)。

「相關性」圖表顯示立即載入網頁與載入網頁時載入的比例 (bfcache 載入) 有明顯關聯
立即載入網頁與 bfcache 使用情況的關聯性

用於這項分析的 Colab 已經問得好。這裡，我們只會討論以下查詢，也就是從 CrUX BigQuery 的詳細資料表中擷取 Navigation_types 分數：

  • 我們在這裡存取 all.202403 資料表 (請參閱 FROM 子句)，篩選 form_factor 代表 phone，並針對前 1 萬個最熱門的起點，選取熱門程度排名 <= 10000 的來源 (請參閱 WHERE 子句)。
  • 在 BigQuery 中查詢 navigation_types 指標時，請務必除以 navigation_types 分數的總和，因為系統只會計算每個來源的分數，而不是每個來源、板型規格的組合。
  • 並非所有來源都有 navigation_types，因此建議使用 SAVE_DIVIDE。
WITH tmp AS (
  SELECT
    origin,
    SUM(navigation_types.navigate.fraction) AS navigate,
    SUM(navigation_types.navigate_cache.fraction) AS navigate_cache,
    SUM(navigation_types.reload.fraction) AS reload,
    SUM(navigation_types.restore AS restore,
    SUM(navigation_types.back_forward.fraction) AS back_forward,
    SUM(navigation_types.back_forward_cache.fraction) AS back_forward_cache,
    SUM(navigation_types.prerender.fraction) AS prerender,
    SUM(navigation_types.navigate.fraction
      + navigation_types.navigate_cache.fraction
      + navigation_types.reload.fraction
      + navigation_types.restore.fraction
      + navigation_types.back_forward.fraction
      + navigation_types.back_forward_cache.fraction
      + navigation_types.prerender.fraction) AS total
  FROM
    `chrome-ux-report.all.202403`
  WHERE
    experimental.popularity.rank <= 10000 AND
    form_factor.name = 'phone'
  GROUP BY
    origin
)

SELECT
  origin,
  ROUND(SAFE_DIVIDE(navigate, total), 4) AS navigate,
  ROUND(SAFE_DIVIDE(navigate_cache, total), 4) AS navigate_cache,
  ROUND(SAFE_DIVIDE(reload, total), 4) AS reload,
  ROUND(SAFE_DIVIDE(restore, total), 4) AS restore,
  ROUND(SAFE_DIVIDE(back_forward, total), 4) AS back_forward,
  ROUND(SAFE_DIVIDE(back_forward_cache, total), 4) AS back_forward_cache,
  ROUND(SAFE_DIVIDE(prerender, total), 4) AS prerender
FROM
  tmp

具體化資料表

如果摘要已足夠，通常查詢具體化資料表通常較為耗時且成本較低。舉例來說，下列查詢會從 chrome-ux-report.materialized.device_summary 資料表擷取可用的 navigation_types 資料。這份表格依據月份、來源和裝置類型來彙整。

SELECT
  yyyymm,
  device,
  navigation_types_navigate,
  navigation_types_navigate_cache,
  navigation_types_reload,
  navigation_types_restore,
  navigation_types_back_forward,
  navigation_types_back_forward_cache,
  navigation_types_prerender
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://example.com' AND
  navigation_types_navigate IS NOT NULL
ORDER BY
  yyyymm DESC,
  device DESC

請注意，這些分數在每列加總不會等於 1.0，因此您必須將各分數除以要解譯的結果總和。

這是因為 chrome-ux-report.materialized.device_summary 中的 navigation_type 分數 (例如直方圖密度)，每個來源最多可加入 1.0 個值，而非每個來源和裝置的日期。這可讓您查看不同裝置的導航類型分佈情形：

SELECT
  device,
  navigation_types_back_forward
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202403
device navigation_types_back_forward
phone 0.0663
desktop 0.0179
tablet 0.0009

在這個查詢結果中，分數反映出來源 https://www.google.com 的網頁載入百分比：在載入的網頁中，有 6.63% 的網頁瀏覽類型是 back_forward、手機 1.79% 和 0.09%。

phone 上的back_forward百分比明顯較高，代表我們可以嘗試最佳化網頁載入，讓網頁可以透過 bfcache 放送。

不過，您也必須考量 bfcache 所處理的網頁載入百分比，也就是 bfcache 命中率。下列查詢指出，由於 >手機與電腦的當機率為 60%。

SELECT
  device,
  navigation_types_back_forward_cache /
    (navigation_types_back_forward + navigation_types_back_forward_cache)
    AS back_forward_cache_hit_rate
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202403
device back_forward_cache_hit_rate
phone 0.6239
desktop 0.6805
tablet 0.7353

因此，手機顯示的 back_forward 比率偏高，並非因為 bfCache 用量較低，而是反映使用者在手機上的返回及快轉方式。

如要查看導覽類型，最簡單的方法是前往 CrUX 資訊主頁，可從這個連結存取來源。在以下螢幕截圖中，雖然我們一開始只能提供一個月的資料，但隨著時間過去，資料調閱記錄會反映出每個月的類型變化。

CrUX 資訊主頁中的導覽類型發布畫面螢幕截圖，顯示一個月的資料。
CrUX 資訊主頁中的導覽類型

如您所見，我們在資訊主頁的頁面頂端醒目顯示的是速度較快的導覽類型，為了改善效能。

結論

希望 CrUX 中的導覽類型細目資料有幫助，希望能協助您瞭解並改善網站成效。只要確保能有效使用 HTTP 快取、bfcache 和預先算繪，網站載入速度會比需要帶回伺服器的網頁載入速度更快。

我們也很高興能在各種 CrUX 存取點中提供資料，讓使用者可以視需要使用資料，以及查看透過 CrUX API 公開的網址類型細分資料。

除了社群媒體或 CrUX 討論群組，歡迎針對這項 CrUX 新增的意見提供意見。