Lighthouse vs field data: 修正の効果を確認する

Lighthouseでは修正済みと出ているのに、なぜSearch Consoleはまだ赤いままなのでしょうか？

Lighthouseは、シミュレートされた1台のスマートフォンでページを1回読み込み、そのときのLCPとCLSをレポートします。一方、Core Web Vitalsはfield dataです。高速・低速な端末やネットワーク、キャッシュの有無、あらゆるクリックを含め、実際のChromeユーザーによる過去28日間の訪問の75パーセンタイルを集計しています。そのため、今日Lighthouseで合格した修正でも、Search Consoleに反映されるまでに4週間かかることがあります。Lighthouseを3回実行して結果を比較し、あとはfield dataの推移を追ってください。

修正前後を比較するには、Lighthouseをどう実行すればよいでしょうか？

変更の前後で、同じ方法でLighthouseを実行してください：

1. キャッシュをクリアします。変更後は、キャッシュプラグインとCDNのキャッシュを空にしてください。そうしないと、Lighthouseが古いページをテストしてしまいます。
2. 使用するツールを1つに固定します。コードを使わない場合は、PageSpeed Insightsの「モバイル」タブを使用します。開発者なら、Chrome DevToolsのLighthouseパネルを使い、Deviceを「Mobile」に設定したシークレットウィンドウで実行してください。ブラウザ拡張機能がページに独自のスクリプトを追加してしまうのを防ぐためです。
3. 指摘を受けたURLをテストします。商品テンプレートを変更した場合は、商品ページをテストしてください。
4. 3回実行し、中央値を採用します。
5. まず指摘事項と該当する指標を確認します。指摘が「Passed audits」に移動し、対象の指標（LCP、CLS、Total Blocking Time）の数値が下がっているかを確認してください。スコアの確認は最後です。

何も変えていないのに、なぜスコアが変わるのでしょうか？

テストの実行は、あくまで1回の読み込みに過ぎません。まったく同じ読み込みは2つと存在しません。サーバーの応答速度やネットワーク状況は毎回変動し、広告や同意バナー、A/Bテストも実行ごとに変わることがあります。あるテストページでは、最初のテキストや画像（FCP）が別の実行時より1.5秒早く表示されたことがありました。また別のページでは、何も変更していないのにスコアが96になったり80になったりしました。修正後にスコアが数ポイント上がったとしても、3回実行した中央値を比較しない限り、あてにはなりません。

同一URL（www.bbc.com）で2分間に6回連続で実行したところ、スコアは38、44、41、73、60、53となりました。Lighthouse 13.5.0、モバイル、PageSpeed Insightsと同等のシミュレートされたスロットリング環境です。

DevToolsでのトレース記録

Chromeでページを開き、DevToolsを開いてPerformanceパネルに移動します。歯車アイコンの設定で、Networkを「Slow 4G」、CPUを「4x slowdown」に設定してください。これはLighthouseがモバイルでシミュレートする条件に近い設定です。設定後、「Record」をクリックしてページを再読み込みします。サイドバーの「Insights」タブには、Lighthouseと同じインサイトが表示され、それぞれに関連するリクエストや要素を確認できます。なお、記録を開始する前でも、パネル上には手元のブラウザのLCP、CLS、INPがリアルタイムに表示されます（INPはページ内をクリックすると表示されます）。「Field metrics」の「Set up」をクリックすれば、同じURLに対する実際の訪問者のCrUX数値を並べて表示できます。

なぜLighthouseとSearch Consoleで結果が異なるのでしょうか？

Lighthouseが提供するのはlab dataです。キャッシュが空の状態で、低速な4G回線に接続されたミドルレンジのスマートフォンをシミュレートし、ページを1回読み込みます。読み込み完了後すぐに計測を終了するため、スクロールやタップをしたり、2ページ目を開いたりすることはありません。得られるのはその1回の読み込みに対するLCPとCLSだけであり、INPは計測されません。INPの計測には、実際にクリックする訪問者が必要だからです。

field dataは、実際の訪問者についてChromeが計測したデータです。高速な端末も遅い端末もあり、通信環境もさまざまです。キャッシュが空の初回訪問もあれば、すべてキャッシュされた10回目の訪問もあります。ユーザーはスクロールし、タップし、ページ間を移動します。Googleは、利用統計の共有を許可しているAndroidおよびデスクトップのChromeユーザーからこのデータを収集し、Chrome UX Report（CrUX）としてまとめています。Core Web Vitalsは、過去28日間のこうした訪問データをもとに、各指標の75パーセンタイル（p75）で算出されます。つまり、全体の4回のうち3回の訪問が、少なくともその数値を満たしていたという意味です。

Googleがランキングに使用するのはfield dataです。Lighthouseは、ページが遅い原因を特定し、改善が有効かどうかを検証するためのツールです。両者の結果が食い違っているなら、計測している読み込みの条件が異なるということです。Lighthouseのスコアが緑色（良好）なのにfield dataが悪い場合、シミュレーションよりも低スペックな端末が使われているか、クリックへの応答（INP）が遅いか、あるいはスクロール中にレイアウトのズレが発生しているケースが多く見られます。逆に、スコアが赤（不良）なのにfield dataが良い場合は、実際の訪問者がLighthouseのSlow 4Gよりも高速な端末や通信環境を使っており、キャッシュを保持した状態で再訪しているケースが大半です。

2026年10月26日時点のwww.bbc.com（モバイル）におけるPageSpeed Insightsのレポート。実際の訪問データではLCPが1.2秒でCore Web Vitalsの3指標すべてに合格していますが、同じレポート内のLighthouseの実行結果ではスコアが37、LCPは9.5秒となっています。

