Core/Dash ディメンション: Navigation Origin

訪問者が同じドメインから来ているのか、外部ソースから来ているのかを確認し、その違いがCore Web Vitalsにどう影響するかを把握します。

無料トライアル

Trusted by market leaders · Client results

kpnworkivaaleteiaperionebayerasmusmcloopearplugscomparemy work featured on web.devadevintaharvardwhowhatwearfotocasamonarchnina caremarktplaatsdpg mediavpnsnvsaturnhappyhorizonnestle

Navigation Originが測定するもの

Navigation Originディメンションは、フィールドデータを次の2つのグループに分割します：

  • Same Origin (1) — 前のページが同じドメインにある場合。
  • Cross Origin (2) — ユーザーが別のドメイン、検索エンジン、ソーシャルプラットフォームからアクセスしたか、URLを直接入力した場合。

この区別が重要な理由は、それぞれのケースでブラウザの開始条件がまったく異なるためです。same-origin（同一オリジン）のナビゲーションでは、既存の接続を再利用し、サブリソースのHTTPキャッシュを活用し、サイトに設定されているプリフェッチの恩恵を受けることができます。一方、cross-origin（クロスオリジン）のナビゲーションはゼロから始まります。

クロスオリジンのナビゲーションが遅くなる理由

ユーザーが外部サイトからのリンクをクリックした場合、ブラウザがHTMLをリクエストする前に、次のような処理を行う必要があります：

  1. DNSルックアップ — ドメインをIPアドレスに解決します。
  2. TCPハンドシェイク — サーバーへの接続を確立します。
  3. TLSネゴシエーション — HTTPSハンドシェイクを完了します。

これらのステップが合わさることで、モバイル回線ではページの最初のバイトがリクエストされる前に、通常200〜500ミリ秒の遅延が追加されます。このコストはTime to First Byte (TTFB)に直接表れます。さらに、LCP要素がHTML到達後に読み込まれるリソースに依存している場合、結果としてLargest Contentful Paint (LCP)のスコア悪化にも連鎖します。

キャッシュされたサブリソースも利用できません。Googleからのリンクをクリックして訪れたユーザーは、フォント、ヒーロー画像、またはクリティカルCSSのキャッシュを持っていません。一方、あなたのサイトのホームページから遷移してきた訪問者であれば、それらをすべて保持している可能性が高いです。

同一オリジンのナビゲーションとバックフォワードキャッシュ（bfcache）

same-originのナビゲーションは、cross-originのナビゲーションでは確実に利用できない2つのパフォーマンス上の利点をもたらします。

1つ目は、Speculation Rules APIです。これにより、ユーザーがクリックする前に内部ページをプリフェッチまたは事前レンダリングできます。ブラウザはバックグラウンドのタブで次のページを完全にレンダリングした状態にできるため、ナビゲーションが瞬時に行われます。これはsame-originの宛先にのみ適用されます。

2つ目は、back-forward cache (bfcache)です。これはユーザーが戻るボタンを押した際にメモリからページを復元します。bfcacheのヒットは非常に高速で、すべてのCore Web Vitalsにおいて良いスコアを記録します。これらはデータ上、same-originのナビゲーションとして表示されます。もしsame-originのLCPがcross-originのLCPよりも大幅に優れている場合、bfcacheとプリフェッチがその差に寄与している可能性が高いです。

CoreDashでのこのディメンションの読み方

coredash metric table urls

CoreDashでは、Navigation Originをフィルターとして、あるいは任意の指標に対する内訳ディメンションとして使用します。最も有用な比較は、ナビゲーションのオリジンごとのLCPです。same-originとcross-originのLCPに大きな差がある場合、次の3つのいずれかを示しています：

  • cross-originのランディングページのTTFBが遅く、それがLCPを悪化させている。
  • same-originのナビゲーションはプリフェッチやbfcacheの恩恵を受けているが、cross-originのページはそうではない。
  • キャッシュされたサブリソースが再訪問者には役立っているが、外部ソースからの初回訪問者には機能していない。

cross-originのデータは、一般的にSEOにおいてより重要な数値となります。GoogleのChrome UX Report (CrUX)にはすべてのナビゲーションタイプが含まれますが、オーガニック検索トラフィックはほぼすべてcross-originです。cross-originのLCPが合格しているのにsame-originのLCPが不合格になる場合、それは異常であり調査する価値があります。逆のケースの方がはるかに一般的です。

クロスオリジンのペナルティを軽減する

コールドスタートのペナルティを完全になくすことはできませんが、軽減することは可能です：

  • TTFBが高速なCDNを使用する。 サーバーが地理的にユーザーに近く、応答が速い場合、接続オーバーヘッドは減少します。HTMLドキュメントのTTFBは200ミリ秒未満を目標にしてください。
  • LCP画像をプリロードする。 <head>内の<link rel="preload">によって、画像の取得をできるだけ早く開始し、HTMLの配信からLCP要素の描画までの時間を短縮します。
  • クリティカルCSSをインライン化する。 レンダリングをブロックするスタイルシートのリクエストをなくすことで、コールドな接続でもブラウザがより早く描画できるようになります。
  • サードパーティのオリジンにpreconnectヒントを追加する。 LCP画像やレンダリングブロックリソースが別のドメインでホストされている場合、rel="preconnect"ヒントを使用すると、TCPとTLSの処理を早期に開始できます。

same-originのナビゲーションにおいて、現在利用可能な最も影響力の大きい改善策はSpeculation Rules APIです。次に遷移する可能性が最も高いページを事前レンダリングすることで、それらの遷移時のLCPをほぼゼロに短縮できます。

コンテキストにおけるNavigation Origin

Navigation Originは、Navigation Typeディメンション（navigate、reload、back-forward、prerenderを分類します）およびEffective Connection Typeディメンションと組み合わせて使用すると効果的です。遅い接続環境でのcross-originナビゲーションは、サイトが直面する最も過酷なシナリオです。これら2つの条件を同時にフィルタリングすることで、真のワーストケースのパフォーマンスと、どこに最大の改善余地があるのかが明らかになります。