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 では、次の表で次のナビゲーション タイプを区別できます。
タイプ | 説明 |
---|---|
navigate |
他のどのカテゴリにも当てはまらないページの読み込み。 |
navigate_cache |
メインリソース(メインの HTML ドキュメント)が HTTP キャッシュから配信されたページ読み込み。多くのサイトはサブリソース用のキャッシュを利用しますが、多くの場合、メインの HTML ドキュメントのキャッシュ保存量はかなり少なくなっています。キャッシュ保存が可能な場合、ローカルや CDN でキャッシュに保存できるようになるため、パフォーマンスが大幅に向上する可能性があります。 |
reload |
ユーザーがページを再読み込みした(再読み込みボタンを押すか、アドレスバーの Enter キーを押すか、タブを閉じると元に戻った)。ページの再読み込みが行われると、メインページが変更されたかどうかを確認するために、サーバーに再検証が行われることがよくあります。ページの再読み込みの割合が高い場合は、ユーザーが不満を抱いている可能性があります。 |
restore |
ブラウザの再起動後、またはメモリ上の理由で削除されたタブの後に、ページが再読み込みされた。Android 版 Chrome では、代わりに reload として報告されます。 |
back_forward |
履歴ナビゲーション。ページが表示され、最近アクセスされたことを示します。適切なキャッシュがあれば、これらを適度に高速に処理できますが、ページの処理と JavaScript の実行が必要になりますが、bfcache によってこのどちらも回避されます。 |
back_forward_cache |
bfcache から配信された履歴ナビゲーション。bfcache を使用するようにページを最適化すると、エクスペリエンスが高速になります。サイトは、bfcache のブロッカーを排除して、このカテゴリのナビゲーションの割合を高める必要があります。 |
prerender |
ページが事前レンダリングされているため、bfcache と同様に、ページがほぼ瞬時に読み込まれる可能性があります。 |
場合によっては、ページの読み込みは複数のナビゲーション タイプの組み合わせになることがあります。その場合、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
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 ダッシュボードにアクセスできます。次のスクリーンショットからわかるように、最初は 1 か月分のデータしか利用できませんが、時間の経過とともに履歴が蓄積され、月ごとにタイプの変更を確認できます。
ご覧のとおり、ダッシュボードのこのページの上部に、サイト側で最適化する必要がある、より高速なナビゲーション タイプがハイライト表示されています。
おわりに
CrUX でのナビゲーション タイプの内訳が、サイトのパフォーマンスの理解と最適化のお役に立てば幸いです。HTTP キャッシュ、bfcache、事前レンダリングを効率的に使用することで、サイトはサーバーに戻る必要があるページ読み込みよりもはるかに速くページを読み込むことができます。
また、さまざまな CrUX アクセス ポイントでデータを利用できるようになり、ユーザーは思いどおりにデータを使用し、CrUX API で公開されているものを URL 別にタイプの内訳を確認できます。
CrUX への今回の追加について、ソーシャル メディアや CrUX ヘルプグループでフィードバックをお待ちしています。