Core Web Vitalsの計測はどこで？実際の訪問と試験で数字が違う理由

Core Web Vitalsの数字が測る場所ごとに違うのは、実際の訪問を集めたデータと、その場で1回読み込む試験とで、測っているものが違うからです。この記事は、PageSpeed InsightsやSearch Consoleの「ウェブに関する主な指標」、ChromeのLighthouseで数字を見比べて、どれを信じればいいのか分からなくなった個人ブロガーに向けて書きました。読み終えると、手元の数字がどちらの種類なのかを見分け、どこから見ればいいかを自分で決められます。

根拠にしたのは、web.dev の「ウェブに関する主な指標」「Web Vitals の測定を始める」「ラボデータと実環境データに相違が生じる理由（および対処方法）」、Googleの「PageSpeed Insights について」、Chromeの開発者向けサイトの「PageSpeed Insights で Chrome UX レポートデータを表示する方法」と[パフォーマンス]パネルの説明、Search Consoleヘルプの「Core Web Vitals レポート」、Google 検索セントラルのページ エクスペリエンスの説明で、2026年10月20日に日本語版と英語版を読み比べました。ページ エクスペリエンスの説明を除く7ページの日本語版はAIによる翻訳と注記されているので、引用は英語版と同じ意味かを見て、訳が崩れている文は英語版を私が訳しています。

私はこの記事のために、自分のブログをPageSpeed InsightsやLighthouseで測ってはいません。画面や項目の名前は上の文書に書かれている字で呼んでいて、数字の例は web.dev に載っている例だけを使います。見る順番は私の決め方で、Googleの文書にこの順で書かれているわけではありません。

結論:判定は実際の訪問のデータで、試験は原因探しに使う

文書に書かれていることと、そこから私が決めている見方をまとめると、次の4つです。

• Core Web Vitalsを測る道具は、実際の訪問のデータ(フィールドデータ)と、その場の試験(ラボデータ)の2種類。Search Consoleのレポートと PageSpeed Insightsの上の欄は前者、PageSpeed Insightsの下の欄とLighthouseは後者です
• 数字が違うのは正常。実際の訪問のデータは28日間の分布、試験は決まった条件での1回で、INPはLighthouseのような操作をしない試験では測れません
• 良し悪しは実際の訪問のデータで決める。web.dev は、推奨の基準値を満たすかをGoogleが判断するのに使うのは実際の訪問のデータだと書いています
• 個人ブログでは、Search Console → PageSpeed Insightsの上の欄 → 試験の順に見る。直したら試験で手元の変化を確かめ、結果は実際の訪問のデータが溜まるのを待ちます

Core Web Vitalsはどこで計測できる？実際の訪問のデータと試験の道具

web.dev のウェブに関する主な指標は、Core Web Vitalsを測る道具を「フィールド ツール」と「ラボツール」の2つの表に分けています。フィールドの表に並ぶのは、Chrome ユーザー エクスペリエンス レポート(CrUX)、Chrome DevTools、PageSpeed Insights、Search Console の Core Web Vitals レポートで、どれもLCP・INP・CLSの3つを測れます。英語版によれば、CrUXが実際の訪問者のデータを集めていて、そのデータがDevTools・PageSpeed Insights・Search Consoleのレポートの元になっています(日本語版はこの箇所を「…などのツールも利用できます。」と訳していて、データの元だという意味が弱くなっています)。ラボの表に並ぶのはChrome DevToolsとLighthouseで、Lighthouseの行はINPだけが測れない印になっていて、TBTを使うよう添えられています。TBTは手がかりになる指標で、INPそのものではありません。

個人ブログで目にする場所を、この2種類に当てはめると次のようになります。

PageSpeed Insightsの期間と更新について、Chromeの開発者向けサイトのPageSpeed Insights で Chrome UX レポートデータを表示する方法は、オリジンのパフォーマンスの概要の節で「…PSI は過去 28 日間を含む新しいデータを毎日集計します。そのため、今日表示される結果は明日は異なる可能性があります。」と書いています。英語版のよくある質問には、PageSpeed Insightsが出すのは最新の日ごとの集計だけなので、推移までは分からないことがある、ともあります(私の訳。日本語版はここを「直近の 1 日分の集計データのみ」と訳していて、1日分のデータしか使っていないように読めてしまいます)。推移を見るなら、日ごとのURLの数を示すSearch Consoleのグラフのほうです。

