PageSpeed Insightsの見方は？上の実際のユーザーのデータが先、下の点数はLighthouseの試験で毎回変わる

PageSpeed Insightsに自分のブログの記事のURLを入れたら、上と下に2つの欄が出て、色の付いた点数、FCPやLCPといった英語の略語、長い項目の一覧が並んだ。点数が赤いと検索で不利なのか、もう一度測ったら点数が変わったのはなぜか、モバイルだけ低いのはなぜか。どこから見ればいいのか、見当がつかないかもしれません。

この記事は、PageSpeed Insightsの画面の読み方が分からない個人ブロガーに向けて、上の欄と下の欄がそれぞれ何を測っているか、点数がどう決まるか、どの順で見るかだけを書きます。直し方は書きません。根拠にしたのは、Googleの「PageSpeed Insights について」、Chromeの開発者向けサイトのLighthouseの点数の説明、web.dev の2ページ、Google 検索セントラルの2ページ、Search Consoleのヘルプで、2026年10月10日に日本語版と英語版を読み比べました。PageSpeed Insightsの説明ページの日本語版はAIによる翻訳と注記されていて、文が途中で切れている箇所があるので、そこは英語版を私が訳しています。

なお、私はこの記事のために実際のPageSpeed Insightsの画面を開いて確かめてはいません。欄や項目の名前は、説明ページに書かれている字で呼んでいます。画面の見出しとは字が違うことがあるので、上か下か、色と数字で見当をつけてください。

結論:上は実際の訪問者のデータ、下は試験の点数。先に見るのは上

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

• 上の欄は、実際のChromeユーザーから集めた過去28日間のデータ。Core Web Vitals の3指標がそろって良好なら合格です。訪問の少ないページやブログでは、出ないこともあります
• 下の欄の点数は、Lighthouseが決まった条件でその場で測った試験の結果。90以上が緑、50〜89がオレンジ、50未満が赤です
• 点数は実行ごとに変わり、モバイルとパソコンは測る条件も点数の基準も違う。1回の点数や、モバイルとパソコンの差に一喜一憂しなくていい、と私は考えています
• 両方あるなら、上の欄で優先順位を付ける。web.dev がそう書いています。下の欄は、上の欄で問題が出たときに原因の見当をつける場所です

PageSpeed Insightsとは:1ページを、2種類のデータで見る道具

GoogleのPageSpeed Insights についてによると、PageSpeed Insightsは、1つのページのユーザー エクスペリエンス(使い心地)をモバイルとパソコンの両方で報告し、改善のための提案を出す道具です。そして、1つのページについて、性質の違う2種類のデータを並べて見せます。

1つはフィールドデータで、実際にページを開いた人の記録です。もう1つはラボデータで、決まった条件で読み込んでみた試験の記録です。説明ページは「ラボデータは、制御された環境で収集されるため、問題のデバッグに役立ちます。」と書き、英語版はそのあとに "However, it may not capture real-world bottlenecks."(ただし、現実の環境での詰まりを捉えられないことがある。私の訳)と続けています。フィールドデータのほうは、実際の使い心地をそのまま捉えられる代わりに、見られる指標が少ない、とあります。

画面の上の欄がフィールドデータ、下の欄がラボデータです。説明ページの見出しでは、上が「実際のユーザー エクスペリエンス データ」、下が「ラボの診断」です。

上の欄:実際の訪問者の過去28日間のデータ

どこから来た数字か

上の欄の数字は、Chrome ユーザー エクスペリエンス レポート(CrUX)から来ています。英語版の説明では、CrUX のデータをもとに、過去28日間の実際のユーザーの FCP・INP・LCP・CLS を報告し、あわせて試験運用の指標として TTFB も出します(私の訳)。データは毎日更新されます。Search Consoleの「ウェブに関する主な指標」レポートも、ヘルプによれば「Core Web Vitals レポートのデータは、CrUX レポートに基づいています。」で、出どころは同じです。

