この記事は、オウンドメディアのSEO支援実績を持つHabinyのコンサルタントが執筆しています。
PageSpeed Insightsは、Googleが無料で提供しているページの表示速度と使いやすさを測るツールです。URLを入れるだけで点数が出る手軽さの一方で、「赤い数字が並んでいるが、何から直せばいいかわからない」「スコアを上げても問い合わせが増えない」という声もよく聞きます。本記事では、PageSpeed Insightsの使い方と結果の見方を整理したうえで、問い合わせや商談につながるページから改善する優先順位の決め方と、開発・制作会社への依頼の出し方まで解説します。
💡 この記事でわかること
- PageSpeed Insightsの使い方と、2つの評価（実際のユーザーのデータ／診断スコア）の見方
- スコアの合格点の目安と、100点を目指さなくてよい理由
- BtoBサイトで成果につなげる改善の優先順位と、開発・制作会社への依頼テンプレート
【表示速度の改善、どこから手をつけるか迷ったら】
PageSpeed Insightsとは？ページの表示速度と体験の質を無料で測るツール
PageSpeed Insights（PSI）は、Googleが提供するWebページのパフォーマンス診断ツールです。モバイルとパソコンの両方について、ページのユーザー体験を評価し、改善のための提案を表示します。アカウント登録は不要で、公開されているページのURLを入力するだけで使えます。
出典：Google for Developers「PageSpeed Insights について」
PageSpeed Insightsでわかる2種類のデータ
PageSpeed Insightsの結果は、性質の違う2種類のデータで構成されています。ここを区別できるかどうかが、結果を正しく読む最大のポイントです。
区分 | フィールドデータ | ラボデータ |
|---|---|---|
画面上の表示 | 実際のユーザーの環境で評価する | パフォーマンスの問題を診断する |
データの出どころ | Chromeの実ユーザーから集めたデータ（CrUX） | Lighthouseによる読み込みのシミュレーション |
集計期間 | 過去28日間 | 計測したその時点 |
主な結果 | Core Web Vitalsの合格／不合格 | 0〜100のスコアと改善案 |
向いている用途 | 実際にユーザーが困っているかの判断 | 原因の特定と、修正直後の確認 |
フィールドデータは「実際に起きていること」、ラボデータは「決まった条件で再現した結果」です。Googleも、ラボデータは問題のデバッグに役立つ一方で、実際のボトルネックを捉えきれない場合があると説明しています。
出典：Google for Developers「PageSpeed Insights について」
Lighthouse・Search Consoleとの違い
表示速度を測るGoogleの無料ツールは、主に3つあります。目的に応じて使い分けると効率的です。
ツール | 見られるデータ | 単位 | 向いている場面 |
|---|---|---|---|
PageSpeed Insights | フィールドデータ＋ラボデータ | 1URLずつ（サイト全体の集計も表示可） | 特定ページの状態確認と原因の把握 |
Lighthouse | ラボデータのみ | 1URLずつ | 公開前の検証や、ログインが必要なページの計測（Chromeのデベロッパーツールなどから実行） |
Search Console（Core Web Vitalsレポート） | フィールドデータ | サイト全体（似たURLをグループ化） | 問題のあるページ群の洗い出しと、改善後の推移確認 |
PageSpeed Insightsのラボデータは、Lighthouseを使って計測されています。つまり、PageSpeed Insightsは「Lighthouseの結果」に「実ユーザーのデータ」を加えたツールだと考えるとわかりやすいでしょう。運用では、Search Consoleで問題のあるページ群を見つけ、PageSpeed Insightsで原因を調べるという順番が効率的です。
サーチコンソールとアナリティクスの違いとは？役割・指標・使い分けを「商談につながる分析」視点で解説
表示速度がBtoBサイトの成果に関わる理由
表示速度は、SEOとCV（問い合わせ・資料請求）の両面に関わります。
SEOの面では、GoogleはCore Web Vitalsがランキングシステムで使われていると明言し、サイト所有者に改善を勧めています。ただし、レポートの結果が良くても上位表示が保証されるわけではなく、SEOのためだけに満点を狙うのは有効な時間の使い方ではない、とも説明しています。
出典：Google 検索セントラル「ページ エクスペリエンスが Google 検索の検索結果に与える影響について」
CVの面では、影響はより直接的です。資料請求フォームの読み込みが遅い、ボタンを押しても反応が鈍い、入力中にレイアウトがずれて別の場所を押してしまう。こうした体験は、検討意欲の高いユーザーを入口で取りこぼす原因になります。BtoBサイトで表示速度を改善する本当の目的は、スコアではなく商談につながる行動を妨げないことです。
【表示速度の改善、どこから手をつけるか迷ったら】
PageSpeed Insightsの使い方（3ステップ）
操作はシンプルです。次の3ステップで結果を確認できます。
- URLを入力して分析する：PageSpeed Insightsにアクセスし、調べたいページのURLを入力して「分析」を押します。結果は数十秒ほどで表示されます。
- モバイルとパソコンを切り替える：結果は最初にモバイル向けが表示されます。画面上部のタブでパソコン向けに切り替えられます。
- 「このURL」と「オリジン」を切り替える：フィールドデータは、入力したページ単体の結果と、サイト全体（オリジン）の集計を切り替えて確認できます。アクセスが少ないページは、オリジンの結果だけが表示されることもあります。
結果ページのURLをコピーすれば、同じレポートを社内や制作会社と共有できます。改善を依頼する際の資料としても使えます。
PageSpeed Insightsの見方｜2つの評価は分けて読む
結果画面は、上段の「実際のユーザーの環境で評価する」（フィールドデータ）と、下段の「パフォーマンスの問題を診断する」（ラボデータ）に分かれています。上段で問題があるかどうかを判断し、下段で原因を探す、という順番で読むのが基本です。
上段：Core Web Vitalsの合否（フィールドデータ）
上段の冒頭には、Core Web Vitalsの評価が「合格」または「不合格」で表示されます。Core Web Vitalsは、ページ体験の中でも特に重要とされる3つの指標です。
3つの指標それぞれで、過去28日間に集まった値の75パーセンタイル（遅い側から数えて4分の1の位置にあたる値）が「良好」なら合格です。INPのデータが足りない場合は、LCPとCLSの2つが「良好」であれば合格と判定されます。
出典：Google for Developers「PageSpeed Insights について」
Core Web Vitals 3指標の意味と基準値
指標 | 測るもの | 良好 | 改善が必要 | 不良 |
|---|---|---|---|---|
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超 |
出典：Google for Developers「PageSpeed Insights について」
なお、以前はINPではなくFID（First Input Delay）がCore Web Vitalsの1つでした。2024年3月12日にINPへ置き換わっています。FIDを前提にした古い解説記事も残っているため、参照する際は注意してください。
出典：web.dev「Interaction to Next Paint は正式に Core Web Vitals となり、First Input Delay に代わって 3 月 12 日に有効になります」
その他の指標（FCP・TTFB）
上段には、Core Web Vitals以外の参考指標も表示されます。合否には直接関わりませんが、原因を絞り込むヒントになります。
- FCP（First Contentful Paint）：最初に何らかの内容が表示されるまでの時間。良好の基準は1.8秒以下です。
- TTFB（Time to First Byte）：ページを要求してから、サーバーが最初のデータを返すまでの時間。良好の基準は0.8秒以下です。ここが遅い場合は、サーバー側に原因がある可能性が高まります。
下段：パフォーマンススコアと改善案（ラボデータ）
下段には、Lighthouseのシミュレーションによる0〜100のパフォーマンススコアが表示されます。スコアは、FCP・LCP・TBT（Total Blocking Time）・CLS・Speed Indexの5つの指標の結果から算出されます。TBTは、読み込み中にブラウザが操作を受け付けられなかった時間の合計で、ラボデータでINPの代わりに反応の悪さを見る指標です。
スコアの下には、改善案と診断の項目が並びます。各項目を開くと、問題のある画像やスクリプトのファイル名が具体的に表示されます。なお、Lighthouseのスコアに影響するのは指標の値だけで、改善案や診断の項目そのものはスコアに直接影響しません。改善案に対応することで指標が良くなり、結果としてスコアが上がる、という関係です。
出典：Chrome for Developers「Lighthouse による全体的なパフォーマンス スコアの計算方法」
スコアの横には、パフォーマンスのほかに「ユーザー補助」「ベスト プラクティス」「SEO」のスコアも表示されます。本記事で扱う表示速度に関わるのは、パフォーマンスのスコアです。
【表示速度の改善、どこから手をつけるか迷ったら】
PageSpeed Insightsの合格点は？スコアの目安と100点を目指さなくてよい理由
スコアの色分け基準
パフォーマンススコアは、次の3段階で色分けされます。
スコア | 評価 | 色 |
|---|---|---|
90〜100 | 良好 | 緑 |
50〜89 | 改善が必要 | オレンジ |
0〜49 | 不良 | 赤 |
出典：Google for Developers「PageSpeed Insights について」
合否はスコアより「Core Web Vitals」で判断する
「合格点は何点か」と聞かれた場合、スコアの目安は90点以上です。ただし、実務で重視すべきなのは上段のCore Web Vitalsが合格しているかどうかです。
理由は2つあります。1つ目は、スコアがシミュレーションの結果にすぎない点です。ラボデータは、中程度の性能のモバイル端末と低速な回線を想定して計測されるため、実際のユーザー環境よりも厳しい数値が出やすくなります。2つ目は、Googleが検索で使っているのは実ユーザーのデータにもとづくCore Web Vitalsだという点です。前述のとおり、Google自身もSEOのためだけに満点を目指すことは勧めていません。
たとえば、スコアが60点台でもCore Web Vitalsが合格していれば、実際のユーザーは大きな不便を感じていない可能性が高いと言えます。逆に、スコアが高くてもCore Web Vitalsが不合格なら、実ユーザーの環境で問題が起きているサインです。
測るたびにスコアが変わる理由と、安定して計測するコツ
ページを何も変えていなくても、計測のたびにスコアは数点ほど上下します。Googleは、ネットワークの状態や計測環境の負荷などが変動の原因になると説明しています。広告やA/Bテストなど、表示されるたびに中身が変わる要素があるページでは、変動はさらに大きくなります。
出典：Google for Developers「PageSpeed Insights について」
1回の結果で一喜一憂しないために、次のルールで計測するのがおすすめです。
- 同じページを3回ほど計測し、中央の値を記録する
- 改善前後の比較は、同じ時間帯・同じ条件（モバイル／パソコン）でそろえる
- スコアの小さな上下より、Core Web Vitalsの各指標の値の変化を見る
BtoBサイトで成果につなげる改善の優先順位
PageSpeed Insightsの改善案をすべて対応しようとすると、工数がいくらあっても足りません。BtoBサイトでは、問い合わせや商談に近いページから順に直すのが鉄則です。
どのページから直すか：優先順位の判断表
次の2つの軸で、対象ページを並べ替えます。
優先度 | 条件 | 該当しやすいページ |
|---|---|---|
最優先 | CV導線上のページで、Core Web Vitalsが不合格 | 問い合わせフォーム、資料ダウンロードページ、サービスページ、料金ページ、広告の着地ページ |
高 | 流入が多く、CVのきっかけになっている記事で、Core Web Vitalsが不合格 | 検索流入の上位記事、CTA経由のクリックが多い記事 |
中 | Core Web Vitalsは合格だが、スコアが低い | テンプレートが共通の記事ページ全般 |
低 | 流入もCVも少ないページ | 更新が止まった古いお知らせ、アクセスのないアーカイブページ |
CV導線上のページは、GA4で「CVに至ったユーザーが直前に見たページ」を確認すると特定できます。また、記事ページの多くは同じテンプレートで作られているため、1ページの原因を直すとテンプレート全体に効果が及ぶこともあります。
よくある原因と対策、担当者の目安
改善案に表示される項目は多岐にわたりますが、BtoBサイトでよく見られる原因は次のとおりです。担当者の目安を入れているので、社内外の役割分担にも使えます。
よくある原因 | 悪化しやすい指標 | 主な対策 | 担当の目安 |
|---|---|---|---|
画像が大きすぎる・重すぎる | LCP | WebPなどの軽い形式への変換、表示サイズに合わせた縮小、ファーストビューの画像は遅延読み込みの対象から外す | マーケ（入稿時のルール化）・制作 |
計測タグ・広告タグ・チャットツールなどの外部スクリプトが多い | INP・TBT | 使っていないタグの削除、タグマネージャーの棚卸し、読み込みタイミングの見直し | マーケ（棚卸し）・開発 |
サーバーの応答が遅い | TTFB・LCP | キャッシュの設定、CDNの導入、サーバー環境の見直し | 開発・インフラ |
読み込みを妨げるCSS・JavaScript | FCP・LCP | 不要なコードの削除、読み込みの後回し・分割 | 開発 |
画像・バナー・埋め込みに表示領域が確保されていない | CLS | 画像や埋め込みに幅と高さを指定する、後から表示するバナーの領域をあらかじめ確保する | 制作 |
Webフォントの読み込み | FCP・CLS | 使う太さ・文字の絞り込み、読み込み中の表示方法の指定 | 制作 |
この中で、マーケティング担当者が主導しやすいのが画像と外部スクリプトです。キャンペーンのたびに追加した計測タグや、試験導入したまま残っているツールのタグは、多くのサイトで見つかります。まずはタグの一覧を作り、「今も使っているか」「誰が管理しているか」を確認するだけでも、改善の糸口になります。
SEOに効く画像対策とは？alt・ファイル名・サイズの最適化と「成果につながる画像」【2026年版】
開発・制作会社への依頼の出し方（テンプレート）
表示速度の改善は、実作業を開発者や制作会社が担うことが多い施策です。「スコアを上げてください」とだけ依頼すると、成果に関係の薄いページや項目に工数が使われてしまいます。依頼時は、次の6項目をそろえて伝えましょう。
- 対象URLと優先順位：判断表で決めた順番と、その理由（例：資料請求フォームのため最優先）
- 現状の値：Core Web Vitalsの合否、LCP・INP・CLSの75パーセンタイルの値、計測日
- 目標：例「3指標とも良好にする」。スコアの点数ではなく、指標で目標を置く
- PageSpeed Insightsで指摘された主な項目：レポートのURLとスクリーンショット
- 変更できないこと：削除できない計測タグ、変えられないデザインやツールなどの制約
- 確認方法と時期：修正直後はラボデータで確認し、約1か月後にフィールドデータで最終確認する
特に5つ目の「変更できないこと」を先に伝えておくと、「改善のためにタグを外したら計測ができなくなった」といった手戻りを防げます。
【表示速度の改善、どこから手をつけるか迷ったら】
改善後の効果測定と運用サイクル
表示速度の改善は、修正してすぐに結果がすべて出るわけではありません。フィールドデータは過去28日間の集計のため、改善の効果は日を追って少しずつ反映されます。次のサイクルで確認すると、効果を正しく判断できます。
タイミング | 確認するもの | 見るポイント |
|---|---|---|
修正直後 | PageSpeed Insightsのラボデータ | 指摘項目が消えたか、LCPやTBTの値が改善したか |
修正から約1か月後 | PageSpeed Insightsのフィールドデータ | Core Web Vitalsが合格になったか |
毎月 | Search ConsoleのCore Web Vitalsレポート | 「不良」「改善が必要」のURLが減っているか、新たに増えていないか |
毎月 | GA4 | 改善したページのCV率・フォーム到達率が変わったか |
最後のGA4の確認が、事業成果起点の運用では最も重要です。表示速度の改善を「技術的な宿題」で終わらせず、問い合わせ数や資料請求数の変化とあわせて振り返ることで、次にどこへ工数をかけるべきかが見えてきます。
また、表示速度は一度直しても、新しいタグの追加やサイトの改修で再び悪化します。月1回のチェックを定例に組み込み、ページを追加したときやタグを入れたときにも確認する習慣をつけましょう。
SEO内部対策とは？やるべき施策と優先順位を事業成果起点で解説【2026年版チェックリスト】
表示速度とLLMO・AIO対策の関係
AI検索が広がる中でも、表示速度を含むページ体験の重要性は変わりません。Googleは、AIを使った検索体験でコンテンツを活かすための方法の1つとして、優れたページ体験の提供を挙げています。従来の検索結果とAI検索のどちらから訪れたユーザーに対しても、どの端末でも適切に表示され、待たされない体験を届けることが重要だとしています。
出典：Google 検索セントラル ブログ「Google 検索の Google AI エクスペリエンスでコンテンツのパフォーマンスを高めるための主な方法」
一方で、表示速度を上げただけでAIに引用されやすくなるわけではありません。表示速度はあくまで「訪れたユーザーを逃さないための土台」です。AI検索で選ばれるかどうかは、質問に端的に答える構成や、自社にしかない一次情報といったコンテンツの中身で決まります。土台とコンテンツの両方を整えることが、AI検索時代の集客の基本です。
LLMO対策とは？SEO・AIOとの違いや具体施策をわかりやすく解説
一次情報とは？二次情報・三次情報との違いと成果につなげる集め方・使い方を徹底解説
【AIに「選ばれる」企業へ。】
PageSpeed Insightsに関するよくある質問
Q. PageSpeed Insightsの合格点は何点ですか？
A. パフォーマンススコアは90点以上が「良好」とされています。ただし、スコアはシミュレーションによる参考値です。実務では、実ユーザーのデータにもとづくCore Web Vitalsの評価が「合格」かどうかを判断基準にすることをおすすめします。
Q. PageSpeed InsightsとLighthouseの違いは何ですか？
A. Lighthouseは、決まった条件でページの読み込みを再現して計測するツールです。PageSpeed Insightsは、そのLighthouseの計測結果に、Chromeの実ユーザーから集めたデータを加えて表示します。公開中のページの状態を知りたいときはPageSpeed Insights、公開前のページやログインが必要なページを調べたいときはLighthouseが向いています。
Q. 「データが不足しています」と表示されるのはなぜですか？
A. 実ユーザーのデータ（フィールドデータ）を表示するには、一定以上のアクセス数が必要だからです。公開したばかりのページやアクセスの少ないページでは、ページ単体のデータが表示されず、サイト全体の集計だけが表示されることがあります。サイト全体でもデータが足りない場合は、フィールドデータは表示されません。その場合は、ラボデータの指標を目安に改善を進めます。
Q. スコアを上げれば検索順位は上がりますか？
A. 直結するとは限りません。GoogleはCore Web Vitalsをランキングシステムで使っていると説明していますが、評価が良くても上位表示が保証されるわけではないとしています。検索順位は、何よりページの内容が検索意図に合っているかで大きく左右されます。表示速度は、内容の良いページの評価やCVを下げないための土台と捉えるとよいでしょう。
Q. モバイルとパソコン、どちらの結果を重視すべきですか？
A. 基本はモバイルです。モバイルのほうが端末の性能や回線の条件が厳しく、問題が表れやすいためです。ただし、BtoBサイトはパソコンからのアクセスが多いケースもあります。GA4で自社サイトのデバイス別のアクセス比率とCV比率を確認し、CVの多いデバイスの結果を優先して見てください。
PageSpeed Insightsは「点数」ではなく「成果に近いページの体験」を見るツール
PageSpeed Insightsは、URLを入れるだけで表示速度の課題がわかる便利なツールです。ただし、成果につなげるには使い方にコツがあります。
まず、上段のCore Web Vitals（実ユーザーのデータ）で問題があるかを判断し、下段のスコアと改善案（シミュレーション）で原因を探すこと。そして、すべてのページで100点を目指すのではなく、問い合わせフォームやサービスページなど、商談に近いページから順に改善することです。改善後は、Core Web Vitalsの合否だけでなく、CV率の変化まで確認して振り返りましょう。
Habinyでは、オウンドメディアのSEO支援の中で、サイトの技術的な課題の洗い出しから優先順位づけ、コンテンツ制作、CV導線の改善まで一貫してサポートしています。「PageSpeed Insightsの結果をどう読めばいいかわからない」という段階からでも、お気軽にご相談ください。
【表示速度の改善、どこから手をつけるか迷ったら】
関連記事：
SEO内部対策とは？やるべき施策と優先順位を事業成果起点で解説【2026年版チェックリスト】