[パフォーマンス]パネルについては、パフォーマンス パネルの説明によると、開くと自分の端末で読み込んだときのLCPとCLSがすぐに出て、ページを操作するとINPも出ます。さらに、[パフォーマンス] > [次のステップ] > [フィールド データ] の [設定] から、CrUXの実際の訪問のデータを取ってきて自分の数字と並べられます(設定のときにプライバシーの開示を確かめるよう書かれています)。並べたときに自分の環境がユーザーとずれていれば、[ローカル テスト条件を考慮する] に、回線やCPUを遅くする設定の勧めが出る、とあります。

ほかに、CrUXの履歴を見るダッシュボード(CrUX Vis)や、自分のブログに計測のコード(web-vitals という JavaScript のライブラリ)を入れて実際の訪問を自分で集める方法もあります。「Web Vitals の測定を始める」の英語版は、CrUXをもとにした道具に加えて自分で集めるデータを足すことを強く勧めています("we strongly recommend supplementing it with your own RUM")。コードを入れる作業になるので、この記事では入れ方までは扱いません。

なぜ測る場所で数字が違うのか

Web Vitals の測定を始めるは、はっきり「RUM データとラボデータの間には常に差異が生じます。」と書いています(RUM は実際の訪問を集めたデータのことです)。違いの元は、私の整理では次の3つです。

1. 実際の訪問のデータは分布で、試験は1回

web.dev のラボデータとフィールドデータの違いの解説は、いちばん大事な点としてこう書いています。

フィールドデータについて理解しておくべき最も重要なことは、フィールドデータは単なる数値ではなく、数値の分布であるということです。
— web.dev「ラボデータと実環境データに相違が生じる理由（および対処方法）」

速い回線のパソコンで開いた人も、遅い回線の古いスマホで開いた人もいて、その全部が実際の訪問のデータです。そこから1つの数字を出すときは、75パーセンタイル(4回に3回の訪問がその値か、それより良い値)を使います。一方、試験は、1台の端末を1つの回線につないで、1つの場所から読み込んだ1回の結果です。同じ解説には、同じページで実際の訪問のLCPの75パーセンタイルが1.8秒、試験のLCPが3.0秒だった例が載っていて、試験の3.0秒も、分布の中にありうる正しい値の1つだと説明されています。GoogleのPageSpeed Insights についてのよくある質問も、フィールドデータはさまざまな端末と回線の実際のユーザーの記録で、ラボデータは1台の端末と決まった回線で読み込みを模したものなので、値が違うことがある、と答えています。

2. まとめる単位と期間が違う

同じ実際の訪問のデータでも、Search ConsoleとPageSpeed Insightsでは数字が合わないことがあります。Search Consoleのヘルプは、レポートがURLグループでまとめ、PageSpeed Insightsは基本的に1つのURLのデータを出すと説明したうえで、こう書いています。

PageSpeed Insights の特定の URL の統計情報は、Core Web Vitals のグループの結果と一致しないことがあります。個々の URL がグループ内で外れ値になっていることがあるためです。
— Search Console ヘルプ「Core Web Vitals レポート」

PageSpeed InsightsはURLの後ろのパラメータを外して通常のURLにまとめる、という違いもあります。そして期間です。どちらも過去28日分ですが、PageSpeed Insightsは毎日集計し直した最新の値で、Search Consoleはグラフに日ごとの数が並びます。直した翌日にPageSpeed Insightsの上の欄が少し動いても、28日分のうち1日分が入れ替わっただけ、ということがある、と私は読んでいます。

なお、「Web Vitals の測定を始める」の英語版は "Search Console reports performance data on a per-page basis."(ページ単位で報告する)と書いていて、Search Consoleのヘルプの「URL グループ」の説明と食い違っています。この記事では、レポートの単位はSearch Console自身のヘルプの説明に合わせます。レポートが記事1本ずつではなくグループで判定する仕組みはウェブに関する主な指標レポートの見方は？URLグループとデータなしに書きました。

3. 試験では測れないもの、測りにくいものがある