それぞれの指標には、良好・改善が必要・不良の3色の棒(緑・黄・赤)が付きます。英語版の例では、LCP の黄色の棒に11%とあれば、観測された LCP の11%が2,500ミリ秒から4,000ミリ秒の間だった、という意味です。棒の上に出る1つの値は75パーセンタイル、つまり4回に3回の訪問がその値か、それより良い値だった、という値です。

合格・不合格は、Core Web Vitals の3指標で決まる

上の欄では、Core Web Vitals の評価の結果も示されます。説明ページは、合否の決まり方をこう書いています。

3 つの指標すべてで十分なデータがある集計の場合、3 つの指標の 75 パーセンタイルが [良好] であれば、その集計はウェブに関する主な指標のテストに合格します。
— Google「PageSpeed Insights について」

3つの指標は、LCP(いちばん大きな要素が表示されるまで)、INP(操作してから次の画面が描かれるまで)、CLS(表示のずれ)です。良好の目安は、web.dev の「ウェブに関する主な指標」によると、LCPが2.5秒以内、INPが200ミリ秒以下、CLSが0.1以下です。英語版の説明では、INP のデータが足りないときは、LCP と CLS が良好なら合格になり、LCP か CLS のデータが足りないときは評価できない、とあります(私の訳)。FCP と TTFB も上の欄に並びますが、合否には入りません。

記事の数字が出ず、サイト全体の数字になったり、何も出なかったりする

英語版の説明によると、ページの数字を出すには、CrUX に入るだけのデータが要ります。公開したばかりのページや、訪問者が少ないページでは足りないことがあり、そのときはサイト全体(オリジン)の数字に切り替わり、それも足りなければ実際のユーザーのデータは表示できません(私の訳)。同じページのよくある質問には、CrUX に入るには URL が公開されていて(クロールとインデックス登録ができる)、十分な数のサンプルがあることが要る、とあります。個人ブログで上の欄が出ないのは珍しくありません。Search Consoleのレポートで「データがありません」と出るときの考え方はウェブに関する主な指標レポートの見方は？URLグループとデータなしに書きました。

下の欄:Lighthouseが、決まった条件で測った試験の点数

点数の色は、90以上が緑、50未満が赤

下の欄は、Lighthouse というGoogleの点検の道具が、URLを模擬の環境で読み込んで調べた結果です。英語版の説明によると、点検するカテゴリはパフォーマンス、ユーザー補助、ベスト プラクティス、SEO の4つで、欄の上部にカテゴリごとの点数が出ます。点数の目安は "A score of 90 or above is considered good. 50 to 89 is a score that needs improvement, and below 50 is considered poor."(90以上は良好、50〜89は改善が必要、50未満は不良。私の訳)です。Lighthouseのパフォーマンス スコアリングの説明の色分けも同じ境目です。

0～49（赤）: 低い
50～89（オレンジ）: 改善が必要
90 ～ 100（緑）: 良好
— Chrome for Developers「Lighthouse のパフォーマンス スコアリング」

ここで覚えておきたいのは、上の欄の「良好」と下の欄の「良好」は、別の物差しだということです。上は実際の訪問者の75パーセンタイルの値をしきい値と比べた結果、下は試験の点数の色です。上の欄の色は緑、黄、赤で、下の欄の中間の色は、Lighthouseの説明ではオレンジと書かれています。

パフォーマンスの点数は、指標の点数の加重平均

下の欄でいちばん目立つパフォーマンスの点数について、Lighthouseの説明は「パフォーマンス スコアは、指標スコアの加重平均です。」と書いています。指標ごとに0〜100の点数を付け、重みを掛けて平均したものです。Lighthouse 10 の重みは次のとおりです。

重みの合計は 10 + 10 + 25 + 30 + 25 = 100 で、いちばん重いのは TBT です。説明は、重みはこれまでにも変わってきたと書いています。また、PageSpeed Insightsがいまどの版の Lighthouse を使っているかは、私が読んだ2つの説明ページには書かれていませんでした。表は Lighthouse の説明ページに載っている Lighthouse 10 のものです。

