Core/Dashディメンション： Navigation Type

ユーザーのページ到達方法でCore Web Vitalsをセグメント化し、bfcache、prerender、reloadのパフォーマンスをデバッグします。

無料トライアル

Trusted by market leaders · Client results

ディメンション：Navigation Type (nt)

CrUXデータにおけるすべてのページビューには、Navigation Typeが含まれています。これにより、ブラウザがページをどのように読み込んだかがわかります。これによって、ネットワークスタック、back/forward cache、prerenderパイプライン、セッション復元のうち、どのブラウザシステムが関与したかが決定されます。CoreDashはこれをntディメンションとして提供しているため、ナビゲーションコンテキストごとにCore Web Vitalsをフィルタリングして比較できます。

このデータは、PerformanceNavigationTiming API、特にtypeプロパティから取得されます。performance.getEntriesByType("navigation")[0].typeで取得できます。ChromeはCrUXに送信されるすべてのWeb Vitalsの測定値とともにこの値を報告します。CoreDashはこれを保存してインデックスを作成するため、カスタムの計測コードを書くことなくセグメント化を行えます。

coredash metric table urls

Navigation Typeが重要である理由

すべてのNavigation TypeにわたってLCPやINPを合算すると、技術的には正しくても、実態とは異なる数値になります。back/forward cacheのヒットは数ミリ秒で完了します。一方、コールドナビゲーションはDNS、TCP、TLS、およびTTFBを待ちます。セッションの20%がbfcacheヒットである場合、それらがp75 LCPを引き下げてしまうため、新規ナビゲーションにおける実際の問題が見えにくくなります。

逆もまた同様です。サイトでbfcacheが機能していない場合、back/forwardセッションのパフォーマンスは新規ナビゲーションと同じくらい悪化します。Navigation Typeでセグメント化しない限り、合算値は安定したまま推移するため、この問題に気づくことはできません。

Prerenderは最も顕著な例です。正しくprerenderされたページは、ユーザーがリンクをクリックする前にレンダリングが完了しているため、LCPはほぼゼロになるはずです。もしprerenderされたページのLCPが通常の数値を示しているなら、Speculation Rulesの設定が間違っており、prerenderが実行されていないか、使用される前に破棄されています。

Navigation Typeの種類

navigate

標準的なナビゲーションです。ユーザーがURLを入力した、別のサイトのリンクをクリックした、またはリダイレクトに従った場合が該当します。キャッシュによるショートカットのない、完全なページロードです。ブラウザは、DNSルックアップ、コネクション確立、すべてのリソース読み込みを含む、完全なリクエストパイプラインを実行します。CoreDashのデータでは、navigateがセッションの約65%を占めます。これがベースラインとなります。他のすべてのNavigation Typeは、navigateと比較して判断する必要があります。

reload

ユーザーがF5キーを押した、ブラウザの更新ボタンをクリックした、またはコードでlocation.reload()が呼び出された場合です。ブラウザはキャッシュされたリソースに対して再検証リクエストを送信するため、ユーザーが同じページにいるにもかかわらず、TTFBは通常のnavigateよりも悪化することがよくあります。もしreloadのTTFBがnavigateのTTFBよりも大幅に高い場合、キャッシュヘッダーが古いコンテンツを返す代わりに、リロードのたびに再検証をトリガーしている可能性があります。一般的なCoreDashのトラフィックでは、セッションの約10%がリロードです。

back_forward

ユーザーがブラウザの「戻る」または「進む」ボタンを押した場合です。back/forward cache（bfcache）が機能している場合、これは最も高速なNavigation Typeとなります。ブラウザはネットワークリクエストを一切行わず、メモリからページを復元します。bfcacheヒット時のLCPは、実質的にメモリからペイントする時間となるため、ほぼ瞬時に完了します。

もしback_forwardのメトリクスがnavigateと似たような数値になっているなら、bfcacheが機能していません。最も一般的な原因は、unloadイベントハンドラーの使用、レスポンスヘッダーのCache-Control: no-store、および遷移前にクローズされなかった未接続のIndexedDB接続です。CoreDashのデータでは、back/forwardはセッションの約20%を占めるため、これは改善効果の非常に高い修正項目です。

prerender

ユーザーがリンクをクリックする前に、Speculation Rules APIを使用してバックグラウンドでページが読み込まれていた場合です。ユーザーが実際にクリックすると、prerenderされたドキュメントが瞬時にアクティブ化されます。正しくアクティブ化されたprerenderのLCPは、ナビゲーションイベントの前にすべてのレンダリング処理が終了しているため、ほぼゼロになります。

もしprerenderのLCPが通常の数値と変わらない場合、次の3つのいずれかが発生しています：アクティブ化される前にprerenderが破棄された、Speculation Rulesの対象URLが間違っている、またはページでprerenderingを妨げるヘッダーやJavaScriptが使用されている。CoreDashのセッションにおけるprerenderのアクティブ化は約3%ですが、Speculation Rulesを導入すればこの割合は急速に増加します。

restore

ブラウザが閉じられた後、またはタブがクラッシュした後に、タブが復元された場合です。ブラウザはページを一から再読み込みしますが、このセッションは新規のnavigateではなくrestoreとして処理されます。パフォーマンスはコールドナビゲーションと同様です。これはセッションの約2%を占め、最適化の対象になることは稀ですが、不安定なブラウザセッションを使用しているユーザーがいる場合は監視する価値があります。

デバッグのワークフロー

navigateのLCPと全体のLCP目標を比較する。 これが新規読み込みパフォーマンスの基準値となります。もしnavigateがすでに目標値をクリアしているなら、問題は別の場所にあります。
back_forwardとnavigateを比較する。 数値が近い場合、bfcacheが機能していません。Chrome DevToolsを開き、[Application] パネルに移動して、bfcacheテストを実行してください。DevToolsの出力結果に、bfcacheの適用を妨げている具体的な機能やヘッダーがリストアップされます。
prerenderのLCPを確認する。 もし200msを超えている場合、prerenderパイプラインが機能していません。Speculation RulesのJSONが有効であること、対象ページがブロック処理を返していないこと、そしてChrome DevToolsの [Speculation Rules] でアクティブ化がカウントされているかを確認してください。

エンジニアリングの経験則

navigate： 高速なTTFB、LCP画像へのfetchpriority="high"の指定、レンダリングをブロックするリソースの排除といった、通常の最適化によってLCPしきい値をクリアするべきです。
back_forward： navigateよりも10〜20倍高速であるべきです。そうでない場合はbfcacheが機能していません。
prerender： LCPは200ms未満にするべきです。そうでない場合はSpeculation Rulesの設定に問題があります。
reload： TTFBがnavigateより極端に悪化するべきではありません。もし悪化している場合はキャッシュ再検証ヘッダーを修正してください。

Navigation Typeは、「ページがどのように機能しているか」と「ブラウザの個々の読み込み戦略においてページがどのように機能しているか」を切り分けるディメンションです。この区別こそが、憶測とデバッグの決定的な違いです。