「Web Vitals の測定を始める」は、試験で集めるときに気をつける点を指標ごとに挙げています。要約すると次のとおりです。

• INP:読者の操作が要るので、試験では測れない、と書かれています。試験で見る目安として勧められているのはTBT(読み込み中に操作へ応答できなかった時間の合計)ですが、計算のしかたはINPと違い、INPそのものではありません。なお、同じページはDevToolsの[パフォーマンス]パネルもラボの道具に挙げていて、パネルの説明によると、そこでは自分でページを操作するとINPも出ます。読者の操作ではなく、手元での自分の操作の値です
• CLS:多くの試験はページを読み込むだけで操作しないので、読み込み中のずれしか拾いません。スクロールしたあとのずれまで入る実際の訪問のデータより、人為的に低く出ることがあります
• LCP:リダイレクトやサーバーへの接続、キャッシュの有無、画面の大きさで見える中身が変わること、Cookieのバナーなどで、試験と実際の訪問とで値が違うことがあります

ラボデータとフィールドデータの違いの解説も、実際の訪問ではキャッシュが効いていたり、戻る・進むで一瞬で表示されたりするぶん、実際の訪問のほうが速く出ることがある、と書いています。試験の数字のほうが悪く出るのは、珍しいことではありません。INPの数字が試験に出ない理由と、TBTとの関係はINPの改善とは？サーチコンソールで「改善が必要」と出たら遅い操作を探すに、試験でCLSが小さく出るときの見方はCLSの改善とは？PageSpeed Insightsでずれる場所を探すに書きました。PageSpeed Insightsの下の欄の点数が、ページを変えていなくても測るたびに変わる理由はPageSpeed Insightsの見方は？下の点数より上の欄を先に見るにあります。

どの数字を信じる？判定に使われるのは実際の訪問のデータ

「Web Vitals の測定を始める」は、実際の訪問のデータについてこう書いています。

RUM データは、サイトが推奨されるウェブに関する主な指標の基準値を満たしているかどうかを Google が判断するために使用されます。
— web.dev「Web Vitals の測定を始める」

英語版は "RUM data is what Google uses to determine whether a site meets the recommended Core Web Vitals thresholds." です。ここで言っているのは、基準値を満たしているかの判断のことです。「ウェブに関する主な指標」も「ラボでの測定は優れたエクスペリエンスを提供するために不可欠ですが、フィールドでの測定の代わりにはなりません。」と書いています。そして、両方の数字があるときの扱いは、ラボデータとフィールドデータの違いの解説にこうあります。

一般に、特定のページについてフィールドデータとラボデータの両方がある場合は、フィールドデータを使用して優先順位を付ける必要があります。
— web.dev「ラボデータと実環境データに相違が生じる理由（および対処方法）」

同じ解説は続けて、実際の訪問のデータが全体に良くても、試験に改善の余地が出ているなら、さらにできることを確かめる価値がある、とも書いています。実際の訪問のデータは、ページを読み込めた人の分しか入らないので、遅い回線や性能の低い端末の人に届きやすくする手がかりは試験のほうにある、という説明です。試験の数字を見なくていい、という話ではありません。

判定の線は、Search Consoleのヘルプの表では、LCPが2.5秒以下で良好・4秒を超えると低速、INPが200ミリ秒以下で良好・500ミリ秒を超えると低速、CLSが0.1以下で良好・0.25を超えると低速で、その間が改善が必要です。この線と比べるのは、実際の訪問の75パーセンタイルの値です。試験の数字を同じ線に当てはめて「良好」と読んでも、それは1回の試験の結果です。3つの指標を並べた表はウェブに関する主な指標レポートの見方は？にあります。

個人ブログでCore Web Vitalsを見る場所と順番

ここからは私の決め方です。その前に1つだけ。速度の数字より先に、記事の表示回数・掲載順位・クリック率を見る順番があり、それはページ表示速度はSEOに効くか、Core Web Vitalsより先に見る3つに書きました。そちらが済んでいて、速度を見る段階に来たときの順番です。なお、重いと感じるページが決まっていて、読者のために軽くしたいだけなら、そのURLをPageSpeed Insightsに入れるところからでかまいません(ページ表示速度はSEOに効くかのよくある質問と同じです)。