下に並ぶ改善案や診断は、点数に直接は入らない

点数の下には、ページの改善のための項目が長く並びます。ここで迷う人が多いと思いますが、Lighthouseの説明はこう書いています。

通常、Lighthouse のパフォーマンス スコアには、指標のみが影響し、改善案や診断の結果は影響しません。
— Chrome for Developers「Lighthouse のパフォーマンス スコアリング」

英語版は "only metrics contribute to your Lighthouse Performance score, not the results of Opportunities or Diagnostics." です。ただし続けて、改善案や診断を直せば指標の値も良くなる見込みが高いので、間接的な関係はある、とも書いています。項目の数が多くても、それがそのまま減点の数ではない、ということです。画像についての項目が出て、どこまで軽くすればいいか迷ったときの考え方はブログの画像圧縮はSEOに効く？どこまでやるかは最初の1枚で決めるにまとめました。

点数は実行ごとに変わる。原因の多くはLighthouseの外

同じURLをもう一度測ると、ページを何も変えていなくても点数が変わります。説明ページのよくある質問にも、まさにこの問いがあり、英語版は "Several common sources of metric variability are local network availability, client hardware availability, and client resource contention."(ばらつきのよくある原因は、回線の状態、測る機械の状態、機械の処理の取り合い。私の訳)と答えています。Lighthouseの説明はもっとはっきり書いています。

全体的なパフォーマンス スコアと指標の値が変動する主な原因は、Lighthouse ではありません。
— Chrome for Developers「Lighthouse のパフォーマンス スコアリング」

続けて挙げている例には、「配信される広告の A/B テストや変更」「インターネット トラフィックのルーティングの変更」「JavaScript を挿入したり、ネットワーク リクエストを追加または変更したりするブラウザ拡張機能」「ウィルス対策ソフトウェア」があります。広告を貼っているブログなら、測るたびに違う広告が出るだけで点数が動くことがある、と私は読んでいます。

同じ説明は、1つの点数としてではなく、点数の分布として考えるほうが役に立つことがある、とも書いています。私は、1回の点数で判断せず、何回か測って大きく外れた回を除いて見るようにしています。点数が数点上下したのを、直した効果や悪くなった証拠とは読みません。

モバイルとパソコン:測る条件も、点数の基準も違う

結果はモバイルとパソコンの2つがあり、切り替えて見ます。web.dev のフィールドで遅い操作を見つけるガイドにも「切り替えボタンを使用して、モバイルとパソコンのディメンションの INP 値を確認することもできます。」とあります。

下の欄の試験の条件について、英語版の説明は "Currently, Lighthouse simulates the page load conditions of a mid-tier device (Moto G4) device on a mobile network for mobile, and an emulated-desktop with a wired connection for desktop." と書いています。モバイルは中くらいの性能のスマホ(Moto G4)をモバイル回線で、パソコンは有線接続のパソコンを模して読み込む、ということです(私の訳)。さらにLighthouseの説明によると、点数の基準(指標の値を点数に直す曲線)も、パソコンにはパソコン用のものが使われています。

モバイルだけ点数が低く出やすい理由について、原文は、モバイルのほうが低く出るとまでは書いていません。条件を読む限り、中くらいの性能のスマホとモバイル回線を模すモバイルのほうが、有線接続のパソコンより厳しい試験になる、というのが私の読みです。そして基準も別なので、モバイル50点とパソコン80点を並べて、モバイルのほうが30点悪いと比べても、あまり意味がない、と私は考えています。見るなら、モバイルはモバイルどうし、パソコンはパソコンどうしで、前に測ったときと比べます。どちらから見るかは、自分のブログに多い端末の側からで十分だと私は考えています。

上と下で結果が食い違ったら、上を先に見る

