PageSpeed Insightsの数字は「ラボ」と「過去28日の利用者」で別物 ── スコアの揺れとフィールドデータの読み方を確認する13項目（2026年10月時点）

目次

1. 01 何が書かれているか — PageSpeed Insightsの画面には、性格の違う2種類の数字が並ぶ。測った1回の「ラボ」と、過去28日の実際の利用者の「フィールド」
   1. 画面は2つの部分に分かれる
   2. フィールドデータは、過去28日のChromeの利用者から来る
   3. フィールドが出ないことがある。そのときの順序
   4. 画面の段階分けと、合格の条件
2. 02 なぜ・背景 — 数字は、測った環境と見ている人の違いで、別の数字になる
   1. スコアが測るたびに変わる理由は、公式が書いている
   2. Lighthouseの文書は「複数回測る」と書く
   3. ラボとフィールドが食い違うことは、公式が先に断っている
   4. 75パーセンタイルは「いちばんつらい体験」を見るための選び方
   5. 「どの数字で判断するか」は、Googleのページ体験の文書が答えに近い
3. 03 この記事に出てくる用語
   1. CrUXに載る条件
4. 04 型別 — 適用範囲・公式が書いていないこと・読む順番
   1. 適用範囲: 画面のどの部分が、どちらのデータか
   2. 公式が書いていないこと
   3. 読む順番
   4. フィールドが出ないページの扱い
5. 05 明日、自社のサイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — データの出どころごとの、公式の言い方と使い分け
   1. 速さを見る道具を、データの出どころで並べる
   2. 自社で集めるという選択肢
   3. ラボのスコアを、どう使うか
7. 07 当サイトの例 — 2026年9月30日に、記事ページの遅さを、測ってから直した。10月20日は、PSIの上限で測れなかった
   1. 確かめられたこと: 遅さは、原因を測ってから直した
   2. 確かめられなかったこと: PSIが、測れない日がある
   3. 同じ揺れは、別の診断ツールでも起きた
8. 08 このテーマは、ここまで
   1. 2019年9月19日 — Lighthouseのスコアの資料の表記上の更新日
   2. 2022年7月18日 — ラボとフィールドの違いの記事の更新日
   3. 2024年6月20日 — CrUXの方法の資料の更新日
   4. 2024年10月21日 — PSIの説明の更新日
   5. 2026年9月22日 — ページ体験の文書の更新日
   6. 2026年10月20日 — この記事の確認日
9. 09 この記事のまとめ

01 何が書かれているか — PageSpeed Insightsの画面には、性格の違う2種類の数字が並ぶ。測った1回の「ラボ」と、過去28日の実際の利用者の「フィールド」

PageSpeed Insightsを開くと、大きな丸いスコアと、実際の利用者の数字と、改善の提案が1つの画面に並ぶ。同じ画面の数字でも、測り方が別である。公式の資料を、画面の上から順に読む。指標そのものの意味（LCP・INP・CLSの中身）は、Core Web VitalsのLCP・INP・CLSは「良好・改善が必要・不良」の3段階で判定される ── 自分のサイトで確認する14項目（2026年9月時点）と、Cloudflareの実ユーザー計測が、LCPを4段階・INPを3段階に分けて見せるようになった。直す前に、いちばん長い段階を決める ── 自社の遅さがどの段階で起きているかを確認する13項目（2026年10月時点）で扱っているので、この記事では「画面の読み方」に絞る。

画面は2つの部分に分かれる

Googleの「About PageSpeed Insights」は、ページの下の表記が「Last updated 2024-10-21 UTC」である。この資料は、画面が出す2つのデータを、こう書く。

"PSI provides both lab and field data about a page. Lab data is useful for debugging issues, as it is collected in a controlled environment. However, it may not capture real-world bottlenecks. Field data is useful for capturing true, real-world user experience - but has a more limited set of metrics."

（訳: PSIは、ページについて、ラボデータとフィールドデータの両方を提供する。ラボデータは、管理された環境で集められるので、問題の調査に役立つ。ただし、現実の場面での詰まりを捉えられないことがある。フィールドデータは、現実の利用者の体験を捉えるのに役立つが、指標の種類は限られる。）