PageSpeed Insightsでは、テスト対象のURLに十分な訪問数があればそのURLのfield dataが表示され、訪問数が不足している場合は「Origin」としてサイト全体のデータが表示されます。Search Consoleは類似するURLをグループ化し、各グループを最も悪い指標に基づいて評価します。

実際の訪問者のデータはどこで確認できるでしょうか？

Googleが採用しているfield data（CrUX）は、4つの無料ツールで確認できます：

• PageSpeed Insights: ページ最上部の「実際のユーザーの環境を評価する」セクションに、URLまたはオリジン単位で、過去28日間のp75におけるLCP、INP、CLSが表示されます。
• Search Console: モバイルおよびデスクトップ向けのCore Web Vitalsレポートで、サイト全体の中でどのURLグループが不良（poor）かを把握できます。
• CrUX History report: サイトまたはURLの推移が週ごとのバーで表示され、トレンドを確認できます。
• DevTools: Performanceパネルで、手元の読み込み結果の横に同じ数値を並べて表示できます（初回のみセットアップが必要）。

Chrome経由の訪問数が少ないサイトにはCrUXデータが存在せず、PageSpeed Insightsの最上部には「データなし」と表示されます。しかし、CoreDashならそうしたアクセスも漏れなく計測できます。

CoreDash: どのページの、どの要素か

Googleのfield dataであるCrUXでは、URL単位またはサイト単位で1つのp75しかわかりません。筆者が開発したRUMツールCoreDashは、ページにスクリプトを埋め込むことで、すべての訪問を計測し、LCP、INP、CLSの原因となった要素を特定します。ページ、デバイス、要素でフィルタリングでき、修正を加えたあとは次の訪問から時系列データに変更が反映されます。修正に着手する前にスクリプトを導入しておけば、変更前後の比較が可能です。

CoreDash、acme-pagespeed.com、モバイル、ページごとのp75：他のページのCLSが0であるのに対し、1ページだけCLSが0.92になっています。

修正がSearch Consoleに反映されるまでどれくらいかかるでしょうか？

PageSpeed InsightsとSearch Consoleは過去28日間のデータを表示しており、その対象期間は毎日1日ずつ移動します。PageSpeed Insightsのデータは約2日前のものですが、Search Consoleのデータはさらに数日遅れています。修正を反映してから2週間が経過しても、対象期間内のアクセスの半分は修正前のデータです。対象期間が修正後のアクセスだけで満たされるのは、4週間が経過してからです。詳しいタイムラインについては、28日間の集計ウィンドウの日々の推移をご覧ください。

2026年10月26日時点のSearch Console Core Web Vitalsレポート（モバイル）：最終更新日は10月21日。

CrUX History reportは、同じウィンドウを週単位で表示します。各バーはその時点までの過去28日間を対象としているため、修正の効果が完全に現れるまでにおよそ4本分のバーを要します。

ado-goldkante.de（スマートフォン）のCrUX History report（LCP）：週ごとの「良好」「改善が必要」「不良」の割合。8月中旬に変更を加えた後、「良好」の割合は4本のバーをかけて59%から76%、83%、90%、93%へと上昇し、p75のLCPは3.6秒から1.5秒に短縮されています。

修正を本番に反映したら、Search ConsoleのCore Web Vitalsレポートで該当する問題を開き、「検証を開始」（または「修正を検証」）をクリックしてください。これにより、同じfield dataをもとに、その問題を抱えていたすべてのURLを対象としたSearch Console独自の28日間の検証が始まります。検証中のステータスは「開始」となり、それまでに確認されたすべてのURLで問題がなければ「順調」に変わります。28日間にわたって該当の問題が発生したURLが1つもなければ「合格」となり、1つでも問題が残っていれば「不合格」となります。その場合は該当箇所を修正し、「新しい検証を開始」をクリックします。

実際の訪問者に対して修正が効果を発揮したか、どう確認すればよいでしょうか？

反映が早い順に、次の手順で確認してください：

1. 変更が本番に反映されていることを確認します。ページのソースを表示するか、DevToolsのNetworkパネルで該当のファイルやヘッダーを確認してください。古いバージョンが表示される場合は、キャッシュプラグインやCDNが古いページを返しています。
2. Lighthouseで合格することを確認します。モバイル環境で3回実行し、中央値を採用します（上記の手順）。該当の指摘が「Passed audits」に移っているか確認してください。
3. 実際の訪問者に届いているかを確認します。CoreDashでは、修正直後のアクセスから反映されます。変更したページやテンプレートで絞り込み、デバイスをモバイルに設定して、日ごとの指標と原因要素の推移を追跡します。
4. CrUXに反映されるのを待ちます。PageSpeed Insightsのfield dataや、CrUX History reportのバーグラフが少しずつ動き始めます。効果が完全に現れるのは4週間後です（時間がかかる理由はこちら）。
5. Search Consoleで最終確認します。Core Web Vitalsレポートで該当の問題の「検証を開始」をクリックし、「合格」になるのを待ちます。

Lighthouseでは合格したのに、4週間経ってもfield dataがまったく動かない場合はどうでしょうか？その場合、遅さの原因はLighthouseでは再現できないアクセスにあります。より低価格な端末でのアクセス、遅いクリック、ページの中ほどまでスクロールしたときに生じるレイアウトのズレなどです。Core Web Vitals power hourでは、ページグループごとにfield dataを一緒に精査し、どのページのどの要素がp75の足を引っ張っているかを突き止めます。