上の欄は合格なのに下の点数が赤い、あるいはその逆、ということがあります。英語版の説明は、フィールドデータはさまざまな端末と回線の実際のユーザーの記録で、ラボデータは1台の端末と決まった回線での模擬の読み込みなので、値が違うことがある、と説明しています(私の訳)。点数の目安を答える質問では、日本語版は「緑色のスコア（90 以上）は良好と見なされます。」と書いていますが、その次の文は途中で切れていて、意味が逆に読めます。英語版は "having good lab data does not necessarily mean real-user experiences will also be good."(ラボデータが良くても、実際のユーザーの体験も良いとは限らない。私の訳)です。

web.dev のラボデータとフィールドデータの違いの解説は、食い違ったときの扱いをこう書いています。

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

同じ解説は、フィールドが良好でもラボに改善の余地があるなら、さらにできることを知っておく価値がある、とも書いていて、下の欄を無視してよいとは言っていません。ラボデータは、遅い回線や性能の低い端末の人に届きやすくする手がかりにもなる、とあります。私の見方は、上の欄が合格なら下の点数の赤は急がず、上の欄で不良が出ている指標があれば、下の欄でその指標に関係する項目を探す、という順番です。

点数は、Google検索の順位の数字ではない

Google 検索セントラルのページ エクスペリエンスの説明は、「Google のランキング システムでは Core Web Vitals が使用されます。」と書いています。そしてCore Web Vitals の説明は、「Core Web Vitals は、ページの読み込みパフォーマンス、インタラクティブ性、視覚的安定性に関する実際のユーザー エクスペリエンスを測定する一連の指標です。」としています。一方で、私が読んだGoogleの文書(この記事で挙げたページ)には、Lighthouseのパフォーマンスの点数を順位に使うとは書かれていませんでした。ページ エクスペリエンスの説明でLighthouseが出てくるのは、改善点を見つける道具の1つとしてです。

同じページは、「Search Console の Core Web Vitals レポートのようなレポートやサードパーティのツールで良い結果が得られても、Google 検索の検索結果で上位に表示されることが保証されるわけではありません。」とも書き、「SEO 上の理由のためだけに満点を取ろうとするのは、有効な時間の使い方とは言えないでしょう。」と続けています。Lighthouseの説明も「100 の「完璧」なスコアを達成するのは非常に困難であり、期待されるものではありません。」としていて、英語版によれば、99点を100点にするには、90点を94点にするのと同じくらいの指標の改善が要ります(私の訳)。速度が順位にどれだけ効くかはページ表示速度はSEOに効くか、Core Web Vitalsより先に見る3つに書きました。

どれから見るか:私が決めている順番

ここまでを、画面を開いたときに見る順番にすると、次のようになります。

1. モバイルかパソコンか、自分のブログに多い端末のほうを選ぶ
2. 上の欄が出ているかを見る。出ていなければ、その記事は実際の訪問者のデータが足りない。サイト全体の数字に切り替わっていないかも見る
3. 上の欄が出ていれば、Core Web Vitals の評価が合格かを見る。不合格なら、LCP・INP・CLS のどれが良好でないかを見る
4. 下の欄の点数は、色だけ見る。何回か測って、毎回赤なのか、たまたま赤だったのかを分ける
5. 下の欄の項目は、上の欄で良好でなかった指標に関係するものだけ読む

この順番は私の決め方で、Googleの文書にこの順で書かれているわけではありません。根拠にしているのは、フィールドデータで優先順位を付けるという web.dev の文と、点数は実行ごとに変わるという説明です。

よくある質問

PageSpeed Insightsの点数は何点なら合格ですか

下の欄の点数に「合格」はありません。説明ページは90以上を良好、50〜89を改善が必要、50未満を不良としています。合格・不合格が出るのは上の欄の Core Web Vitals の評価で、3指標の75パーセンタイルがすべて良好なら合格です。

下の欄に INP が出てきません