1. Search Consoleの「ウェブに関する主な指標」で、サイト全体を見る。「データがありません」なら、このレポートで良し悪しを判断する段階ではありません。「低速」があればそこから、「改善が必要」だけなら急ぎません
2. 問題の出たグループの代表のURLを、PageSpeed Insightsに入れて上の欄を見る。端末はSearch Consoleで問題が出たのと同じほうを選び、出ている数字が記事のものか、サイト全体のものかも確かめます。代表のURLが合格なら、同じグループのほかのURLも入れてみます
3. 上の欄で良好でない指標があれば、原因は試験で探す。PageSpeed Insightsの下の欄や、Chromeの[パフォーマンス]パネルで、その指標に関係するところだけを見ます。上の欄が合格なら、下の欄の点数が赤くても急ぎません
4. 直したら、試験で手元の変化を確かめてから、Search Consoleで[トラッキングを開始]を押す。結果は、直したあとのページを実際の読者が開き、データが溜まるのを待って見ます

4つ目の流れだけは私の考えではなく、Search Consoleのヘルプが「技術者以外のユーザー」向けに書いている手順と同じです。英語版の手順は、まず「低速」から優先順位を付け、外部のテストで直し方の提案を見て、外部のテストで直したかを確かめ、直ったと思ったら問題の詳細ページで[トラッキングを開始]を押して検証を追う、という順です(私の訳)。外部のテストとしてヘルプが挙げているのは、AMP以外のページではPageSpeed Insightsで、ChromeのLighthouseも使える、とあります。トラッキングで何が起きて、何が起きないかはウェブに関する主な指標レポートの見方は？URLグループとデータなしに書きました。

3つ目で何を見るかは、指標ごとに記事を分けています。LCPならLCPの改善とは？PageSpeed Insightsで4つの内訳を確かめる、INPなら上のINPの記事、CLSなら上のCLSの記事です。下の欄に並ぶ項目の名前が古い解説と違って迷うときは「レンダリングをブロックしているリクエスト」とは？PageSpeedの分析情報を見てください。Core Web Vitalsには入らないFCPが赤や黄色で出ているときに急ぐかどうかはFCPの改善は必要？Core Web Vitals外、急ぐかはLCPで決めるに書きました。

なお、「Web Vitals の測定を始める」の英語版は、測って直し始めるための1つの行動を探しているなら、Chrome DevToolsの[パフォーマンス]パネルを使うよう勧めています("we recommend using the Chrome DevTools Performance panel")。私がSearch Consoleから始めるのは、ヘルプの説明どおり、このレポートがサイトの複数のページに共通する問題を見つけるためのもので、ブログ全体のどこに問題があるかを先に1画面で見られるからです。[パフォーマンス]パネルは、開いた1ページを手元で測る道具なので、2つ目と3つ目の段階で使っています。

数字が食い違ったときの読み方

よく出る食い違いを、ここまでの3つの違いに当てはめると次のようになります。右の列は私の読み方です。

4行目について、PageSpeed Insightsで実際の訪問のデータが出ないとき、Chromeの開発者向けサイトのガイドは、それでもLighthouseのラボデータでページのパフォーマンスを推定できる、と書いています。推定は推定なので、私はこの段階では「おおよその見当」として扱っています。

計測した数字は順位にどこまで効くか

Google 検索セントラルのページ エクスペリエンスの説明は「Google のランキング システムでは Core Web Vitals が使用されます。」と書く一方、レポートやサードパーティのツールで良い結果が出ても「…Google 検索の検索結果で上位に表示されることが保証されるわけではありません。」とも書いています。この記事も、その両方を書いたウェブに関する主な指標レポートの見方は？URLグループとデータなしの結論を越えません。公式の文言の読み比べはページエクスペリエンスは順位に効く？名指しはCore Web Vitalsだけにあります。

この記事で引いた公式の文書は、web.dev の3ページ、Googleの「PageSpeed Insights について」、Chromeの開発者向けサイトの2ページ、Search Consoleのヘルプ、Google 検索セントラルのページ エクスペリエンスの説明の8ページです(2026年10月20日に日本語版と英語版の本文を取得して照合しました)。

よくある質問

PageSpeed Insightsの上の欄の数字が、昨日と違います

