クライアントサイトのCore Web Vitals：ラボデータとフィールドデータの追跡方法: Baromio Blog

要約

Core Web Vitalsは、プラグイン、テーマ、タグが変わるたびに変化するため、公開日に行った監査はすぐに古くなります。Lighthouseは再現性のあるラボ測定を提供し、次の実行時に悪化を示します。CrUXは実際のChromeユーザーが体験した内容を28日間の移動平均で示すため、悪化にも改善にもゆっくりとしか反応しません。GoogleはCore Web Vitalsをランキングに使用していますが、関連性が優先されるとしています。重要なページでは両方を追跡しましょう。稼働チェックはどちらも測定しません。測定するのはサーバーの応答速度であり、ページの描画ではありません。

ほとんどのクライアントサイトでは、公開時にPageSpeed Insightsを1回実行したきり、誰も見直しません。その後、プラグインの更新でスクリプトが追加され、クライアントが大きなヒーロー画像をアップロードし、マーケティング担当がタグマネージャー経由でチャットウィジェットを追加します。どれも稼働アラートにはつながりませんが、どれもページを遅くする可能性があります。

3つのCore Web Vitalsとそのしきい値

Largest Contentful Paint (LCP)：最大の画像またはテキストブロックが表示されるタイミングです。良好：2.5秒以下。
Interaction to Next Paint (INP)：クリック、タップ、キー入力にページがどれだけ速く反応するかです。良好：200ミリ秒以下、不十分：500ミリ秒超。INPは2024年3月12日に、First Input Delayに代わってCore Web Vitalsの指標になりました。
Cumulative Layout Shift (CLS)：読み込み中にレイアウトがどれだけずれるかです。良好：0.1以下。

ページがしきい値を満たすのは、ページ読み込みの75%以上がそれを満たす場合です。モバイルとデスクトップで別々に測定されます。

ラボデータとフィールドデータは別の測定です

ラボデータは、PageSpeed Insightsの基盤であるLighthouseから得られます。Lighthouseは、制御されたシミュレーション環境でページを1回読み込みます。そのため再現性があり、デバッグにも、変更直後の悪化の発見にも向いています。ただし限界があります。

誰もページを操作しないため、INPは測定できません。Total Blocking Time (TBT) は妥当な目安になりますが、代わりにはなりません。
スコアは実行ごとに変動します。たとえば広告、A/Bテスト、ネットワークのルーティングが原因です。そのため、1つの数値ではなく傾向を見てください。
パフォーマンススコアには3つの区分があります。0から49は不十分、50から89は改善が必要、90から100は良好です。

フィールドデータは、Chrome UX Report (CrUX) から得られます。使用統計情報の送信と履歴の同期を有効にした、実際のChromeユーザーのデータです。クローラーから得られるものではありません。重要な特性が2つあります。

28日間の移動平均で、毎日更新されます。今日リリースした変更による悪化は今後数週間かけて徐々に現れ、修正が反映されるまでにも同じくらいかかります。
ページ単位のデータを得るには、そのページに十分なChromeのトラフィックが必要です。足りない場合、PageSpeed Insightsはオリジン全体のデータで代替し、小規模なサイトではフィールドデータがまったくないこともあります。

つまり、ラボデータは何かが変わったことをすばやく教えてくれ、フィールドデータは訪問者が実際にどう感じたかを教えてくれます。

稼働チェックがここで役に立たない理由

稼働チェックは、サーバーがリクエストにどれだけ速く応答するかを測定します。ページを描画せず、画像も読み込まず、スクリプトも実行しないため、LCP、INP、CLSは見えません。

ただし、1つの要素は見えます。サーバーの応答時間です。Time to First ByteはFirst Contentful PaintとLCPより前に来るため、サーバーが遅くなれば、その後のすべてが遅くなります。良好なTTFBは0.8秒以下です。ホスティングの変更後に応答時間が上昇傾向にあるなら、Lighthouseを実行する価値があります。

クライアントサイトを遅くする主な原因

以下はよくある原因であり、測定結果ではありません。

スクリプト、スタイル、Webフォントを追加するプラグインやテーマの更新。
タグマネージャーに追加された新しいタグ（チャットウィジェット、ピクセル、ヒートマップ）。
クライアントがフルサイズのままアップロードした画像や動画。
すべてのページで読み込まれるスライダーやページビルダー。
ホスティングの変更（より安いプラン、新しいサーバー、キャッシュの欠如）。

変化を見逃さないための手順

クライアントごとに2、3ページを選びます。トップページと、問い合わせや売上につながるページです。
PageSpeed Insightsでベースラインを記録します。ラボスコア、LCP、TBT、CLS、そしてフィールドデータがあればそれも記録します。
更新のたびにLighthouseを再実行し、その間も定期的に実行します。
フィールドデータは月に1回確認します。変化から数週間遅れて反映されることを忘れないでください。
数か月ごとにクライアントと一緒にタグマネージャーを見直し、誰も使っていないものを削除します。

Baromioでの追跡方法

Lighthouseを定期実行：HTTPモニターまたはキーワードモニターでページ速度を監視をオンにします。BaromioはGoogle PageSpeed Insights経由でLighthouseを実行し（モバイル）、パフォーマンススコア、LCP、FCP、TBT、CLS、Speed Index、リソースの種類別のページ重量を記録します。Free：1 URL、週1回。Pro（月額9 EUR）：5 URL、1日1回。Business（月額29 EUR）：15 URL、1日1回。履歴はプランに応じて7日、30日、または90日間保存されます。
アラート：スコアがLighthouseの「不十分」区分である50を下回るとアラートが届き、その後はさらに15ポイント下がった場合にのみ再度通知されます。スコアが50以上に戻り、かつ15ポイント以上高くなると、回復アラートが届きます。
CrUXフィールドデータ：同じモニターについて、BaromioはそのURLそのもののCrUXスナップショットを毎日保存します。対象はスマートフォン、デスクトップ、全デバイスの合計で、LCP、FCP、CLS、INP、TTFBのp75を、それぞれ良好・改善が必要・不十分の内訳とともに記録します。CrUXにそのURLのデータがない場合、スナップショットは保存されず、「ページ速度」タブにその旨が表示されます。トラフィックの少ないページではよくあることです。
AIアシスタントから：同じフィールドデータは、BaromioのMCPサーバー（get-crux-data）からも取得できます。

出典

web.dev、Web Vitals（2024年10月31日更新）：しきい値と75パーセンタイルのルール。
web.dev、Interaction to Next Paint becomes a Core Web Vital on March 12（2024年1月31日）。
web.dev、Interaction to Next Paint (INP)（2025年9月2日更新）：INPの区分、TBTは目安になるが代わりにはならないこと。
web.dev、Time to First Byte (TTFB)（2025年11月18日更新）：0.8秒のしきい値、TTFBはFCPとLCPより前に来ること。
Google Search Central、Understanding page experience in Google Search results（2026年9月22日更新）。
Chrome for Developers、CrUX methodology（2024年6月20日更新）：どのユーザーのデータが含まれるか。
Chrome for Developers、CrUX API（2025年2月11日更新）：28日間の移動平均、毎日の更新。
Google、About PageSpeed Insights（2024年10月21日更新）：ラボデータとフィールドデータの違い、オリジン全体のデータへのフォールバック。
Chrome for Developers、Lighthouse performance scoring：スコアの区分と変動。

クライアントサイトのCore Web Vitals：ラボデータとフィールドデータの追跡方法