ラボは調べるための数字、フィールドは実際の体験を表す数字という、役割の分担である。この記事では、以後この2つを区別して書く。

フィールドデータは、過去28日のChromeの利用者から来る

同じ資料は、フィールドの出どころを、こう説明する。

"PSI reports real users' First Contentful Paint (FCP), Interaction to Next Paint (INP), Largest Contentful Paint (LCP), and Cumulative Layout Shift (CLS) experiences over the previous 28-day collection period."

（訳: PSIは、直前の28日間の収集期間における、実際の利用者のFCP・INP・LCP・CLSの体験を報告する。）

この数字は、Chrome UX Report（CrUX）のデータで、直前28日の積み重ねである。今日サイトを直しても、フィールドの数字は、すぐには変わらない。

フィールドが出ないことがある。そのときの順序

資料は、データが足りないときの動きを、段階で書いている。

"A page might not have sufficient data if it has been recently published or has too few samples from real users. When this happens, PSI will fall back to origin-level granularity, which encompasses all user experiences on all pages of the website. Sometimes the origin may also have insufficient data, in which case PSI will be unable to show any real-user experience data."

（訳: ページは、公開されて間もない場合や、実際の利用者からの標本が少なすぎる場合に、十分なデータを持たないことがある。そのときPSIは、サイトのすべてのページのすべての利用者の体験を含む、オリジン単位の粒度に切り替わる。オリジンもデータが不十分で、PSIが実際の利用者の体験のデータを出せないこともある。）

順序は3段階で、そのページの数字 → サイト全体の数字 → 何も出ないである。自社のページで「実際のユーザー体験のデータがない」と出ても、それは速い・遅いの判定ではなく、データの量の問題である。

画面の段階分けと、合格の条件

PSIは、体験を「Good・Needs Improvement・Poor」の3段階に分け、公式の資料は基準の表を載せている。表の数字は、この資料の値を写したものである。

Core Web Vitals（LCP・INP・CLS）の合否は、資料がこう書く。

"For aggregations with sufficient data in all three metrics, the aggregation passes the Core Web Vitals assessment if the 75th percentiles of all three metrics are Good."

（訳: 3つの指標のすべてで十分なデータがある集計は、3つの指標の75パーセンタイルがすべてGoodなら、Core Web Vitalsの評価に合格する。）

INPのデータが足りない場合は、LCPとCLSの2つだけで判定する、とも書かれている。LCPかCLSのデータが足りなければ、評価はできない。

02 なぜ・背景 — 数字は、測った環境と見ている人の違いで、別の数字になる

スコアが測るたびに変わる理由は、公式が書いている

Lighthouseのスコアの決まり方を書いたChromeの資料「Lighthouse performance scoring」は、スコアが揺れる原因を、こう挙げる（ページの下の表記は「Last updated 2019-09-19 UTC」で、本文には新しい版の重みの表も載っている。日付と中身が合っていない可能性があるが、理由は確かめられなかった）。

"When your Performance score fluctuates it's usually because of changes in underlying conditions."

（訳: パフォーマンスのスコアが揺れるのは、たいていは、土台の条件が変わったからだ。）

挙げられている原因は、次の5つである。

• A/Bテストや、配信される広告の変化
• インターネットの通信経路の変化
• 性能の違う端末での測定（高性能のデスクトップと、低性能のノートPCなど）
• JavaScriptを差し込み、通信を足したり変えたりするブラウザの拡張機能
• ウイルス対策のソフト

PSIの資料のFAQも、同じ方向である。「何も変えていないのに、スコアが毎回変わる」という問いに、通信環境・端末の性能・端末の資源の取り合いを、よくある原因として挙げている。同じページでも、条件が少し動けば数字が動く。これは異常ではなく、仕組みである。

Lighthouseの文書は「複数回測る」と書く

Lighthouseのリポジトリにある「Score Variability」の文書（GitHub上の文書で、日付の表記は見つからなかった）は、冒頭の要約が、こうである。

"Run Lighthouse multiple times and beware of variability before drawing conclusions about a performance-impacting change."

