本頁面由 Cloud Translation API 翻譯而成。

CrUX 現已提供導覽類型

Barry Pollard

Johannes Henkel

自 2024 年 3 月資料集起，Chrome 使用者體驗報告 (CrUX) 已加入 navigation_types 指標。這樣就能為所查詢維度的網頁載入類型提供匯總統計資料。

每種導覽類型都會導致成效指標上出現差異，因此在查看網站成效時，最好瞭解各類型網頁的相對頻率。舉例來說，瀏覽時使用後向 (bfcache) 瀏覽後通常能近乎即時的瀏覽體驗，這也反映在非常小的 LCP 和 FCP 指標上，並且減少 CLS 和 INP 指標。

透過公開導覽類型細目，我們希望鼓勵網站擁有者更深入瞭解其網站使用的導覽類型，並計劃查看快取設定、Bfcache 封鎖程式和預先算繪，鼓勵一些更快的類型。

navigation_types 指標適用於每日 CrUX API、CrUX History API (最初提供 3 週的記錄，未來 6 個月將逐步增加至所有涵蓋率)、最新的 CrUX BigQuery 資料集，以及 CrUX 資訊主頁。保留歷史記錄也能讓網站擁有者查看導覽類型在一段時間內的使用情況變化。藉此追蹤改善項目，例如移除 bfcache 封鎖。就算網站本身沒有修改，您也可以說明各項指標的變化。

CrUX 會在下表中區分下列導覽類型：

類型	說明
`navigate`	網頁載入，不符合任何其他類別。
`navigate_cache`	網頁載入後，主要資源 (主要 HTML 文件) 是從 HTTP 快取提供。網站通常會使用快取子資源，但主要 HTML 文件通常快取的快取次數可能大幅減少。如果可以，這項功能會讓本機和 CDN 快取效能明顯提升。
`reload`	使用者重新載入頁面，可能是按下重新載入按鈕、按下網址列的 Enter 鍵，或是復原關閉分頁。重新載入頁面後，系統通常會重新驗證伺服器，檢查主網頁是否變更。多次重新載入網頁可能代表使用者感到不悅。
`restore`	瀏覽器重新啟動後，頁面已重新載入，或是因記憶體不足而遭移除的分頁。如果是 Android 版 Chrome，則應用程式會回報為 `reload`。
`back_forward`	記錄瀏覽機制，也就是使用者查看過網頁並返回最近。透過正確的快取，這類體驗應可合理快速，但仍需處理網頁和執行 JavaScript (兩者都會避免使用)。
`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 日為止，最後有 6.77% 的瀏覽 (網頁載入) 來自瀏覽器的 bfcache。同樣地，部分其他分數也有助於找出網頁載入最佳化的機會。請注意，對於任何特定鍵 (包括網址或來源與板型規格的組合)，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 毫秒) 和網頁即時載入的頻率 (good_lcp_density 定義為 LCP <= 2500 毫秒) 的關聯性。我們觀察到 back_forward_cache 和 instant_lcp_density (有 0.87) 之間的統計相關性 (如下圖所示)，以及 back_forward_cache 和 good_lcp_density (縮放=0.29) 之間存在中度相關性。

關聯圖表，顯示立即載入網頁的比例和 bfcache 頁面載入速度之間的關係 — 從立即載入網頁到 bfcache 用量的相關關聯

可用於這項分析的 Colab 指標非常實用。以下我們僅討論從 CrUX BigQuery 詳細表格，擷取最熱門來源 1 萬個來源的導覽類型分數的查詢：

我們會存取這裡的 all.202403 表格 (請參閱 FROM 子句)，然後為 phone 篩選 form_factor，並針對最熱門的前 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 個，而非每個起點和每個日期的每部裝置最多新增 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 比率偏高，並非因為快取量減少，而是能反映出使用者在手機上往回瀏覽及轉寄更多內容。

CrUX 資訊主頁中的導覽類型

如要查看導覽類型，最簡單的方法是在 CrUX 資訊主頁中，都可以透過這個連結存取來源。從以下螢幕截圖中，我們一開始只提供一個月的資料，但一段時間後，記錄就會填滿每月各個類型的變動。

CrUX 資訊主頁中「Navigation Types Distribution」畫面的螢幕截圖，顯示一個月的資料。 — CrUX 資訊主頁中的導覽類型

如您所見，我們在這個資訊主頁的頂端特別標明瞭速度較快的導覽類型，建議供您改進。

結論

希望您覺得 CrUX 導覽類型細目可以派上用場，幫助您瞭解並改善網站成效。只要確保網站能有效使用 HTTP 快取、Bfcache 和預先算繪功能，網頁載入速度會比需要回到伺服器伺服器還要快。

此外，我們也很高興在所有 CrUX 存取點中提供資料，讓使用者可以按需求使用資料，並依網址查看 CrUX API 中公開資料的類型分析。

歡迎前往社群媒體或 CrUX 討論群組，分享有關 CrUX 這項新功能的意見回饋。