Core Web Vitals の指標をモニタリングするツールで報告される数値が異なる理由と、その違いを解釈する方法について説明します。
Google では、サイト所有者がウェブサイトの監視に役立つさまざまなツールを提供しています。 Core Web Vitals のスコアです。これらのツールは 大きく 2 つに分類できます
- ラボデータを報告するツール（検査データを使用して制御された環境で収集されたデータ） 事前定義済みのデバイスとネットワーク設定を サポートしています
- フィールド データ（アクセスした実際のユーザーから収集されたデータ）をレポートするツール できます。
問題は、ラボツールによって報告されるデータが場合によって、 フィールド ツールで報告されるデータとは異なります。ラボデータによって フィールド データによると、サイトのパフォーマンスは良好であるものの、 向上しますフィールド データですべてのページが良好と判定されても、 ラボデータから非常に低いスコアが報告されることがあります。
web.dev の PageSpeed Insights レポートの例を以下に示します。 ラボデータとフィールド データが Core Web Vitals の指標:
ツールの違いが、組織にとって当然ながら混乱の原因となる 開発できます。この記事では、こうした違いが生じる主な理由について Core Web Vitals の各指標に関する具体例を含む ページ間の相違が見つかった場合の対処法
ラボデータとフィールド データ
ラボツールとフィールド ツールで、 ラボとフィールドの違いを理解する必要があります。 分析できます
ラボデータ
ラボデータは、制御された環境でウェブページを読み込み、 ネットワークやデバイスに関する事前定義済みの条件を 組み合わせることができますこのような状態は ラボラボ環境。合成環境とも呼ばれます。
検査データを報告する Chrome ツールが正常に動作している Lighthouse:
臨床試験の目的はできるだけ多くの要素をコントロールすることです 結果が（可能な限り）整合性があり、実行ごとに再現可能である。
フィールド データ
フィールド データは、ページを訪問するすべてのユーザーをモニタリングし、 各ユーザーのパフォーマンス指標のセットを個人 体験できますフィールド データは実際のユーザーの訪問に基づいているため、 ユーザーの実際のデバイス、ネットワーク状態、地理的位置といった情報を提供します。
フィールド データは一般に Real User Monitoring とも呼ばれます。 （RUM）データ。2 つの項 互換性があります。
フィールド データを報告する Chrome ツールは通常、そのデータを Chrome ユーザー エクスペリエンス レポート （CrUX）をご覧ください。 また、サイト所有者がフィールド データを収集することも一般的（推奨） 追加の分析情報を取得できるため 行動につながるインサイトが得られます。
フィールド データについて理解しておくべき最も重要なことは、フィールド データは単なる 数値の分布ですつまり、サイトを訪れた一部のユーザーが サイトによっては読み込みがとても速い場合もあれば、非常に遅い場合もあります。 サイトのフィールド データは、すべてのパフォーマンス データをまとめたものです。 収集します
たとえば、CrUX レポートには実際のパフォーマンス指標の分布が表示されます。 28 日間の Chrome ユーザー数。CrUX レポートのほとんどを見れば サイトにアクセスした一部のユーザーは エクスペリエンスが非常に良い一方で 非常に不快な経験がある人もいます。
ツールが特定の指標に対して単一の数値を報告する場合、通常は 分布内の特定の点を表しますCore Web を報告するツール Vitals フィールドのスコアは、 パーセンタイル。
上のスクリーンショットのフィールド データから LCP を見ると、 ここで:
- 訪問の 88% で、LCP が 2.5 秒以下（良好）でした。
- 訪問の 8% で、2.5 ～ 4 秒の LCP が確認されました（改善が必要）。
- 訪問の 4% で LCP が 4 秒を超えた（低い）。
75 パーセンタイルで、LCP は 1.8 秒でした。
同じページのラボデータでは、LCP 値が 3.0 秒となっています。この値は フィールド データの 1.8 秒を超える場合も、有効な LCP である 値（これは、分布全体を構成する多数の値の 1 つ）です。 提供できます
ラボデータとフィールド データが異なる理由
前述のとおり、ラボデータとフィールド データは、 あります。
フィールド・データには、ネットワークやデバイスのさまざまな状態、 多様化していますまた このアラートには たとえば、 バックフォワード キャッシュ（bfcache）、または AMP キャッシュ。
一方、ラボデータでは、関係する変数の数は意図的に制限されています。 ラボテストは以下で構成されます
- 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% を下回った場合、そのページのスコアは できます。
あるいは、その逆が当てはまる場合もあります。ラボテストでは、1 つのブロックが というテキストが LCP 要素として扱われます。 ページのヒーロー画像が最初にレンダリングされ オフにします。ただし、フィールド データの大半は、次の要件を満たす Google Pixel XL ユーザー そのため、読み込みの遅いヒーロー画像が LCP 要素です。
LCP に対するキャッシュ状態の影響
ラボテストでは通常、コールド キャッシュを含むページが表示されますが、実際のユーザーがアクセスすると リソースの一部がすでにキャッシュされている可能性があります。
ユーザーが初めてページを読み込むときは 読み込みが遅くなることがありますが 適切にキャッシュが設定されていれば、次回ユーザーが ページがすぐに読み込まれる可能性があります。
ラボツールの中には、同じページを複数回実行することをサポートするものがあります（ ウェブサイト訪問者のエクスペリエンス）を ラボツールで把握することはできませんが 実際の訪問のうち、新規ユーザーとリピーターの割合。
キャッシュ設定が最適化されており、リピート ユーザーが多いサイトでは、 ラボデータで示されているよりもはるかに高速であることがわかりました。
AMP または Signed Exchange の最適化
AMP で作成されたサイト、または Signed Exchange を使用するサイト （SXG）: Google などのコンテンツ アグリゲータがプリロードできます。 検索。これにより、ユーザーにとっての読み込みパフォーマンスが大幅に向上します。 パフォーマンス指標です
クロスオリジン プリロードに加えて、サイト自体は サイトの後続のページ用にコンテンツをプリロードする これらのページの LCP も改善されます
ラボのツールは、こうした最適化による効果をシミュレーションするものではなく、 同社は自社のトラフィックに占める 割合を把握できず Google 検索などのプラットフォームと他のソースを比較しました。
bfcache が LCP に及ぼす影響
ページが bfcache から復元されると、読み込みがほぼ こうしたエクスペリエンスが 。
ラボテストでは bfcache が考慮されないため、 bfcache に適した場合は、 フィールドの LCP スコアが速くなります
ユーザー操作が LCP に及ぼす影響
LCP は、テキスト ブロック内の最も大きい画像またはテキスト ブロックのレンダリング時間を ただし、ページの読み込み時や 自動的にビューポートに追加されます。
ラボでは、ブラウザはページが完全に読み込まれるまで待ってから、 LCP 要素を特定しましたしかし、作業中にブラウザが モニタリング: 大きな要素の場合 ユーザーがページをスクロールしたり 操作したりした後
これは当然のことであり、必要でもあります。なぜなら、ユーザーは通常、 そのページが「表示される」までページに対してなんらかの操作を行った読み込みが完了しています。これは LCP が 検出しようとします。また、追加される要素を考慮する意味もなく、 ユーザーが操作した後にビューポートが移動します。これは、 なんらかの理由で読み込まれたものがあるとは限りません。
ただし、これによりページのフィールド データの方が迅速にレポートを取得できるため、 LCP の時間は、そのページでのユーザーの行動によって異なります。
INP
INP には実際のユーザー操作が必要
INP 指標はユーザー操作に対する ページの応答性を測定するものです ユーザーが実際に操作した時点を表示します
この文章の後半部分は重要です なぜなら 臨床試験でも スクリプトのユーザーの行動をサポートするため、ユーザーが選択するタイミングを正確に予測できない FID を正確に測定できません。
TBT ではユーザー行動は考慮されない
ラボの指標である Total Blocking Time (TBT) は、ページの読み込み中にメインスレッドがブロックされる量を定量化することで、INP の問題の診断に役立てることを目的としています。
同期型の JavaScript やその他の集中的な処理が メインスレッドがブロックされる可能性が高くなるため、ユーザーが 必要があります。ただし、ユーザーが閲覧されるまでページ上でのインタラクションを JavaScript の実行が終了すると、INP が非常に低い可能性があります。
ユーザーがページを操作するタイミングは、 インタラクティブに見えるため、TBT では測定できません。
TBT ではタップの遅延は考慮されない
サイトがモバイル表示向けに最適化されていない場合、ブラウザで 300 ミリ秒追加 遅延 イベント ハンドラを実行する前に、タップ後にイベント ハンドラを実行します。その理由は、 ダブルタップでズームを発動する前にユーザーが行おうとしているのかどうかを判別する マウスまたはクリックイベントです
この遅延は実際の入力に影響するため、ページの INP にカウントされます。 レイテンシを短縮できます。ただし、この遅延は技術的には長い Task を参照し、ページの TBT には影響しません。 つまり、TBT スコアが非常に高いページでも、INP が低い可能性があります。
キャッシュ状態と bfcache が INP に及ぼす影響
適切なキャッシュ保存がフィールドの LCP を改善するのと同様に、 向上します
実際には、ユーザーがサイトの JavaScript を 処理されるため、処理にかかる時間を短縮できる 遅延が小さくなります。
bfcache から復元されたページについても同様です。そのような場合、 JavaScript はメモリから復元されるため、処理がほとんど、またはまったく行われない場合があります。 できます。
CLS
ユーザー操作が CLS に及ぼす影響
ラボで測定される CLS では、上記で発生したレイアウト シフトのみが考慮される ただしこれは CLS で実際に使用される 対策です
現場では、CLS はすべての予期しないレイアウトを考慮します。 シフトが コンテンツの持続期間（ユーザーがスクロールまたはスクロールするとコンテンツが変わるなど） レスポンスを返すのが難しくなります
たとえば、ページで画像や iframe に遅延読み込みを レイアウト サイズが異なるため、 ユーザーがページの該当セクションまでスクロールすると移動される。しかし、そうした変化が ユーザーが下にスクロールしたときにのみ発生します（多くの場合、ラボテストでは検出されません）。
マイページのコンテンツ
ターゲット広告や A/B テストなど、パーソナライズされたコンテンツがどのような要素に影響するか 1 つのページに読み込まれます読み込み方法にも影響します。これはパーソナライズが コンテンツは通常後で読み込まれてページのメイン コンテンツに挿入されるため、 調整できます。
ラボでは通常、パーソナライズされたコンテンツなしでページが読み込まれる 一般的な「テストユーザー」向けのコンテンツを含むため、シフトがトリガーされる場合も、されない場合もあります。 目を向けることができます
フィールド データにはすべてのユーザーの経験が含まれるため、 ページで発生するレイアウト シフトの割合は、コンテンツの種類に大きく依存します。 読み込まれます。
キャッシュ状態と bfcache が CLS に及ぼす影響
読み込み中のレイアウト シフトの最も一般的な 2 つの原因は、画像と 上記のようなディメンションのない iframe、ウェブの読み込みが遅い 問題があり、どちらの問題も 初回アクセス時のキャッシュ保存時のエクスペリエンスに影響する 空です。
ページのリソースがキャッシュに保存されている場合、またはページ自体が bfcache を使用すると、ブラウザは通常すぐに画像やフォントをレンダリングできます。 ダウンロードを待機しますこれにより、該当フィールドの CLS 値が下がる可能性があります。 報告されるデータよりも 多くなる可能性があります
結果が異なる場合の対処方法
原則として、特定のページにフィールド データとラボデータの両方がある場合は、 作業の優先順位を決める際に使用しますフィールドデータは 実際のユーザーが体験していることを表すため、 ユーザーが苦労している状況や 対処が必要な問題を正確に理解できます 改善されています。
反対に、フィールド データが全般的に良いスコアを示している場合でも、 まだ改善の余地があることが 示唆されています さらに最適化できる余地がないか確認しましょう。
また、フィールド データは実際のユーザー エクスペリエンスをキャプチャしますが、 サイトを正しく読み込めるユーザーだけにしましょう。検査データは サイトのリーチを広げて ネットワークが低速なユーザーやローエンドのデバイスでもアクセスしやすくなります。
全体として、ラボデータと現場データの両方が効果的な パフォーマンス測定を行えますどちらにも強みと限界があります。 1 つしか使用していない場合 改善の機会を逃している可能性があります 優れたエクスペリエンスを構築できます