（訳: 性能に影響する変更について結論を出す前に、Lighthouseを複数回実行し、ばらつきに注意せよ。）

1回の数字で「直った」「悪くなった」と決めない。05章の5番目と6番目が、この対処に当たる。

ラボとフィールドが食い違うことは、公式が先に断っている

PSIの資料のFAQには、「ラボとフィールドが食い違うのはなぜか」という問いがある。要点は、フィールドが「過去の実績」で、ラボが「1台の端末・決まった通信条件の模擬」であることだ。web.devの記事「Why lab and field data can be different (and what to do about it)」（Last updated 2022-07-18 UTC）は、さらに踏み込む。

"The most important thing to understand about field data is that it is not just one number, it's a distribution of numbers."

（訳: フィールドデータについて最も大切なのは、それが1つの数字ではなく、数字の分布だということだ。）

画面の上に出る1つの数字は、分布の中の1点である。次の節の75パーセンタイルが、その1点の選び方である。

75パーセンタイルは「いちばんつらい体験」を見るための選び方

PSIの資料は、75パーセンタイルを選ぶ理由を、こう書く。

"The 75th percentile is selected so that developers can understand the most frustrating user experiences on their site."

（訳: 75パーセンタイルが選ばれているのは、開発者が、サイトで最も不満の出やすい利用者の体験を知るためだ。）

平均でも中央値でもなく、4人に1人が経験する遅さ以上の数字が、画面の上に出る。

「どの数字で判断するか」は、Googleのページ体験の文書が答えに近い

Googleの「Understanding page experience in Google Search results」（Last updated 2026-09-22 UTC）は、検索での扱いを、こう書く。

"Core Web Vitals are used by our ranking systems."

（訳: Core Web Vitalsは、Googleのランキングシステムで使われている。）

"Keep in mind that getting good results in reports like Search Console's Core Web Vitals report or third-party tools doesn't guarantee that your pages will rank at the top of Google Search results; there's more to great page experience than Core Web Vitals scores alone."

（訳: Search ConsoleのCore Web Vitalsのレポートや第三者のツールのようなレポートで良い結果が出ても、ページが検索結果の上位に出ることは保証されない、と心に留めておくこと。優れたページ体験には、Core Web Vitalsのスコアだけでは足りないものがある。）

この資料は続けて、「SEOのためだけに完璧なスコアを目指すことは、時間の使い方として最良ではないかもしれない」という趣旨も書いている。筆者が読んだ範囲では、PSIのスコア（90以上など）が上がれば順位が上がる、と書いた文は、見つからなかった。

03 この記事に出てくる用語

CrUXに載る条件

CrUXの方法を書いた「CrUX methodology」（Last updated 2024-06-20 UTC）は、ページがデータに入る条件として、公開されて見つけられること（検索エンジンと同じ基準）と、十分な訪問者がいることを挙げる。人気の基準は「An exact number is not disclosed」（訳: 正確な数字は公開されていない）と書かれている。また、"At this time, you cannot manually submit pages or origins for inclusion."（訳: 現時点では、ページやオリジンを手で申請して含めてもらうことはできない。）とも書く。

04 型別 — 適用範囲・公式が書いていないこと・読む順番

適用範囲: 画面のどの部分が、どちらのデータか

画面の部分を、データの種類で整理する。

フィールドの数字は、更新の頻度についても公式が書く。「PSIのフィールドは毎日更新され、BigQueryのCrUXのデータは月に1回の更新で、オリジン単位に限られる。どちらも直前28日分」という趣旨である。

公式が書いていないこと

• CrUXに載る「十分な訪問者」の具体的な人数（資料は「公開されていない」と書く）
• PSIのスコアと、検索順位の関係を示す数字（筆者が読んだ範囲では、見つからなかった）
• PSIの資料の指標の一覧と、Lighthouseのスコアの重みの表が食い違っている理由（PSIの資料は一覧にTime to Interactiveを挙げるが、スコアの資料の新しい版の重みの表には、その指標がない）

