Core/Dash ディメンション: リピーター

ディメンション: ユーザー行動: リピーター (fv)

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

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

パフォーマンスの格差が予想以上に大きい理由

ブラウザキャッシュは、リピーターの完全なリクエストチェーンを省略します。一般的なコンテンツサイトでは、リピーターはキャッシュされたすべてのアセットに対するDNSルックアップ、TCPハンドシェイク、TLSネゴシエーション、サーバーレスポンスをスキップします。LCPリソース自体も、ネットワーク経由で200ms〜800msかかる代わりに、メモリキャッシュから5ms未満で提供されることがよくあります。これは単なるわずかな改善ではなく、ページのロード方法における構造的な違いです。

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

両グループ間の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つです。集計されたフィールドデータは真実を覆い隠してしまいます。訪問タイプによって分割することで、最適化の作業が確固たるものなのか、あるいは検索から訪れるすべての新規ユーザーを失望させながら、忠実なリピーターからのキャッシュヒットに頼ってやり過ごしているだけなのかが即座に明らかになります。