Core/Dash Dimension: Navigation Origin
訪問者が同じドメインから来ているか外部ソースから来ているか、そしてその分布がCore Web Vitalsにどのように影響するかを確認できます。
Trusted by market leaders · Client results
Navigation Originが測定するもの
Navigation Originディメンションは、フィールドデータを2つのグループに分割します：
- Same Origin (1) — 前のページが同じドメイン上にあった場合。
- Cross Origin (2) — ユーザーが異なるドメイン、検索エンジン、ソーシャルプラットフォームから来た場合、またはURLを直接入力した場合。
この区別は重要です。なぜなら、それぞれのケースでブラウザの初期条件がまったく異なるからです。同一オリジンのナビゲーションでは、既存の接続を再利用し、サブリソースのHTTPキャッシュを活用し、サイトが設定したプリフェッチの恩恵を受けることができます。クロスオリジンのナビゲーションはゼロから始まります。
クロスオリジンのナビゲーションが遅い理由
ユーザーが外部サイトのリンクをクリックすると、ブラウザはHTMLをリクエストする前にやるべき作業があります：
- DNSルックアップ — ドメインをIPアドレスに解決する。
- TCPハンドシェイク — サーバーへの接続を開く。
- TLSネゴシエーション — HTTPSハンドシェイクを完了する。
これらのステップを合わせると、モバイル接続ではページの最初のバイトがリクエストされる前に通常200〜500ミリ秒が追加されます。このコストはTime to First Byte (TTFB)に直接影響し、LCP要素がHTML到着後にロードされるリソースに依存している場合、Largest Contentful Paint (LCP)の悪化にも波及します。
キャッシュされたサブリソースも利用できません。Googleからクリックして来た訪問者は、フォント、ヒーロー画像、クリティカルCSSのキャッシュされたコピーを持っていません。ホームページから来たばかりの訪問者は、それらすべてを持っている可能性が高いです。
同一オリジンのナビゲーションとback-forwardキャッシュ
同一オリジンのナビゲーションは、クロスオリジンのナビゲーションでは確実に利用できない2つのパフォーマンス上の利点への扉を開きます。
まず、Speculation Rules APIを使用すると、ユーザーがクリックする前に内部ページをプリフェッチまたはプリレンダリングできます。ブラウザはバックグラウンドタブで次のページを完全にレンダリングでき、ナビゲーションを瞬時にします。これは同一オリジンの宛先にのみ適用されます。
次に、back-forwardキャッシュ（bfcache）は、ユーザーが戻るボタンを押したときにメモリからページを復元します。bfcacheヒットは非常に高速で、すべてのCore Web Vitalsで良好なスコアを示します。データ上では同一オリジンのナビゲーションとして表示されます。同一オリジンのLCPがクロスオリジンのLCPよりも大幅に良い場合、bfcacheとプリフェッチがそのギャップに貢献している可能性が高いです。
CoreDashでこのディメンションを読み取る方法
CoreDashでは、Navigation Originをフィルターとして、または任意のメトリクスと組み合わせたブレイクダウンディメンションとして使用できます。最も有用な比較は、ナビゲーションオリジン別のLCPです。同一オリジンとクロスオリジンのLCPの間に大きなギャップがある場合、次の3つのいずれかを示しています：
- クロスオリジンのエントリーページのTTFBが遅く、LCPを膨張させている。
- 同一オリジンのナビゲーションがプリフェッチまたはbfcacheの恩恵を受けているが、クロスオリジンのページはそうではない。
- キャッシュされたサブリソースがリピーターには役立つが、外部ソースからの初回訪問者には役立たない。
クロスオリジンのデータは通常、SEOにとってより重要な数値です。GoogleのChrome UX Report（CrUX）にはすべてのナビゲーションタイプが含まれていますが、オーガニック検索トラフィックはほぼ完全にクロスオリジンです。クロスオリジンのLCPが合格で同一オリジンのLCPが不合格の場合、それは珍しいことであり、調査する価値があります。その逆の方がはるかに一般的です。
クロスオリジンのペナルティを軽減する
コールドスタートのペナルティを完全に排除することはできませんが、軽減することはできます：
- 高速なTTFBのCDNを使用する。サーバーがユーザーに地理的に近く、迅速に応答する場合、接続オーバーヘッドは縮小します。HTMLドキュメントのTTFBは200ミリ秒未満を目標にしましょう。
- LCP画像をプリロードする。
<head>内の<link rel="preload">は、画像のフェッチをできるだけ早く開始し、HTMLの配信からLCP要素の描画までの時間を短縮します。 - クリティカルCSSをインライン化する。レンダーブロッキングのスタイルシートリクエストがなければ、コールド接続でもブラウザはより早く描画できます。
- サードパーティオリジンに
preconnectヒントを追加する。LCP画像やレンダーブロッキングリソースが別のドメインでホストされている場合、rel="preconnect"ヒントがTCPとTLSの作業を早期に開始します。
同一オリジンのナビゲーションについては、Speculation Rules APIが現在利用可能な最もインパクトの大きい改善です。最も可能性の高い次のページをプリレンダリングすることで、それらの遷移のLCPをほぼゼロに削減できます。
Navigation Originのコンテキスト
Navigation Originは、Navigation Typeディメンション（navigate、reload、back-forward、prerenderを区別する）およびEffective Connection Typeディメンションと組み合わせるとうまく機能します。低速な接続でのクロスオリジンのナビゲーションは、サイトが直面する最も厳しいシナリオです。これら2つの条件を組み合わせてフィルタリングすると、真のワーストケースのパフォーマンスと最大の改善が可能な箇所が表示されます。