3番目は、資料の日付の古さが関わるかもしれないが、確かめられなかった。測った地域は、公式のFAQが、結果の環境のブロックで確かめられると書いている。Lighthouseの版が同じブロックに出るかは、確かめられなかった。

読む順番

画面は、上から下へ、現実から調査への順で読む。

• まず、フィールドがあるか、ページ単位かサイト全体かを見る
• あれば、3つの75パーセンタイルと、合否を見る
• 次に、ラボのスコアと各指標を、複数回の測定で見る
• フィールドとラボの差が大きいときは、LCPの要素と、広告・個人化の有無を見る
• 改善したら、ラボは同じ日に、フィールドは28日後に見る

フィールドが出ないページの扱い

フィールドが出ないページでは、判断の材料が、ラボの数字と、サイト全体のフィールドの数字になる。その場合の数字は、「そのページの実績」ではないと、記録に書く。05章の2番目と3番目が、その確認である。

05 明日、自社のサイトで確認できることチェックリスト

以下は、PageSpeed Insightsの画面を、ラボとフィールドに分けて読み、スコアの揺れを数字で見て、記録の形をそろえるための13項目である。1〜4番目はフィールドの読み方、5〜8番目はラボの揺れと食い違い、9〜11番目は測る条件、12〜13番目は記録と確認日である。チェックの状態はブラウザに保存され、サーバーには送られない。

• 自社のトップページのURLをPageSpeed Insightsに入れてモバイルで測り、「実際のユーザー体験」の欄があるか、ないかを書き留める
• 欄がある場合、数字がそのページのものか、サイト全体のものかを、画面の表示で確かめて、記録の隣に書く
• 欄がない場合は、同じサイトの別のページを2ページ測り、サイト全体の数字だけは出るかを確かめて書く
• フィールドのLCP・INP・CLSの75パーセンタイルの値を3つ書き出し、公式の基準（2500ms・200ms・0.1）と並べて、どれがGoodかを丸で示す
• 同じURLをモバイルで3回、数分あけて続けて測り、スコアの最大と最小を書き出して、差を計算する
• 3回のスコアの中央値を、その週の基準値として記録し、LCP・TBT・CLSの値を3つ、スコアの隣に並べて書く
• モバイルとデスクトップを1回ずつ測り、スコアの差と、LCPの要素が同じものかを比べる
• フィールドとラボのLCPが1秒以上離れているとき、ラボのLCPの要素を書き出し、自分のスマートフォンでページを開いて、同じ要素かを確かめる
• 測った日付・時刻・端末・通信の条件を、数字の隣に書く記録表を、1つのシートで作る
• ページのソースを開き、広告のタグ・A/Bテストのタグ・利用者ごとに内容が変わる部分の数を書き出し、記録表に「揺れやすい」と注記する
• 拡張機能を切ったシークレットウィンドウで、ブラウザのLighthouseを1回実行し、PSIのスコアと並べて、差を書く
• 改善をしたら、ラボの再測定日と、フィールドの確認日（28日後）を、カレンダーに2つ登録する
• 毎週決まった曜日に、測るページを3つ決めて、フィールドの有無・75パーセンタイル3つ・ラボのスコアの中央値を、1行で記録表に足す

06 代替・他の選択肢 — データの出どころごとの、公式の言い方と使い分け

速さを見る道具を、データの出どころで並べる

どの道具も、ラボかフィールドかのどちらか、または両方である。出どころで並べると、混ぜて使うときの落とし穴が見える。

当サイトの🔧 最大3ページをまとめてLighthouse監査するツールは、利用には無料の会員登録が必要です。5番目・6番目の複数回の測定を、複数ページに広げたいときの道具である。

自社で集めるという選択肢

web.devの記事は、フィールドのデータを自社で集めることについて、こう書く。

"It's also common (and recommended) for site owners to collect field data themselves because it can provide more actionable insights than just using CrUX alone."

（訳: サイト運営者が、フィールドデータを自分で集めることも、一般的で、薦められている。CrUXだけを使うよりも、行動に移しやすい洞察が得られうるからだ。）

CrUXはChromeの利用者に限られ、公開されて十分な訪問があるページだけが対象である。小さなサイトでは、ページ単位のフィールドが出ないことがある、というのが、この資料から読み取れる範囲の話である（どのくらいの頻度かは、資料に書かれていない）。

