Core/Dash ディメンション: リピート訪問者

ディメンション: User Behavior: Repeat Visitor (fv)

リピート訪問者（Repeat Visitor）ディメンションは、パフォーマンスデータを2つのグループに分割します。以前にサイトを訪れたことがあるユーザーと、そうでないユーザーです。これらのグループ間のエンジニアリング上の違いは、ブラウザキャッシュにあります。リピート訪問者はフォント、スクリプト、画像をディスクからロードしますが、新規訪問者はすべてのバイトをネットワークからフェッチします。

これが重要となる理由は、集計されたLCPスコアが両者の加重平均であるためです。セッションの40%が新規訪問者である場合、彼らのコールドキャッシュのロード時間がp75を引き上げています。このディメンションがなければ、LCPの悪化が実際のインフラストラクチャの問題なのか、それとも新規ユーザー獲得の一時的な急増によるものなのかを判断することはできません。

パフォーマンスのギャップが予想以上に大きい理由

ブラウザキャッシュは、リピート訪問者のリクエストチェーン全体を排除します。一般的なコンテンツサイトでは、リピート訪問者はキャッシュされた各アセットに対するDNSルックアップ、TCPハンドシェイク、TLSネゴシエーション、サーバー応答をスキップします。LCPリソース自体も、ネットワーク経由で200msから800msかかる代わりに、多くの場合5ms未満でメモリキャッシュから提供されます。これはわずかな改善ではなく、ページの読み込み方法における構造的な違いです。

監視対象サイトのCoreDashデータでは、リピート訪問者は通常、同じページで新規訪問者よりも35%から60%低いLCPスコアを示します。このギャップは、ヒーロー画像が大きく、オリジンサーバーが地理的にユーザーから離れている画像中心のページで最大になります。サーバーサイドレンダリングを使用し、テキストのLCP要素を持つページでは、テキストのロード遅延が両方のグループでほぼゼロであるため、ギャップは狭まります。

2つのグループ間のINPの違いは小さいですが、存在しています。新規訪問者は、初回ロード時にモジュールバンドルが初めて評価されるため、より多くのJavaScriptの解析をトリガーすることがよくあります。リピート訪問者は、コンパイルされたバイトコードを保存し、解析とコンパイルのステップを完全にスキップするV8のコードキャッシュの恩恵を受けます。JavaScriptを多用するページでは、これにより処理時間が50msから150ms短縮される可能性があります。

3つの値の読み方

0: リピート訪問者 (Repeat Visitor)

これはユーザーのオリジンに対する最初のセッションではないとブラウザが報告しています。キャッシュされたリソースが利用可能です。CoreDashでトラッキングされているほとんどのマーケティングおよびエディトリアルサイトにおいて、リピート訪問者は全セッションの55%から70%を占めます。彼らのパフォーマンスデータは、あなたのウォームキャッシュベースライン、つまりサイトを知っている実際のユーザーにとってのベストケースシナリオです。もしここでLCPが悪い場合、問題はキャッシュではありません。代わりに、レンダリングブロックリソース、サーバー応答時間、またはレンダリング遅延を確認してください。

1: 新規訪問者 (New Visitor)

キャッシュはありません。ブラウザはすべてのリソースをネットワークからフェッチします。これはコールドキャッシュの最悪のケースであり、オーガニック検索、有料広告、またはソーシャルシェアを通じてあなたを見つけたすべてのユーザーに対する第一印象を表します。新規訪問者は通常、セッションの30%から45%を占めます。彼らのLCPスコアは、画像ベースのページにおいて、リピート訪問者よりも300msから700ms高くなります。もし新規訪問者のLCPが2.5秒のしきい値に失敗し、リピート訪問者のLCPがパスしている場合、最適化のターゲットは明確です。このオーディエンスに対してはキャッシュに頼ることができないため、LCPリソース自体のサイズと遅延を減らしてください。

2: 測定不可 (Not Measured)

CoreDashはこのセッションの訪問タイプを特定できませんでした。これは通常、新規訪問者とリピート訪問者を区別するために必要なストレージアクセスをブラウザがブロックした場合、またはプライバシー重視のブラウザ設定がチェックを妨げた場合に発生します。ほとんどのサイトにおいて、このバケツはセッションの5%未満です。最適化の対象となるセグメントではなく、ノイズフロアとして扱ってください。

デバッグのワークフロー

1. ベースラインの分割を確立する: CoreDashでリピート訪問者（Repeat Visitor）ディメンションを開き、新規セッションとリピートセッションの割合に注目します。新規訪問者がトラフィックの50%を超えている場合、コールドキャッシュのパフォーマンスが主要なUXであり、主な最適化ターゲットにする必要があります。
2. 訪問タイプ別にLCPを比較する: 新規訪問者のみにフィルタリングし、p75のLCPを記録します。次に、リピート訪問者にフィルタリングして同じ指標を記録します。500ms以上のギャップがある場合は、アセットサイズまたはネットワークフェッチ時間がボトルネックであることを示しています。200ms以下のギャップの場合は、両方のグループに等しく影響するレンダリング側の問題を示唆しています。
3. LCPリソースを直接ターゲットにする: LCPが遅い新規訪問者に対する修正は、リソースのロード時間を減らすことです。LCP画像を圧縮し、ユーザーに近いCDNエッジノードから配信し、fetchpriority="high"を適用します。これらのメリットはキャッシュの状態に関係なく持続します。サイズが大きすぎたり、配信が遅いLCPアセットを補うためにキャッシュに依存しないでください。
4. Navigation Typeディメンションで検証する: Navigation Typeディメンションと照らし合わせて相互参照します。リロードや「戻る/進む」によるナビゲーションは、リピート訪問者に偏る傾向があります。リピート訪問者のLCPが予想以上に遅いように見える場合、リロードナビゲーションの割合が高いこと（キャッシュされたリソースが直接配信されるのではなく、再検証される）が原因である可能性があります。

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

• 新規訪問者のLCPターゲット: p75で2.5秒未満。これはリピート訪問者のLCPよりも達成が困難であり、CDN、画像最適化、適切なフェッチ優先度といった実際のインフラストラクチャ作業を必要とします。
• 新規訪問者とリピート訪問者のLCP間の許容ギャップ: 最大400ms。これよりギャップが大きい場合、サイトがCore Web Vitalsをパスするためにブラウザキャッシュに依存していることを示しており、第一印象が失敗していることを意味します。
• 測定不可（Not Measured）は5%未満: このバケツが10%を超えて増加した場合は、Cookie同意の実装やストレージ許可の変更が訪問タイプの検出をブロックしていないか調査してください。

リピート訪問者（Repeat Visitor）ディメンションは、サイトがLCPで境界線上のパスを示した際に私が最初に適用するフィルターの1つです。集計されたフィールドデータは本当の姿を隠してしまいます。訪問タイプ別に分割することで、最適化の作業がしっかりしているか、あるいは検索からやってくるすべての新規ユーザーに失敗しつつ、ロイヤルなリピーターのキャッシュヒットに頼ってサイトが成り立っているかがすぐにわかります。