上の欄は過去28日分を毎日集計し直すので、日によって少しずつ動きます。Chromeの開発者向けサイトのガイドも、今日の結果と明日の結果は違うことがある、と書いています。直した効果かどうかを1日の違いで決めず、推移はSearch Consoleのグラフで見るのが、私のやり方です。

Lighthouseで良好なら、Search Consoleでも良好になりますか

そうとは限りません。Lighthouseは決まった条件での1回の試験で、INPは測りません。Search Consoleの判定は、実際の訪問の28日分の75パーセンタイルで決まります。web.dev も、ラボでの測定はフィールドでの測定の代わりにはならないと書いています。

アクセスが少なくて、実際の訪問のデータが出ません。どこで計測すればいいですか

PageSpeed Insightsの下の欄やLighthouseの試験で、おおよその見当はつけられます。ただ、Search Consoleのレポートで「データがありません」と出ている段階は、このレポートで良し悪しを判断する段階ではありません。速度より先に表示回数・掲載順位・クリック率を見る理由は、上の表示速度の記事に書いたとおりです。

自分のブログに計測のコードを入れたほうがいいですか

入れる価値はありますが、私はまずSearch ConsoleとPageSpeed Insightsで足りるかを見てから考えています。web.dev は、CrUXをもとにした道具に加えて、自分で集めるデータを足すことを強く勧めていて、自分で集めれば、より細かく、早く結果が分かるという理由を挙げています。ただ、コードを入れて、集めたデータを送る先も用意する作業になります。

まとめ

• Core Web Vitalsを測る道具は、実際の訪問のデータ(Search Consoleのレポート、PageSpeed Insightsの上の欄)と、その場の試験(PageSpeed Insightsの下の欄、Lighthouse)に分かれる。DevToolsの[パフォーマンス]パネルは手元の試験で、設定すれば実際の訪問のデータも並べて出る
• 数字が違う理由は、分布か1回か、まとめる単位と期間、試験で測れない・測りにくいもの(INPはLighthouseのような操作をしない試験では測れず、CLSは試験で低く出やすい)の3つ
• web.dev は、推奨の基準値を満たすかをGoogleが判断するのに使うのは実際の訪問のデータだと書き、両方あるなら一般にフィールドデータで優先順位を付けるとしている。ただし、試験に出た改善の余地を確かめる価値もある、と続けている
• Search ConsoleとPageSpeed Insightsの上の欄が合わないのは、グループと1つのURLの違い。どちらも過去28日分だが、PageSpeed Insightsは毎日集計し直した最新の値
• 個人ブログでは、Search Console → PageSpeed Insightsの上の欄 → 試験の順に見る(私の決め方)。直したら試験で確かめてから[トラッキングを開始]を押す流れは、Search Consoleのヘルプの手順と同じ
• 順位については、Googleは Core Web Vitals をランキングで使うと書く一方、良い結果でも上位表示は保証されないとも書いている

数字が食い違って見えたら、まず、それが実際の訪問のデータなのか、試験なのかを見分けてください。それだけで、どれを信じればいいかの迷いはほとんど片付きます。急いで直す数字が無かったなら、その時間は、すでに検索結果に出ている記事の中身やタイトルを見直すほうに回せます。

この先は、私が作ったツールを宣伝する段落です。

計測して急ぐ数字が無かったら、リライトレーダーに記事のURLを入れて、見出しや本文の直す点を見てみてください。もっと具体的に深掘りするなら、Search Consoleのデータを入れると、どの記事から直すかの順番まで出ます。URLの診断で送るのは入れたURLだけで、本文は保存しません。Search Consoleの「ページ」タブのエクスポートをZIPのまま置くと、掲載順位4.0〜20.5位のページから手を入れる候補を順に並べます。判定と、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで3記事分(候補が4件以上のときだけご案内)、生成の期限は購入から90日間で、月額課金はありません。CSVはブラウザの中で読み、送るのは候補ページのURLと、診断カードを出すときの狙いキーワード・順位・表示回数・CTRだけです。

⚠️ URLの診断は本文だけを読み、順位・表示回数・CTRは使いません(それらを使うのはSearch Consoleのデータを入れたときです)。このツールは、表示速度もCore Web Vitalsも計測しないので、計測はこの記事で挙げたGoogleの道具で行ってください。