説明ページが挙げる下の欄の指標に、INP は入っていません。INPは上の欄で確かめます。確かめ方と、下の欄の TBT とINPの関係はINPの改善とは？サーチコンソールで「改善が必要」と出たら、PageSpeed InsightsとChromeで遅い操作を探すに書きました。

Search Consoleの結果とPageSpeed Insightsの上の欄が合いません

出どころはどちらも CrUX ですが、Search Consoleは似たページをまとめた URL グループで、PageSpeed Insightsは基本的に1つのURLで見ます。Search Consoleのヘルプも、PageSpeed Insightsの特定のURLの数字はグループの結果と一致しないことがある、と書いています。

SEO の点数が100なら、検索で有利ですか

下の欄の SEO の点数も、Lighthouseの SEO カテゴリの点検の結果です。私が読んだ文書には、この点数を順位に使うとは書かれていませんでした。点数が100でも、それだけで上位に表示されるわけではない、と私は考えています。SEOの点数が何を数えているかはSEOスコアとは？Lighthouseもプラグインも順位の点数ではない。直す記事は自分の順位と表示回数で選ぶに書きました。

まとめ

• 上の欄は、実際のChromeユーザーから集めた過去28日間のデータ(CrUX)。Core Web Vitals の3指標の75パーセンタイルがすべて良好なら合格
• 訪問の少ないページでは、サイト全体の数字に切り替わったり、上の欄が出なかったりする
• 下の欄の点数は、Lighthouseが決まった端末と回線を模して測った試験の結果。90以上が良好、50〜89が改善が必要、50未満が不良
• パフォーマンスの点数は指標の点数の加重平均(Lighthouse 10では5つの指標)で、改善案や診断の項目は点数に直接は入らない
• 点数は、ページを変えなくても回線や端末の状態で実行ごとに変わる。1回の点数で判断しない
• モバイルとパソコンは、測る条件も点数の基準も違う。2つの点数を並べて比べない
• 両方あるなら上の欄で優先順位を付ける(web.dev)。ランキングに使うと書かれているのは Core Web Vitals で、読んだ文書には Lighthouse の点数を順位に使うとは書かれていない

上の欄が合格か、出ていないなら、点数の赤を追いかけるより、すでに検索結果に出ている記事のうち、どれの中身やタイトルを直すかを決めるほうに時間を回せます。

ここからは、私が作ったツールの話になります。

どの記事の中身やタイトルを直すかを、Search Consoleの数字で並べるツールを作りました。Search Consoleの「ページ」タブのエクスポートをZIPのまま置くと、掲載順位が4.0〜20.5位のページを拾い、表示回数100回以上は通常判定、30〜99回は参考判定、30回未満は本文中心の監査に分けます。並び順は、通常判定 → 参考判定 → 本文中心の監査の順。前2つの中は CTR機会差の多い順、30回未満は表示回数の多い順です。 判定と、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで、無料の1件を除いた3記事分の診断カードが対象です。3記事分が揃うとき(判定に出た候補が4件以上のとき)だけご案内します。生成の利用期限は購入から7日間で、月額課金や自動更新はありません。ログインも不要です。 CSVファイルそのものはブラウザの外に出ませんが、診断カードを出すときは選んだ1ページぶんの数値(URL・キーワード・順位・表示回数・CTR)を、タイトル取得を押したときは最大10件のURLを送ります。

⚠️ 判定に使うのは、Google検索のページごとの平均掲載順位・表示回数・CTRです(診断カードでは選んだ1ページの本文を読みます)。このツールは、表示速度もLighthouseの点数もCore Web Vitalsも測りません。PageSpeed Insightsの代わりにはならないので、速度の確かめ方は、この記事のとおりPageSpeed Insightsで行ってください。表示回数が0の行は読み込み時に除くので、検索結果に出ていない記事は候補に出てきません。並べ替えるだけで、順位やクリック数が上がることを約束するものではなく、掲載順位4.0〜20.5位に入るページが無いブログでは、候補が0件になることがあります。