Core Web Vitals の指標をモニタリングするツールで異なる数値が表示されることがある理由と、その違いを解釈する方法について説明します。
Google は、サイト所有者が Core Web Vitals のスコアをモニタリングするのに役立つさまざまなツールを提供しています。これらのツールは、主に次の 2 つのカテゴリに分類されます。
- ラボデータを報告するツール - 事前に定義されたデバイスとネットワーク設定を使用して、制御された環境で収集されたデータ。
- フィールド データ（サイトにアクセスする実際のユーザーから収集されたデータ）をレポートするツール。
問題は、ラボ用ツールによって報告されるデータがフィールド ツールによって報告されるデータと大きく異なる場合があることです。ラボのデータを見るとサイトのパフォーマンスが良好であることが示されていて、フィールド データを見ると改善が必要であることがわかります。また、フィールド データではすべてのページが良好と示されていても、ラボデータではスコアが非常に低い場合があります。
次に示す web.dev の PageSpeed Insights レポートの実際の例は、場合によっては、ラボデータとフィールド データが Core Web Vitals のすべての指標で異なる可能性があることを示しています。
ツールの違いはデベロッパーにとってわかりきった混乱の原因です。この投稿では、このような相違が生じる主な理由について、Core Web Vitals の各指標の具体的な例を交えて説明します。また、ページで相違が見つかった場合の対応についても説明します。
ラボデータとフィールド データ
ウェブページがまったく同じであっても、ラボツールとフィールド ツールで異なる値が報告される理由を理解するには、ラボデータとフィールド データの違いを理解する必要があります。
ラボデータ
ラボデータは、事前に定義されたネットワークとデバイスの条件で制御された環境でウェブページを読み込むことによって決定されます。これらの条件はラボ環境と呼ばれ、合成環境とも呼ばれます。
ラボデータを報告する Chrome ツールは通常、Lighthouse を実行します。
臨床試験の目的は、できるだけ多くの要因を制御して、結果が（可能な限り）一貫性があり、実行間で再現できるようにすることです。
フィールド データ
フィールド データは、ページにアクセスするすべてのユーザーをモニタリングし、ユーザーの個々のエクスペリエンスごとに特定のパフォーマンス指標のセットを測定することによって決定されます。フィールド データは実際のユーザーによるアクセスに基づいているため、ユーザーの実際のデバイス、ネットワーク状態、地理的位置を反映します。
フィールド データは、一般にリアルユーザー モニタリング（RUM）データとも呼ばれます。この 2 つの用語は同じ意味で使用されます。
フィールド データをレポートする Chrome ツールは通常、Chrome ユーザー エクスペリエンス レポート（CrUX）からそのデータを取得します。また、サイト所有者が自分でフィールド データを収集することも一般的です（推奨）。これは、CrUX のみを使用するよりも行動につながるインサイトを提供できるためです。
フィールド データを理解するうえで最も重要なことは、単なる 1 つの数値ではなく、数値の分布であるということです。つまり、サイトにアクセスするユーザーによっては読み込みに時間がかかる場合もあれば、非常に遅い場合もあります。サイトのフィールド データは、ユーザーから収集されたすべてのパフォーマンス データ一式です。
たとえば、CrUX レポートには、実際の Chrome ユーザーによる 28 日間のパフォーマンス指標の分布が表示されます。ほとんどの CrUX レポートを見ると、サイトを訪れたユーザーの中には、ユーザー エクスペリエンスが非常に良いものと、まったく劣っている人がいることがわかります。
ツールが特定の指標について単一の数値を報告する場合、通常は分布内の特定のポイントを表します。Core Web Vitals のフィールド スコアを報告するツールは、75 パーセンタイルを使用します。
上のスクリーンショットのフィールド データから LCP を確認すると、次の分布が確認できます。
- 訪問の 88% で 2.5 秒以下の LCP を確認（良好）
- 訪問の 8% で 2.5 ～ 4 秒の LCP が確認されました（改善が必要）。
- 訪問の 4% で LCP が 4 秒を上回っています（低い）。
75 パーセンタイルで、LCP は 1.8 秒でした。
同じページのラボデータでは、LCP 値は 3.0 秒となっています。この値は、フィールド データに示されている 1.8 秒より大きくなりますが、このページにとって有効な LCP 値であり、負荷エクスペリエンスの完全な分布を構成する多くの値の 1 つになります。
ラボデータとフィールド データが異なる理由
前のセクションで説明したように、ラボデータとフィールド データは実際にはまったく異なるものを測定します。
フィールド データには、さまざまなネットワークとデバイスの条件のほか、さまざまな種類のユーザー行動が含まれます。また、バックフォワード キャッシュ（bfcache）などのブラウザの最適化や、AMP キャッシュなどのプラットフォームの最適化など、ユーザー エクスペリエンスに影響するその他の要因も含まれます。
対照的に、ラボデータでは関係する変数の数が意図的に制限されています。ラボテストの構成は以下のとおりです。
- 1 台のデバイス...
- 1 つのネットワークに接続しています。
- 1 つの地理的位置から実行できます
臨床試験の細部は、特定のページやサイトのフィールド データの 75 パーセンタイルを正確に表しているとは限りません。
ラボの制御された環境は、本番環境にデプロイする前の問題のデバッグや機能のテストに役立ちますが、これらの要因を制御する場合、あらゆる種類のネットワーク、デバイス機能、地理的位置にまたがって現実世界で見られるばらつきを明示的に表しているわけではありません。また、ページ上のスクロール、テキストの選択、要素のタップなど、実際のユーザーの行動がパフォーマンスに及ぼす影響も一般的に把握できていません。
ラボの条件と実際のユーザーの状況との間には乖離があるだけでなく、ラボとフィールド データを最大限に活用するために理解しておくべき微妙な違いや、その違いもいくつかあります。
以降のセクションでは、Core Web Vitals の各指標でラボデータとフィールド データに差異が生じる最も一般的な理由について詳しく説明します。
LCP
さまざまな LCP 要素
ラボテストで識別される LCP 要素は、ユーザーがページにアクセスしたときに表示される LCP 要素と異なる場合があります。
特定のページに対して Lighthouse レポートを実行すると、毎回同じ LCP 要素が返されます。しかし、同じページのフィールド データを見ると、通常、各ページ訪問に固有のさまざまな状況に応じて、さまざまな LCP 要素があります。
たとえば、次の要因はすべて、同じページに対して異なる LCP 要素が決定される原因となる可能性があります。
- デバイスの画面サイズが異なれば、ビューポート内に表示される要素も異なります。
- ユーザーがログインしている場合、またはパーソナライズされたコンテンツがなんらかの方法で表示されている場合は、LCP 要素がユーザーごとに大きく異なる可能性があります。
- 前述のポイントと同様に、A/B テストがページで実行されている場合、表示される要素が大きく異なる可能性があります。
- ユーザーのシステムにインストールされているフォントのセットは、ページ上のテキストのサイズ（つまりどの要素が LCP 要素であるか）に影響を与える可能性があります。
- ラボテストは通常、ページの「ベース」URL で実行します。クエリ パラメータやハッシュ フラグメントは追加されません。しかし実際の環境では、ユーザーがフラグメント識別子やテキスト フラグメントを含む URL を共有することが多いため、LCP 要素は実際にはページの中央または下部（「スクロールせずに見える範囲」ではなく）に配置されている可能性があります。
フィールドの LCP は、ページにアクセスしたすべてのユーザーの 75 パーセンタイルとして計算されるため、ユーザーの大部分が LCP 要素をすぐに読み込む場合（たとえば、システム フォントでレンダリングされたテキストの段落など）は、LCP 要素として読み込みが遅い大きな画像が含まれていたとしても、そのページのスコアが 25% 未満の場合、そのページのスコアには影響しません。
あるいは、その逆も成り立ちます。ラボテストでは、テキスト ブロックが LCP 要素として識別される場合があります。これは、比較的小さいビューポートを持つ Moto G4 スマートフォンをエミュレートしており、ページのヒーロー画像が最初に画面外にレンダリングされるためです。ただし、フィールド データには、主に画面の大きい Google Pixel XL ユーザーが含まれる可能性があるため、読み込みが遅いヒーロー画像は LCP 要素です。
キャッシュ状態が LCP に及ぼす影響
ラボテストでは通常、コールド キャッシュのあるページが読み込まれますが、実際のユーザーがそのページにアクセスしたときに、リソースの一部がすでにキャッシュされている場合があります。
ユーザーが初めてページを読み込むときは読み込みが遅くなる可能性がありますが、ページにキャッシュが適切に構成されていれば、次にユーザーが戻ったときにすぐに読み込まれる可能性があります。
一部のラボツールでは、同じページを複数回実行することをサポートしています（リピーターによるアクセスをシミュレートするため）。ただし、ラボツールで、新規ユーザーとリピーターによる実際のアクセスの割合を把握することはできません。
キャッシュ設定が十分に最適化されており、リピーターが多いサイトでは、実際の LCP はラボのデータよりもはるかに高速です。
AMP または Signed Exchange の最適化
AMP で構築されたサイトや Signed Exchange（SXG）を使用するサイトは、Google 検索などのコンテンツ アグリゲータによってプリロードできます。これにより、これらのプラットフォームからページにアクセスするユーザーの読み込みパフォーマンスが大幅に向上します。
クロスオリジンのプリロードに加えて、サイト自体はサイト内の後続のページのコンテンツをプリロードできるため、それらのページの LCP も改善される可能性があります。
ラボツールは、こうした最適化による効果をシミュレートするものではなく、たとえ実施したとしても、Google 検索などのプラットフォームからのトラフィックの割合を他のソースと比較して把握することはできません。
bfcache が LCP に及ぼす影響
ページが bfcache から復元されると、読み込みはほぼ瞬時に行われ、これらのエクスペリエンスはフィールド データに含まれます。
ラボテストでは bfcache は考慮されないため、ページが bfcache と相性が良い場合は、フィールドで報告される LCP スコアが速くなる可能性があります。
ユーザー インタラクションが LCP に及ぼす影響
LCP はビューポート内の最も大きな画像またはテキスト ブロックのレンダリング時間を識別しますが、その最大の要素はページが読み込まれるときや新しいコンテンツがビューポートに動的に追加されるときに変化する可能性があります。
ラボでは、ブラウザはページが完全に読み込まれるまで待ってから、LCP 要素を判断します。フィールド内では、ユーザーがページをスクロールまたは操作すると、ブラウザはより大きな要素のモニタリングを停止します。
ユーザーは通常、ページが読み込まれるまで操作するまで待機するため、これは理にかなっています（また必要）。また、ユーザーの操作後にビューポートに追加された要素は、ユーザーの操作が原因でのみ読み込まれた可能性があるため、意味がありません。
ただし、その結果として、ページでのユーザーの行動によっては、ページのフィールド データの方が LCP 時間が短くなる場合があります。
FID
FID には実際のユーザーによる操作が必要
FID 指標は、ユーザーが実際にページ操作を選択した時点で、ユーザー操作に対するページの応答性を測定するものです。
ラボテストでは、スクリプトのユーザーの行動をサポートするものであっても、ユーザーがいつページを操作するかを正確に予測できず、FID を正確に測定できないため、この文の 2 番目の部分は重要です。
TBT ではユーザー行動は考慮されない
ラボの指標の Total Blocking Time（TBT）は、ページの読み込み中にメインスレッドがどの程度ブロックされるかを定量化するため、FID の問題の診断に役立ちます。
同期的な JavaScript や他の集中的なレンダリング タスクが多いページでは、ユーザーが初めて操作したときにメインスレッドがブロックされる可能性が高くなります。ただし、JavaScript の実行が完了するまでユーザーがページの操作を待機すると、FID が非常に低くなる可能性があります。
ユーザーがページを操作するタイミングは、ページがインタラクティブに見えるかどうかによって大きく異なり、TBT では測定できません。
TBT ではタップ遅延は考慮されない
サイトがモバイル表示用に最適化されていない場合、ブラウザでイベント ハンドラが実行されるまでに、タップの後、300 ミリ秒の遅延が追加されます。これは、マウスまたはクリック イベントを呼び出す前に、ユーザーがダブルタップしてズームしようとしているかどうかを判断する必要があるためです。
この遅延は、ユーザーが体験する実際の入力レイテンシに寄与するため、ページの FID にカウントされます。ただし、この遅延は厳密には長時間のタスクではないため、ページの TBT には影響しません。つまり、TBT スコアが良好であっても、ページの FID が低い可能性があります。
キャッシュ状態と bfcache が FID に及ぼす影響
適切なキャッシュによってフィールドの LCP が改善されるのと同様に、FID も改善できます。
実際には、サイトの JavaScript がユーザーのキャッシュにすでに保存されている可能性があります。そのため、処理の時間を短縮し、遅延を小さくすることができます。
bfcache から復元されたページについても同様です。その場合、JavaScript はメモリから復元されるため、処理時間がほとんど、またはまったくない可能性があります。
CLS
ユーザー インタラクションが CLS に及ぼす影響
ラボで測定した CLS では、スクロールせずに見える範囲と読み込み時に発生するレイアウト シフトのみが考慮されますが、これは CLS で実際に測定されるもののサブセットにすぎません。
このフィールドでは、CLS はページの存続期間全体を通じて発生するすべての予期しないレイアウト シフトを考慮します。これには、ユーザーのスクロールに合わせて移動するコンテンツや、ユーザー操作後のネットワーク リクエストの遅延に応じて移動するコンテンツも含まれます。
たとえば、ディメンションのない画像や iframe をページで遅延読み込みすることはよくあります。ユーザーがページのこれらのセクションにスクロールすると、レイアウトが移動することがあります。ただし、このようなシフトはユーザーが下にスクロールしたときにのみ発生する可能性があり、多くの場合、ラボテストでは検出されません。
マイページのコンテンツ
ターゲット広告や A/B テストなど、パーソナライズされたコンテンツは、ページで読み込まれる要素に影響します。パーソナライズされたコンテンツは後で読み込まれてページのメイン コンテンツに挿入されることが多いため、コンテンツの読み込み方法にも影響します。これにより、レイアウトが移動します。
ラボでは通常、パーソナライズされたコンテンツなし、または一般的な「テストユーザー」向けのコンテンツがページを読み込みます。このため、実際のユーザーに見られる変化がトリガーされる場合があります。
フィールド データにはすべてのユーザー エクスペリエンスが含まれているため、特定のページで発生するレイアウト シフトの量（および程度）は、読み込まれるコンテンツによって大きく異なります。
CLS に対するキャッシュ状態と bfcache の影響
読み込み中のレイアウト シフトの最も一般的な原因は、前述のディメンションのない画像と iframe と、ウェブフォントの読み込みが遅いことです。どちらの問題も、ユーザーが初めてサイトにアクセスしたとき、キャッシュが空の場合のエクスペリエンスに影響する可能性があります。
ページのリソースがキャッシュに保存されている場合、またはページ自体が bfcache から復元された場合、ブラウザは通常、画像やフォントのダウンロードを待たずにすぐにレンダリングできます。このため、フィールドの CLS 値がラボツールで報告される値よりも低くなる可能性があります。
結果が異なる場合の対応
原則として、特定のページにフィールド データとラボデータの両方がある場合は、作業の優先順位付けにフィールド データを使用する必要があります。フィールド データは実際のユーザーが直面している状況を表すため、ユーザーが直面している問題や改善が必要な点を最も正確に把握できる方法です。
逆に、フィールド データが全体的に良好なスコアを示していても、ラボデータからまだ改善の余地があると判断された場合は、さらに最適化できる方法を理解する価値があります。
また、フィールド データは実際のユーザー エクスペリエンスをキャプチャしますが、これはサイトを正常に読み込むことができるユーザーについてのみデータを表します。ラボデータは、サイトのリーチを拡大し、低速ネットワークやローエンド デバイスのユーザーがアクセスしやすくする機会を特定するのに役立ちます。
全体として、ラボデータとフィールド データは、効果的なパフォーマンス測定の重要な要素です。どちらにも長所と限界があり、1 つだけ使用していると、ユーザー エクスペリエンスを改善する機会を逃す可能性があります。