ラボのスコアを、どう使うか

PSIの資料のFAQは、ラボのスコアについて、次のように書く。

"Any green score (90+) is considered good, but note that having good lab data does not necessarily mean real-user experiences will also be good."

（訳: 緑のスコア（90以上）はどれも良いとされるが、ラボのデータが良くても、実際の利用者の体験も良いとは限らないことに注意。）

ラボの90以上は、調べるための目安として使い、実際の体験は、フィールドで見る。

07 当サイトの例 — 2026年9月30日に、記事ページの遅さを、測ってから直した。10月20日は、PSIの上限で測れなかった

この記事の手順を、当サイトの経験と照らす。確かめられたことと、確かめられなかったことを分けて書く。

確かめられたこと: 遅さは、原因を測ってから直した

2026年9月30日、当サイトの記事ページを開いたときの応答が、1〜4秒かかっていた。固定のページは0.06秒だった。そこで、ページごとの時間を測り、表示のたびに行っていた重い処理が、時間のかなりの部分を占めていることを確かめた。直したあとは、0.1〜0.27秒になった。これは、限られた場所から測った、ラボの性格の数字である。実際の利用者の数字ではない。この数字が良くなったことは、フィールドの28日後の変化を約束しない。

ブログでは、点検ツールの報告値と、自分で叩き直した値が違った例を書いている。「毎朝の「警告1,415件」を、初めて種類別に数えた ── 96.7%は見なくていいもので、唯一の「本物」は自分で叩くまで分からなかった」と、記事ページの遅さを扱った「警告1,440件の中に、本物は2件だけだった ── 「報告は大げさ」は正しかったのに、記事ページは本当に遅かった」である。どちらも、1回の報告値を、測り直して確かめている。

確かめられなかったこと: PSIが、測れない日がある

2026年10月6日には、PageSpeed Insightsの1日の上限に当たり、測れない日があった。この記事を書いた2026年10月20日の朝も、公開のAPIを2回呼んだが、2回とも上限の応答（429）で、結果は得られなかった。測れなかったことは、数字がなかったことではない。記録には「測れなかった」と書き、前回の値を持ち越さない。

同じ揺れは、別の診断ツールでも起きた

ブログでは、別の診断ツールの点数が、同じ記事を20分あけて測っただけで変わった経験を書いている。「『65点だった記事が20分後に95点になった』— AI診断ツールの"揺らぎ"と、毎回測り直す理由」である。PSIのスコアの揺れとは別の道具だが、1回の点数を信じないという点は、同じである。

08 このテーマは、ここまで

PageSpeed Insightsの読み方に関わる公式の資料を、日付の順に並べる。更新があったら、この欄に追記する。

2019年9月19日 — Lighthouseのスコアの資料の表記上の更新日

ページの表記が「Last updated 2019-09-19 UTC」である。本文には、Lighthouse 10の重みの表（First Contentful Paint 10%・Speed Index 10%・Largest Contentful Paint 25%・Total Blocking Time 30%・Cumulative Layout Shift 25%）が載っている。

2022年7月18日 — ラボとフィールドの違いの記事の更新日

web.devの記事の表記が「Last updated 2022-07-18 UTC」である。フィールドが1つの数字ではなく分布だ、と書いている。

2024年6月20日 — CrUXの方法の資料の更新日

ページの表記が「Last updated 2024-06-20 UTC」である。データに載る条件（公開されて見つけられること・十分な訪問者）が書かれている。

2024年10月21日 — PSIの説明の更新日

ページの表記が「Last updated 2024-10-21 UTC」である。ラボとフィールドの違い、28日、データ不足の順序、段階分けの基準が書かれている。

2026年9月22日 — ページ体験の文書の更新日

ページの表記が「Last updated 2026-09-22 UTC」である。良い結果が出ても上位は保証されない、の文が載っている。

2026年10月20日 — この記事の確認日

上の資料を開いて確かめた。PSIの公開APIは、この日の朝に2回呼んで、2回とも上限の応答だった。