Core/Dash ディメンション: ナビゲーション タイプ

ユーザーがどのようにページに到達したかに基づいて Core Web Vitals をセグメント化し、bfcache、プリレンダリング、リロードのパフォーマンスをデバッグします。

無料トライアル [include]partners.html[\/include]

ディメンション: ナビゲーション タイプ (nt)

CrUX データのすべてのページビューには、ナビゲーション タイプが含まれています。これは、ブラウザがページをロードした方法を示しており、ネットワーク スタック、バック\/フォワード キャッシュ、プリレンダリング パイプライン、またはセッション復元のどれが関与したかを決定します。CoreDash はこれを nt ディメンションとして公開しているため、ナビゲーション コンテキストごとに Core Web Vitals を個別にフィルタリングして比較できます。

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

coredash metric table urls

なぜナビゲーション タイプが重要なのか

すべてのナビゲーション タイプにわたって LCP や INP を集計すると、技術的には正しいものの、実際には誤解を招く数値が生成されます。バック\/フォワード キャッシュ ヒットは数ミリ秒で完了します。一方で、コールド ナビゲーションは DNS、TCP、TLS、および TTFB を待ちます。セッションの 20% が bfcache ヒットである場合、それらが p75 LCP を引き下げ、新規ナビゲーションにおける実際の問題が見えにくくなってしまいます。

逆もまた同様です。サイトで bfcache が壊れている場合、バック\/フォワード セッションのパフォーマンスは新規ナビゲーションと同じくらい悪くなります。ナビゲーション タイプでセグメント化しない限り、集計値は安定したままなので、それに気づくことはありません。

プリレンダリングは最も劇的なケースです。正しくプリレンダリングされたページでは、ユーザーがリンクをクリックする前にレンダリングが終了しているため、LCP はゼロに近くなるはずです。プリレンダリングされたページの LCP 数値が通常通りである場合、Speculation Rules の設定が間違っており、プリレンダリングがトリガーされていないか、使用前に破棄されています。

ナビゲーション タイプの一覧

navigate

標準的なナビゲーションです。ユーザーが URL を入力した、別のサイトのリンクをクリックした、またはリダイレクトに従った場合です。これはキャッシュによるショートカットのないフル ページ ロードです。ブラウザは DNS ルックアップ、接続確立、および完全なリソース ロードを含む完全なリクエスト パイプラインを通過します。CoreDash のデータでは、navigate はセッションの約 65% を占めています。これが基準となります。他のすべてのナビゲーション タイプは、navigate と比較して判断されるべきです。

reload

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

back_forward

ユーザーがブラウザの戻るボタンまたは進むボタンを押した場合です。バック\/フォワード キャッシュ (bfcache) が機能している場合、これは可能な限り最速のナビゲーション タイプです。ブラウザはネットワーク リクエストを一切行わずに、メモリからページを復元します。bfcache ヒットの LCP は、実質的にメモリからペイントする時間であり、ほぼ瞬時です。

back_forward の指標が navigate と似ている場合、bfcache は機能していません。最も一般的な原因は、unload イベント ハンドラー、Cache-Control: no-store レスポンス ヘッダー、およびナビゲーション前に閉じられなかった開いている IndexedDB 接続です。CoreDash のデータでは、バック\/フォワードは約 20% のセッションを占めており、これは改善による効果が非常に高い項目です。

prerender

ユーザーがリンクをクリックする前に、Speculation Rules API を使用してバックグラウンドでページがロードされました。ユーザーがクリックすると、プリレンダリングされたドキュメントが即座にアクティブ化されます。正しくアクティブ化されたプリレンダリングの LCP は、ナビゲーション イベントの前にすべてのレンダリング作業が終了しているため、ゼロに近くなります。

prerender の LCP が正常に見える場合、3 つのいずれかが発生しています。アクティブ化の前にプリレンダリングが破棄されたか、投機ルールが間違った URL をターゲットにしていたか、あるいはページがプリレンダリングを妨げるヘッダーや JavaScript を使用しています。CoreDash のセッションの約 3% がプリレンダリングのアクティブ化ですが、Speculation Rules が導入されるとその割合は急速に上昇します。

restore

ブラウザが閉じられた後、またはタブがクラッシュした後にタブが復元されました。ブラウザはページを最初からリロードしますが、セッションは新規のナビゲーションではなく復元と見なされます。パフォーマンスはコールド ナビゲーションと同様です。これはセッションの約 2% を占め、最適化作業の焦点になることは稀ですが、不安定なブラウザ セッションを利用しているユーザーがいる場合は監視する価値があります。

デバッグのワークフロー
  1. navigate の LCP を全体の LCP 目標と比較する。 これが、フレッシュ ロード パフォーマンスの真実です。navigate がすでに合格している場合、問題は他の場所にあります。
  2. back_forward を navigate と比較する。 数値が近い場合、bfcache は壊れています。Chrome DevTools を開き、[Application] パネルに移動して bfcache テストを実行してください。DevTools の出力には、bfcache の適合性を妨げている機能やヘッダーが正確にリストされます。
  3. prerender の LCP を確認する。 200ms を超えている場合、プリレンダリング パイプラインが機能していません。Speculation Rules の JSON が有効であるかを確認し、ターゲット ページがブロック ロジックを返していないかを確認し、Chrome DevTools の [Speculation Rules] でアクティブ化がカウントされていることを確認してください。

    エンジニアリングの目安