この記事の要点：
- PageSpeed Insights（PSI）は、ページの表示の速さと使いやすさを、モバイルとパソコンに分けて調べる Google の無料ツールです。URL を入れて「分析」を押すだけで使えます。
- 結果は 2 種類あります。上段は実際の利用者の計測値（フィールドデータ、直近 28 日間）、下段は決まった条件で 1 回読み込んだ計測値（ラボデータ、Lighthouse）です。
- 0〜100 の点数は下段のラボデータの点数で、90 以上が「良好」、50〜89 が「改善が必要」、49 以下が「低い」です。コアウェブバイタルの合格・不合格は、上段のフィールドデータで決まります。
- 改善案は、点数を直接上げる項目ではなく、指標を悪くしている原因の手がかりです。多くのページに共通する原因から直し、上段の実測が良くなったかで確かめます。
PageSpeed Insightsとは：ページの速さと使いやすさを調べるGoogleの無料ツール
PageSpeed Insights（PSI）とは、Web ページの表示の速さと使いやすさを、モバイルとパソコンの両方について調べ、改善の手がかりを示す Google の無料ツールです。ブラウザで pagespeed.web.dev を開き、調べたいページの URL を入れるだけで使えます。登録やサイトの所有者の確認は要りません。
Google の「PageSpeed Insights について」は、PSI がページのユーザー体験についてのレポートと、ページを改善する方法の提案を出すツールだと説明しています。結果には、実際の利用者のデータ（フィールドデータ）と、決まった環境で測ったデータ（ラボデータ）の 2 種類が並びます。
PSI が主に使われるのは、コアウェブバイタル（Google が重視するページ体験の 3 つの指標：LCP・INP・CLS）の確認と、遅さの原因探しです。指標の意味と改善のコード例は「コアウェブバイタルの基準と改善方法」で説明しています。この記事では、PSI の操作と結果の読み方を扱います。
| PSI でわかること | 画面の場所 |
|---|---|
| 実際の利用者が体験した速さ（LCP・INP・CLS など）と合否 | 上段「実際のユーザーの環境で評価する」 |
| パフォーマンス・ユーザー補助・おすすめの方法・SEO の点数 | 下段「パフォーマンスの問題を診断する」とその下 |
| 遅さの原因と改善の手がかり | 下段の「インサイト」「診断」 |
画面の表示名は更新で変わることがあります。この記事の表示名は 2026 年 10 月時点の日本語の画面に合わせています。
PageSpeed Insightsの使い方：URLを入れて結果を読むまでの手順
PageSpeed Insights の使い方は、URL を入れて分析し、モバイルとパソコンの結果を、上段の実測から順に読むことです。1 ページの確認なら数分で終わります。
- PageSpeed Insights（pagespeed.web.dev）を開き、調べたいページの URL を入力して「分析」を押す
- 結果が出たら、「携帯電話」と「デスクトップ」の切り替えで、どちらの結果を見ているかを確かめる
- 上段「実際のユーザーの環境で評価する」で、コアウェブバイタルの評価が「合格」か「不合格」か、どの指標が悪いかを見る。「この URL」と「オリジン」（サイト全体）を切り替えられる
- 下段「パフォーマンスの問題を診断する」で、0〜100 の点数と、Lighthouse が測った各指標の値を見る
- さらに下の「インサイト」「診断」で、悪い指標に関係する項目を開き、原因になっている画像やスクリプトを確かめる
調べるページは、トップページだけでなく、アクセスの多い記事や、テンプレートの違うページ（記事・一覧・商品など）を 1 つずつ選ぶと、サイト全体の傾向がつかめます。サイト全体の URL ごとの合否を見るには、Search Console の「ウェブに関する主な指標」を使います。
PSI は Google のサーバーからページを読み込んで測ります。そのため、ログインが必要なページや、社内のネットワークからしか見られないページは調べられません。公開前のページは、Chrome の開発者ツールに入っている Lighthouse で測る方法があります。
フィールドデータとラボデータの違い：上段と下段は別の測り方
PSI の上段のフィールドデータは「実際の利用者がどう体験したか」、下段のラボデータは「決まった条件で 1 回読み込むとどうなるか」を表します。測り方が違うため、2 つの結果が食い違うのは珍しくありません。
| 比べる点 | フィールドデータ（上段） | ラボデータ（下段） |
|---|---|---|
| データの元 | Chrome ユーザー エクスペリエンス レポート（CrUX）。Chrome の利用者から集めた匿名の計測値 | Lighthouse がページをシミュレーションで読み込んだ結果 |
| 期間 | 直近 28 日間 | 分析したその時の 1 回 |
| 端末・回線 | 利用者ごとにさまざま | 決まった端末と回線の条件を再現 |
| 主な指標 | LCP・INP・CLS・FCP・TTFB | FCP・LCP・TBT・CLS・Speed Index |
| 使いどころ | 合否の判断、実際の体験の把握 | 原因の調査、修正前後の比較 |
Google の文書は、ラボデータは管理された環境で集めるため問題のデバッグに役立つ一方、実際のボトルネックを捉えていないおそれがある、と説明しています。フィールドデータは実際の体験をそのまま表しますが、使える指標が限られます。
食い違ったときは、上段の実測を優先して判断します。利用者の多くが速い端末や回線を使っていれば、ラボの点数が低くても実測は良好になりえます。逆に、ラボで速くても、広告や利用者の操作で実測が悪くなることもあります。
上段「実際のユーザーの環境で評価する」の読み方
上段のフィールドデータは、指標ごとの 75 パーセンタイルの値と、「良好」「改善が必要」「低速」の分布で読みます。75 パーセンタイルとは、利用者の体験を良い順に並べたとき 75% の位置にある値で、4 人に 3 人はこの値以上に良い体験をしていることを意味します（出典：Google for Developers：PageSpeed Insights について）。
PSI が使う基準は次のとおりです（Google「PageSpeed Insights について」、2026 年 10 月確認）。コアウェブバイタル（Google が重視する 3 つの指標）は LCP・INP・CLS で、FCP と TTFB は原因を探す手がかりの指標です。5 つの指標の基準と、悪い指標から直す順番は「表示速度の測り方と改善の順番」で説明しています。
| 指標 | 測るもの | 良好 | 改善が必要 | 低速 |
|---|---|---|---|---|
| LCP（Largest Contentful Paint） | 画面で一番大きな画像や文章が表示されるまでの時間 | 2.5 秒以下 | 2.5 秒超〜4 秒以下 | 4 秒超 |
| INP（Interaction to Next Paint） | クリックやタップから画面が反応するまでの時間 | 200 ミリ秒以下 | 200 ミリ秒超〜500 ミリ秒以下 | 500 ミリ秒超 |
| CLS（Cumulative Layout Shift） | 表示中のレイアウトのずれの大きさ | 0.1 以下 | 0.1 超〜0.25 以下 | 0.25 超 |
| FCP（First Contentful Paint） | 最初の文字や画像が表示されるまでの時間 | 1.8 秒以下 | 1.8 秒超〜3 秒以下 | 3 秒超 |
| TTFB（Time to First Byte、試験運用中） | サーバーが最初の応答を返すまでの時間 | 0.8 秒以下 | 0.8 秒超〜1.8 秒以下 | 1.8 秒超 |
コアウェブバイタルの「合格」の決まり方
コアウェブバイタルの評価は、LCP・INP・CLS の 3 つすべての 75 パーセンタイルが「良好」なら合格です。Google の文書によると、INP のデータが足りない場合は、LCP と CLS の両方が「良好」なら合格になります。
「この URL」と「オリジン」、データが出ないとき
「この URL」はそのページだけ、「オリジン」は同じドメインのサイト全体の集計です。アクセスが少なく、そのページのデータが CrUX に十分に集まっていない場合、PSI はオリジンのデータを表示します。オリジンのデータも足りない場合は、実測は表示されません。公開したばかりのサイトや小さなサイトでは、上段が空になることがよくあります。その場合は下段のラボデータで大きな問題がないかを確かめます。
下段のパフォーマンススコアの読み方：点数の決まり方と目安
下段の 0〜100 のパフォーマンススコアは、Lighthouse（Google のページ品質の測定ツール）がラボで測った 5 つの指標を、重みをつけて平均した点数です。90〜100 が「良好」（緑）、50〜89 が「改善が必要」（オレンジ）、0〜49 が「低い」（赤）です。
| 指標（Lighthouse 10 以降） | 測るもの | 重み |
|---|---|---|
| Total Blocking Time（TBT） | 読み込み中に、重い処理で操作を受け付けなかった時間の合計 | 30% |
| Largest Contentful Paint（LCP） | 一番大きな画像や文章が表示されるまでの時間 | 25% |
| Cumulative Layout Shift（CLS） | レイアウトのずれの大きさ | 25% |
| First Contentful Paint（FCP） | 最初の表示までの時間 | 10% |
| Speed Index | 画面が埋まっていく速さ | 10% |
重みは Chrome for Developers の「Lighthouse のパフォーマンス スコアリング」によるもので、Lighthouse の版によって変わってきました。この文書は、点数に影響するのは指標だけで、改善案や診断の項目は直接は影響しないと説明しています。また、100 点を取るのは非常に難しく、期待されるものではないとしています。
点数が毎回変わる理由
同じページでも、測るたびに点数は少し変わります。Lighthouse の文書は、配信される広告の違い、ネットワークの経路、測る端末、ブラウザ拡張機能などを原因に挙げています。修正の効果を確かめるときは、修正の前後で何回か測って比べます。
当サイト（seoagent.jp）での測定例
当サイト（seoagent.jp）では、Lighthouse のモバイル設定で測ったラボの点数を見ながら表示速度を直しました。モバイルではヒーロー画像を読み込まないなどの変更で、点数が 85 から 100（LCP 4.1 秒から約 1.5 秒）になりました。計測タグの読み込みを後回しにした変更では、92 から 96〜97 になりました。いずれもラボ値で、当サイトはアクセスが少ないため、フィールドデータでの変化はまだ確認できていません。
改善案（インサイト・診断）の見方と、直す順番
下段の「インサイト」と「診断」は、点数を上げる作業の一覧ではなく、悪い指標の原因を探すための手がかりです。まず上段・下段で悪い指標を決め、その指標に関係する項目から開きます。
| 悪い指標 | まず開く項目の例（Lighthouse の文書の名前） | よくある原因 |
|---|---|---|
| LCP（一番大きな要素の表示が遅い） | LCP の内訳、LCP リクエストの検出、画像配信を改善する、ドキュメント リクエストのレイテンシ | 大きすぎる画像、遅延読み込みされた最初の画像、サーバーの応答の遅さ |
| TBT・INP（操作への反応が遅い） | メインスレッドの作業を最小限に抑える、JavaScript の実行時間を短縮する、サードパーティ | 重い JavaScript、多すぎる外部のタグ |
| CLS（レイアウトがずれる） | レイアウト シフトの原因 | サイズ指定の無い画像、後から差し込まれる広告や埋め込み |
| FCP（最初の表示が遅い） | レンダリングをブロックしているリクエスト、効率的なキャッシュ保存期間を使用する | 読み込みを止める CSS や JavaScript |
項目の名前は Lighthouse の版で変わり、以前は「改善できる項目」という見出しでした。各項目を開くと、原因になっているファイルや要素と、削れる時間やサイズの目安が出ます。
直す順番は、テーマ・テンプレート・共通のタグなど、多くのページに共通する原因が先です。1 ページだけ直しても、サイト全体の実測はあまり変わらないためです。画像が原因のときの直し方は画像の最適化で、JavaScript の読み込みとレンダリングの関係は「JavaScript SEO」で説明しています。
修正後は、まず下段のラボの値で効果を確かめ、上段の実測は 28 日間の集計が入れ替わるのを待って確かめます。
モバイルだけ点数が低いのはなぜか
PSI でモバイルの点数だけが低くなりやすいのは、モバイルの測定が、性能の低めのスマートフォンと遅めのモバイル回線を再現した条件で行われるためです。同じページでも、パソコンの条件より読み込みと処理に時間がかかって見えます。
Google の文書は、Lighthouse が中程度の性能のモバイル端末と、モバイル回線を模した条件でページの読み込みを再現すると説明しています。パソコンの測定は、パソコン向けの条件と有線の接続を前提にしています。点数の換算もモバイルとパソコンで別の基準が使われます。
そのため、モバイルとパソコンの点数を直接比べる意味はあまりありません。モバイルの結果で見るべきなのは、大きな画像をそのまま送っていないか、スマートフォンの画面に不要な要素を読み込んでいないか、重い JavaScript が処理を止めていないかです。スマートフォン向けの表示の作り方はレスポンシブデザインで扱っています。
Google の検索はスマートフォン向けのページを主に使ってインデックスするため（モバイルファーストインデックス）、迷ったときはモバイルの結果を優先して直します。
PageSpeed InsightsとLighthouse・Search Consoleの使い分け
PageSpeed Insights は 1 ページの実測とラボの両方を見る道具、Lighthouse はラボの測定そのものの道具、Search Console はサイト全体の URL の実測を見る道具です。調べたい範囲で使い分けます。
| 道具 | わかること | 向く場面 |
|---|---|---|
| PageSpeed Insights | 1 ページ（とサイト全体）の実測と、Lighthouse のラボの結果 | 公開中のページの原因調査と、修正の効果の確認 |
| Lighthouse（Chrome の開発者ツールなど） | ラボの結果。手元の端末と回線で測る | 公開前のページ、ログインが必要なページの確認 |
| Search Console「ウェブに関する主な指標」 | インデックスされた URL の実測を、似た URL のグループごとに表示 | サイト全体で問題のあるページの洗い出し |
| PageSpeed Insights API | PSI と同じ結果をプログラムから取得 | 多くのページを定期的に測る仕組みづくり |
PSI の下段は Lighthouse で測っているため、中身は同じ種類の測定です。ただし、PSI は Google のサーバーから測り、開発者ツールの Lighthouse は手元のパソコンで測るため、値は一致しません。比べるときは同じ道具どうしで比べます。
サイト全体の進め方は、Search Console で問題のあるグループを見つけ、代表の URL を PSI で調べる順が効率的です。テクニカルSEO 全体の中での位置づけはSEO内部対策とはを参照してください。
よくある質問
PageSpeed Insightsのスコアは何点を目指せばよいですか？
Lighthouse の文書は 90〜100 を「良好」としていますが、100 点は非常に難しく、期待されるものではないと説明しています。点数より、上段の実測でコアウェブバイタルが合格しているかを先に確かめるのがおすすめです。
点数が低いと検索順位は下がりますか？
0〜100 の点数そのものが順位を決めるわけではありません。Google 検索セントラルは、ランキングシステムがコアウェブバイタルを使うと説明していますが、内容が役に立つことの方が大切だとしています。点数は原因探しの道具として使います。
「データがありません」と表示されるのはなぜですか？
上段の実測は、Chrome の利用者から十分な数のデータが集まったページやサイトにしか出ません。アクセスが少ないサイトや公開直後のページでは表示されないため、下段のラボデータで確かめます。
PageSpeed Insightsでエラーになり、分析できないのはなぜですか？
PSI は Google のサーバーからページを読み込むため、ログインが必要なページ、社内からしか見られないページ、サーバーがアクセスを断っているページ、読み込みに時間がかかりすぎるページは分析できないことがあります。ページを普通のブラウザで開けるか、サーバーの設定でアクセスを制限していないかを確かめます。
修正したのに上段の値が変わらないのはなぜですか？
上段の実測は直近 28 日間の集計のため、修正後のデータに入れ替わるまで時間がかかります。修正の効果は、まず下段のラボの値で確かめ、上段は数週間後に見直します。
SEOAGENTでできること
SEOAGENT では、記事の中身だけでなく、ページが読者に届く状態かも確認できます。
- AI検索・表示速度の診断：表示速度について、実際の利用者のデータ（CrUX）の判定と、計測ツールの点数を分けて表示します。テーマやサーバーの設定を自動で変える機能ではありません。
- SEO分析・効果測定：Search Console の表示回数・クリック・平均順位などを記事ごとに確認でき、速度を直した記事の検索の推移を追えます。
PageSpeed Insightsの使い方と関わるテクニカルSEOの記事は「テクニカルSEOの記事一覧」にまとめています。
