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 ではどのようなナビゲーション タイプを利用できますか？

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

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

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

CrUX は一般公開データセットであるため、レポートの粒度には制限があります。有効なトラフィックが不十分なため、多くのオリジンと URL では navigation_types 指標を利用できません。詳しくは、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 指標を積み上げ棒グラフとしてプロットします。

上のスクリーンショットでは、履歴は 3 つの収集期間（それぞれ 28 日間、7 日間）しか表示できません。データが入力されると、25 回の撮影期間がすべてカバーされます。この履歴を可視化することで、最適化が有効になったことや、最適化が元に戻ったことを確認できます。これは特に HTTP キャッシュの設定、bfcache と事前レンダリングにページを最適化する場合に当てはまります。

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

CrUX BigQuery テーブルに各タイプで構成された navigation_type レコードが含まれるようになり、サマリー マテリアライズド ビューには複数の navigation_types_* 列（タイプごとに 1 つずつ）が含まれるようになりました。

詳細なテーブル

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

一例として、back_forward_cache の割合と、ページが瞬時に読み込まれる頻度（instant_lcp_density を LCP <= 200 ms として定義）および良好な LCP が確認された頻度（good_lcp_density を LCP <= 2, 500 ms として定義）との相関を調べました。次のプロットに示すように、back_forward_cache と instant_lcp_density の間には強い統計的相関（rp=0.87）があり、back_forward_cache と good_lcp_density の間には中程度の相関関係があります（rp=0.29）。

この分析を行う Colab には十分なコメントが寄せられています。ここでは、CrUX BigQuery の詳細テーブルから、最も人気のある 10, 000 のオリジンの feedback_types の割合を抽出するクエリについてのみ説明します。

• ここで all.202403 テーブルにアクセスし（FROM 句を参照）、form_factor を phone でフィルタして、上位 10,000 の最も人気のあるオリジンの人気ランクが 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 行あたり 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 ダッシュボードを使用することです。こちらのリンクから、オリジンの CrUX ダッシュボードにアクセスできます。次のスクリーンショットからわかるように、最初は 1 か月分のデータしか利用できませんが、時間の経過とともに履歴が蓄積され、月ごとにタイプの変更を確認できます。

ご覧のとおり、ダッシュボードのこのページの上部に、サイト側で最適化する必要がある、より高速なナビゲーション タイプがハイライト表示されています。

おわりに

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

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

CrUX への今回の追加について、ソーシャル メディアや CrUX ヘルプグループでフィードバックをお待ちしています。