CrUX で使用可能なナビゲーション タイプ

Barry Pollard

Johannes Henkel

Chrome ユーザー エクスペリエンス レポート（CrUX）には、2024 年 3 月のデータセットから navigation_types 指標が含まれています。これにより、クエリされたディメンションのページ読み込みのナビゲーション タイプに関する集計統計情報が提供されます。

ナビゲーション タイプによってパフォーマンス指標が異なるため、サイトのパフォーマンスを確認する際は、ナビゲーション タイプごとの相対的な表示頻度を把握しておくと役立ちます。たとえば、ナビゲーションで「戻る」（bfcache）を使用すると、通常はほぼ瞬時に移動し、非常に小さい LCP 指標と FCP 指標に反映され、CLS 指標と INP 指標が減少します。

ナビゲーション タイプの内訳を公開することで、サイト所有者がサイトで使用されているナビゲーション タイプについて理解を深め、キャッシュ設定、bfcache ブロッカー、事前レンダリングを確認して、より高速なタイプを奨励できるようにしたいと考えています。

navigation_types 指標は、毎日の CrUX API、CrUX History API（最初は 3 週間の履歴が利用可能で、今後 6 か月間は毎週、すべてのレポートに適用されます）、最新の CrUX BigQuery データセット、CrUX ダッシュボードで利用可能です。また、履歴があると、サイト所有者はナビゲーション タイプの使用状況の推移を確認することもできます。これにより、改善の追跡が可能になります（たとえば、bfcache のブロックを解除するなど）。また、サイトに変更を加えていないときでも、指標の変化について説明することができます。

CrUX にはどのようなナビゲーション タイプが用意されていますか？

CrUX では、次の表のナビゲーション タイプを区別しています。

場合によっては、複数のナビゲーション タイプの組み合わせがページ読み込みになることがあります。その場合、CrUX は上の表とは逆順（下から上）に最初の一致をレポートします。

CrUX のナビゲーション タイプの制限事項

CrUX は一般公開データセットであるため、レポートの粒度は限られています。多くのオリジンと URL では、適格なトラフィックが不十分なため、navigation_types 指標を使用できません。詳しくは、CrUX の手法をご覧ください。

また、CrUX で他の指標の内訳をナビゲーション タイプ別に表示することはできません。これは、CrUX で利用できるオリジンと URL の数がさらに減少するためです。

ナビゲーション タイプなどの条件でトラフィックを分割できるように、サイトに独自の Real User Monitoring（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 から配信されたことがわかります。同様に、その他の一部は、ページ読み込みを最適化できる部分を特定するのに役立ちます。任意のキー（URL またはオリジンとフォーム ファクタの組み合わせを含む）について、navigation_types の小数部分を合計すると約 1.0 になります。

CrUX History API のナビゲーション タイプ

CrUX History API では、比率ごとに最大 25 個のデータポイントを使用してナビゲーション タイプの時系列を提供できます。これにより、これらの比率を経時的に可視化できます。リクエストを CrUX API から CrUX History API に変更するには、queryRecord ではなく queryHistoryRecord エンドポイントに対して実行します。たとえば、CrUX History Colab では navigation_types 指標が積み上げ棒グラフでプロットされます。

</ph>

上のスクリーンショットでは、履歴は 3 つの収集期間（7 日間ごとに 28 日間）しか利用できません。すべてのデータを入力すると、25 回の収集期間すべてに対応することになります。この履歴を可視化することで、最適化が有効になったこと、または回帰したことを確認できます。これは、HTTP キャッシュ設定、ページの bfcache の最適化、事前レンダリングで特に当てはまります。

CrUX BigQuery のナビゲーション型

CrUX BigQuery テーブルには各型で構成された navigation_type レコードが含まれる一方、サマリー マテリアライズド ビューには複数の navigation_types_* 列（型ごとに 1 列）が含まれています。

詳細表

CrUX BigQuery の詳細なテーブル スキーマは、ウェブ パフォーマンス指標の詳細なヒストグラムを提供します。これにより、この例の分析では、特定のナビゲーション タイプが即時または良好な読み込みパフォーマンスとどのように関連しているのかを示すことができます。

例として、back_forward_cache の割合と、ページが即座に読み込まれる頻度（instant_lcp_density は LCP 200 ミリ秒以下）と、良好な LCP が確認された頻度（good_lcp_density は LCP 2, 500 ミリ秒以下）との相関を調べました。以下のプロットに示すように、back_forward_cache と instant_lcp_density の間には強い統計的相関関係（p=0.87）が観察され、back_forward_cache と good_lcp_density の間には中程度の相関関係が認められました（p=0.29）。

</ph>

この分析用の Colab には十分なコメントが付けられています。ここでは、CrUX BigQuery の詳細なテーブルから、最も人気のある 10, 000 のオリジンの navigation_types フラクションを抽出するクエリについてのみ説明します。

• ここで all.202403 テーブルにアクセスし（FROM 句を参照）、form_factor を phone でフィルタし、最も人気のある上位 10,000 オリジンの人気度の順位が 10,000 以下のオリジンを選択します（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 行あたり 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

このクエリ結果では、比率にオリジン 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

したがって、スマートフォンでの back_forward 率が高いのは、bfcache の使用が減っているためではなく、ユーザーがスマートフォンで前後に移動する様子を反映していると考えられます。

CrUX ダッシュボードのナビゲーション タイプ

ナビゲーション タイプを確認する最も簡単な方法は、CrUX ダッシュボードです。このダッシュボードには、こちらのリンクからオリジンにアクセスできます。次のスクリーンショットからわかるように、最初は 1 か月分のデータしか利用できませんが、時間の経過とともに履歴がいっぱいになり、月ごとにタイプの変化を確認できます。

</ph>

また、ダッシュボードのこのページの上部で、最適化すべき、より高速なナビゲーション タイプがハイライト表示されています。

まとめ

CrUX でのナビゲーション タイプの内訳が、サイトのパフォーマンスの理解と最適化にお役に立てば幸いです。HTTP キャッシュ、bfcache、事前レンダリングを効率的に使用することで、サイトはサーバーに戻る必要があるページの読み込みよりもはるかに速くページを読み込むことができます。

また、さまざまな CrUX アクセス ポイントでデータを利用できるようにしています。これにより、ユーザーは自由にデータを使用したり、CrUX API で公開されている URL ごとのタイプの内訳を確認したりできます。

CrUX への今回の追加について、ソーシャル メディアや CrUX ディスカッション グループでフィードバックをお寄せください。