PageSpeed Insightsとは？平均値の目安と改善するための7つの方法を解説
Webサイトの表示速度は、ユーザー体験と検索エンジンからの評価の両方に直結する重要な要素です。そこで活用したいのが、Googleが無料で提供している「PageSpeed Insights（ページスピードインサイト）」です。URLを入力するだけで、ページの読み込み速度・操作性・視覚的安定性を診断し、具体的な改善提案まで提示してくれます。
一方で、「スコアの見方が分からない」「90点を目指すべきなのか」「どこから手を付ければ改善が早いのか」といった声も少なくありません。本記事では、PageSpeed Insightsの基本概念とSEOへの影響、フィールドデータとラボデータの違い、Core Web Vitalsの3指標の合格基準、業界・サイト規模別の現実的なスコア目安、そして影響度の大きい順に並べた7つの改善方法までを、運用実務の目線で体系的に解説します。「PageSpeed Insightsをはじめて使う担当者」と「スコアを見ているが改善が頭打ちになっている担当者」の双方に役立つ内容です。
PageSpeed Insights（PSI、ページスピードインサイト）は、Googleが無料で提供しているWebページのパフォーマンス診断ツールです。計測したいページのURLを入力して「分析」をクリックするだけで、モバイルとデスクトップそれぞれについて、0〜100のパフォーマンススコア、Core Web Vitalsの実測値、改善提案の一覧を確認できます。会員登録やログインは不要で、計測回数の制限もなく、自社サイトだけでなく競合サイトの分析にも使えます。
計測単位はあくまでページ単位で、ドメインを入れてサイト全体を一括分析することはできません。したがって、サイト全体の健康診断としては、まずトップページや主要ランディングページから始め、その後アクセス数の多いページ、SEOで重要なページへと対象を広げていくのが現実的な使い方です。Google検索のページエクスペリエンスシグナルとも連動する仕組みのため、SEO実務では「Googleが公式に示すサイト表示の健康診断ツール」として位置づけられます。
PageSpeed Insightsを正しく読むうえで最初に押さえたいのが、レポートに表示される2種類のデータ、「フィールドデータ」と「ラボデータ」の違いです。フィールドデータは、Chromeユーザーエクスペリエンスレポート(CrUX)に基づく実ユーザーの体感データで、過去28日間に実際にそのページを訪問したユーザーが体験したCore Web Vitalsの分布が反映されます。SEO評価の対象となるのは、こちらのフィールドデータです。
一方ラボデータは、Lighthouseという計測エンジンが標準化された仮想環境(モバイル相当の回線・端末性能)でその場のページをシミュレーションした結果です。再現性が高く、改修前後の比較や、まだトラフィックが少なくフィールドデータが表示されないページの診断に向きます。実務では「実ユーザー体験はフィールドデータで把握し、原因の特定と改修の効果検証はラボデータで進める」という使い分けが基本です。スコア(0〜100の数値)はラボデータの結果で、厳密にはSEOの直接ランキング要因ではありません。SEO評価に直結するのは、その背後にあるCore Web Vitalsの実測値です。
PageSpeed Insightsのスコア自体は、Googleが公開しているランキングシグナルそのものではありません。しかし、その内訳であるCore Web Vitals(LCP・INP・CLS)は、Googleのページエクスペリエンスを構成するシグナルとして検索評価に影響します。同じくらいの品質のコンテンツが並ぶ局面では、表示速度や操作応答性、視覚安定性に優れたページのほうが選ばれやすくなる、と捉えるのが実態に近い理解です。
また、たとえSEOへの直接影響が小さい範囲でも、表示速度の改善はユーザー体験を通じて間接的にSEOにも効きます。ページの表示が遅いほど離脱率は上がり、コンバージョン率や回遊数は下がります。逆に表示が速いサイトは、滞在時間や再訪率、指名検索の伸びといった行動指標が改善し、結果的に検索順位にも好影響を与えます。「100点を目指すこと」ではなく、「実ユーザーの体験を悪化させているボトルネックを潰すこと」を目的にするのが、SEO実務として正しいPageSpeed Insightsの使い方です。
PageSpeed Insightsのパフォーマンススコアは0〜100で表示され、Lighthouseの複数指標を重み付けして算出されます。色分けは、0〜49が赤(Poor／低速)、50〜89が橙(Needs Improvement／改善が必要)、90〜100が緑(Good／良好)です。「緑＝合格」ですが、必ずしも90点を目指す必要はなく、業界水準と自社の改修コストを照らし合わせて現実的な目標を設定するほうが、運用上は健全です。
重要なのは、スコアはモバイルとデスクトップで別々に算出される点です。Googleはモバイルファーストインデックスを採用しているため、SEO観点では「モバイルのスコアを優先して改善する」のが原則です。多くのサイトでは、デスクトップは90点前後を出しやすい一方、モバイルはネットワークやCPUの制約から50〜70点台に留まりがちで、改善余地はモバイル側に集中しています。
LCP(Largest Contentful Paint／最大コンテンツの描画時間)は、ページ内で最も大きなコンテンツ要素(メインビジュアル画像、大見出し、動画のサムネイル等)が表示されるまでにかかる時間を示します。ユーザーが「このページ、ようやく表示された」と感じる体感速度に最も近い指標で、Core Web Vitalsの中でも改善インパクトが最も大きい指標として知られています。
Googleが公式に定める合格基準は、フィールドデータの75パーセンタイル値で2.5秒以内が「良好」、2.5秒超〜4.0秒以内が「改善が必要」、4.0秒超が「不良」です。LCPが遅い原因は、サーバー応答の遅さ、メイン画像のファイルサイズ過大、レンダリングをブロックするCSS／JavaScript、フォントの読み込み遅延などに集中しており、後述する改善方法の多くが直接LCPに効きます。
INP(Interaction to Next Paint)は、2024年3月にFID(First Input Delay)と入れ替わる形でCore Web Vitalsに正式採用された新しい指標です。FIDが「最初のクリック／タップへの初動反応」だけを測っていたのに対し、INPはページ閲覧中のすべてのインタラクションに対する応答速度を総合的に評価します。スマートフォンでメニューを開く、フォームに入力する、ボタンを押した瞬間に画面がもたつく、といった「操作してから画面が反応するまで」のラグの大きさを表す指標と捉えると分かりやすいです。
合格基準は、75パーセンタイル値で200ミリ秒以下が「良好」、200ミリ秒超〜500ミリ秒以下が「改善が必要」、500ミリ秒超が「不良」です。INPはJavaScriptのメインスレッド占有が主要因となるケースが多く、サードパーティスクリプト(チャットツール、広告タグ、ヒートマップ等)の重さや、自社実装のJavaScriptの肥大化が直撃しがちです。
CLS(Cumulative Layout Shift／累積レイアウトシフト)は、ページ読み込み中や閲覧中に、コンテンツがどれだけ意図せず動いてしまったかを示す指標です。リンクを押そうとした瞬間に広告が読み込まれてレイアウトがずれ、誤ったボタンを押してしまう、といった体験を数値化したもので、数値が小さいほど安定したレイアウトであることを意味します。
合格基準は、75パーセンタイル値で0.1以下が「良好」、0.1超〜0.25以下が「改善が必要」、0.25超が「不良」です。CLSの主要な発生源は、サイズ未指定の画像・iframe・広告枠、後から読み込まれて他要素を押し下げるWebフォント、上から差し込まれるバナーやお知らせ枠などです。技術的な対策が比較的シンプルなため、「改修コストに対する効果」が高く、優先的に手を入れる価値のある指標です。
「PageSpeed Insightsの平均値はどのくらいか」は多く聞かれる質問ですが、答えはサイトの種類によって大きく異なります。シンプルな構成のコーポレートサイトやブログでは、モバイル80点前後、デスクトップ95点前後を出しているサイトが珍しくありません。一方で、画像点数の多いECサイト、リッチな動きを持つメディアサイト、SaaSのマーケティングサイトでは、モバイル40〜60点台、デスクトップ70〜85点台が現実的なレンジで、それでも体感速度は十分速いケースが多くあります。
また、WordPressなど動的CMSで運用するサイトはプラグインの数や数の多さ、テーマの設計品質によってスコアが大きく振れます。「業界平均何点」という一律のベンチマークに振り回されるのではなく、自社サイトの種別・規模・主要競合と比較したうえで、現実的な到達点を設定するのが運用上のコツです。
スコアそのものの数値より、本質的に重要なのはCore Web Vitalsの3指標(LCP・INP・CLS)が、フィールドデータの75パーセンタイル値ですべて「良好」基準を満たしているかどうかです。Googleはこの「すべて良好を75%以上のユーザーが満たすこと」をCore Web Vitalsの合格条件と定義しており、Search Consoleの「ウェブに関する主な指標」レポートもこの考え方に沿って集計されます。
言い換えると、スコアが70点でもLCP・INP・CLSの3指標が「良好」帯にすべて入っているなら、SEO観点では十分に合格圏内です。逆にスコア90点でもCLSだけが「不良」なら、そのページはCore Web Vitals評価上は「不良」扱いになります。「総合スコアの数字」より「3指標が良好帯か」を上位の判断軸にするのが、現実的かつGoogleの設計思想にも沿った見方です。
現実的な目標設定としては、まずモバイルのCore Web Vitals 3指標すべてを「良好」帯(LCP≦2.5秒、INP<200ms、CLS≦0.1)に収めることを第一目標に据えるのが推奨されます。総合スコアは、その結果として50〜70点台から徐々に上がっていくため、順序を逆にすると施策の優先順位を見誤りやすくなります。スコアそのものは、改善の進捗を可視化する「成績表」として活用しつつ、絶対値を追いかけすぎないことがポイントです。
サイト構造を大きく変えられない既存サイトでも、「不良」帯から「改善が必要」帯、さらに「良好」帯へと段階的に引き上げるアプローチは現実的です。たとえばモバイルLCPが4.5秒のサイトを、まず3.5秒まで縮めて「改善が必要」帯に持ち込み、その後画像最適化とCDN導入で2.3秒に短縮し「良好」帯に到達させる、といった半年単位の改善ロードマップが、Webサイト改善プロジェクトの一般的な進め方になります。
ここからは、改善インパクトの大きい順に7つの方法を紹介します。最初の3つはLCPに直接効く施策、4〜5つ目はINPとCLSに効く施策、6〜7つ目はサイト全体の基盤と運用に関わる施策です。順序通りに着手することで、最も少ない工数で最も大きなスコア改善を実現できます。
画像の最適化は、最も即効性が高く、改修コストも比較的低いLCP改善策です。ポイントは3つあります。第一に画像フォーマットの最新化で、JPGやPNGを次世代フォーマットのWebP(場合によってはAVIF)に変換すると、見た目の品質を保ったままファイルサイズを30〜70%削減できます。第二に表示サイズに合わせた画像出力で、表示幅800pxの場所に2400pxの原寸画像を読み込ませる無駄をなくし、レスポンシブ対応にはsrcset属性でデバイスごとに最適なサイズを配信します。
第三に遅延読み込み(Lazy Loading)の導入で、画面外の画像はスクロールで近づいてから読み込むようにします。ただし、ファーストビュー内のメインビジュアル画像(LCP候補)は逆にpreloadで優先的に読み込ませるなど、「画面外＝遅延、ファーストビュー＝先読み」というメリハリが重要です。WordPressであれば画像最適化系プラグイン、ヘッドレスCMS環境であればNext.js／Nuxtの画像コンポーネントなど、フレームワーク標準の機能を積極的に活用すると、実装工数を最小化できます。
ブラウザはHTMLを解析する過程で、CSSとJavaScriptの読み込みを待ってから画面を描画します。ファーストビューに関係しない巨大なCSSや、本来あとから読めば足りるJavaScriptが先頭に置かれていると、その分だけLCPが遅れます。これが「レンダリングを妨げるリソース」で、PageSpeed Insightsの改善提案でも頻出する指摘項目です。
対策は、ファーストビューに必要なCSSをインライン化(クリティカルCSS)し、残りは非同期で読み込む、JavaScriptは可能な限りdefer／async属性をつけて読み込みを遅延させる、未使用のCSS・JSをビルドから除外する(Tree Shaking)、といった手法が王道です。特にWordPressなどテーマやプラグインが大量のCSS／JSを読み込む環境では、「実際にそのページで使われているリソース」だけに絞り込めば、モバイルスコアが20〜30点改善するケースも珍しくありません。
どれだけフロントエンドを最適化しても、サーバーからの初動レスポンス(TTFB／Time to First Byte)が遅ければLCPは改善しません。サーバー応答時間の短縮は、3つの方向で進めます。第一にホスティング環境の見直しで、共有サーバーから専用サーバーやマネージドサービス(VPS、クラウドのマネージドホスティング)への移行で大幅に改善することがあります。
第二にキャッシュ戦略で、サーバー側のページキャッシュ(WordPressならキャッシュ系プラグイン、ヘッドレスCMSならビルド時SSGや増分静的再生成)と、ブラウザキャッシュ(HTTPヘッダのCache-Control)を組み合わせ、同じユーザーや同じページへのアクセスでサーバー処理を繰り返さない構成にします。第三にCDN(Cloudflare、Fastly、Akamai等)の導入で、世界中のエッジロケーションからコンテンツを配信し、ユーザーとサーバー間の物理的距離を短縮します。サーバー応答時間が200ms以上のサイトでは、CDN導入だけでLCPが大きく改善するケースが多くあります。
INPの主要因はJavaScriptがメインスレッドを長時間占有することです。自社実装のJavaScriptが肥大化している場合は、コード分割(Code Splitting)で初回読み込み時に必要なコードだけに絞り、Tree Shakingで未使用コードを除外し、画面遷移時に必要なコードだけを動的にインポートする構成に変えます。Reactなどモダンフレームワークを使っている場合は、React.lazyやdynamic importで簡潔に実装できます。
もう一つの大きなINP悪化要因が、サードパーティスクリプト(チャットボット、ヒートマップ、A／Bテストツール、広告タグ、解析タグ、SNSの埋め込みなど)の重さです。これらが何十KB〜何百KBもメインスレッドを占有していることがあり、PageSpeed Insightsでも「サードパーティコードの影響を抑える」という提案で頻出します。対策は、使っていないスクリプトを完全に削除する、必要なものはタグマネージャーで遅延発火(DOMContentLoaded後、ユーザー操作後)に変更する、iframeで隔離して影響を限定する、などです。「すべてのタグを本当に使っているか」を四半期に1回棚卸しする運用を組み込むだけでも、INPの改善効果は大きくなります。
CLSは、技術的な対策が比較的シンプルでありながら効果が大きく、優先的に取り組むべき指標です。最も効くのは、すべての画像・iframe・動画・広告枠にwidth属性とheight属性(またはCSSのaspect-ratio)を指定することです。ブラウザが事前に表示領域を確保できれば、後から実コンテンツが読み込まれてもレイアウトがずれません。
次に、Webフォントの遅延による文字の入れ替わり(FOUT／FOIT)も典型的なCLSの原因です。font-display: swapで一旦システムフォントを表示しておき、Webフォント読み込み後に切り替える、代替フォントのメトリクスをWebフォントに近づける(size-adjustやfallback font metricsの調整)といった対策で、文字の入れ替わりによるシフト量を抑えられます。また、後から差し込まれるバナーやお知らせ枠は、あらかじめ固定の高さを確保しておくか、ページ最上部ではなくフローを邪魔しない位置に配置するのが鉄則です。
Webフォントは、デザイン上の重要な要素である一方、最適化されていないとLCP(テキスト中心のページではテキスト要素がLCP対象になる)・CLS(フォント切り替えによるシフト)の両方を悪化させます。改善策は、利用しているフォントウェイト・スタイルだけに絞ってロードする、サブセット化で日本語フォントのファイルサイズを大幅に削減する、preloadで先読みする、woff2など最新フォーマットを使う、などです。
アイコンも同様で、フォントアイコン(Font Awesomeなど)を読み込みでサイト全体のCSS／JSが肥大化している場合は、実際に使っているアイコンだけをSVGスプライトやSVGコンポーネントとして抽出する、もしくはアイコン専用フォントをサブセット化する、といった対応で改善できます。デザイン要件と表示速度のバランスは、最終的に経営判断に近い領域に入るため、「フォント数を絞る」「アイコンライブラリを軽量化する」といった選択肢を、デザインチームとマーケチームで共有しておくことが運用上重要です。
7つ目は技術施策ではなく、運用の話です。PageSpeed Insightsは一度計測して終わりではなく、「定期的に計測→ボトルネック特定→改修→再計測→効果検証」というサイクルを回すことで初めて成果が出ます。おすすめは、Search Consoleの「ウェブに関する主な指標」レポートを月1回チェックして、「不良」「改善が必要」ページの推移を継続的に把握する運用です。Search Consoleはフィールドデータベースでサイト全体の状況を集計表示するため、PageSpeed Insightsのページ単位分析と相互補完的に使えます。
改修は、影響範囲(アクセス数の多いページ／重要なランディングページ)と改修コスト(工数・リスク)のバランスで優先順位をつけます。トップページや主要LPで「不良」が出ているなら最優先、アクセス数の少ない記事ページであれば後回し、というように、現実的な優先順位を設定するのが運用のコツです。また、本記事で紹介した7つの改善を一気に実施するのではなく、施策単位で段階的にリリースし、各施策の効果をPageSpeed Insightsで計測しながら進めることで、何が効いたのかを切り分けられます。
最も多い失敗が、「90点」「100点」というスコアそのものを目的化してしまうパターンです。スコアを上げるためだけに、デザイン要件として必要だったWebフォントを削除する、コンバージョン率に効いていたチャットツールを外す、といった判断を行うと、表示速度は速くなる代わりにCV数や売上が下がる、という本末転倒の結果になりがちです。
対策は、PageSpeed Insightsを「事業KPI(CV数・売上・直帰率・滞在時間)と紐づけて評価する」運用に切り替えることです。Core Web Vitalsの3指標を「良好」帯に収めることを最低ラインとしつつ、それを超えるスコア最適化は「ユーザー体験と事業指標にどう影響したか」を計測しながら判断します。スコアは手段、事業成果が目的という順序を組織全体で共有しておくことが重要です。
デスクトップは90点出るのに、モバイルが60点台でも、「サイトは速い」と認識してしまうケースも頻発します。Googleはモバイルファーストインデックスを採用しており、SEO評価でもモバイル側のCore Web Vitalsが優先されます。BtoC・ローカルビジネス・メディア系のサイトはモバイルユーザーの比率が圧倒的に高く、BtoBサイトでも意思決定者のモバイル閲覧は年々増えています。
対策は、計測時に必ずモバイルとデスクトップの両方を確認し、改修の優先順位は原則モバイル側に置くことです。サイトのアナリティクスで実際のデバイス比率(モバイル：デスクトップ)を確認しておくと、社内での改修優先順位の合意形成がスムーズになります。「モバイルが遅いと感じるユーザーが半数以上いる」という事実をデータで提示できれば、開発リソース確保の説得力も大きく変わります。
PageSpeed Insightsのラボスコアは、計測のたびに数点〜十数点の変動が起きることがあります。サーバー側の負荷、計測地点のネットワーク状況、A／Bテスト中のバリエーション差、外部スクリプトの応答遅延など、さまざまな要因が絡むためで、「先週は85点だったのに今日は72点に下がった」と一喜一憂しても本質的な意味はありません。
対策は、ラボスコアは「同じ条件で複数回計測して中央値を取る」「改修前後の比較として相対的に使う」という運用に切り替え、絶対値で評価しないことです。長期トレンドや実ユーザー体験の評価は、フィールドデータとSearch Consoleのウェブに関する主な指標レポートで見ます。フィールドデータは過去28日間のロールアップなので、短期のノイズが平準化され、安定したトレンドが読み取りやすくなります。
PageSpeed Insightsは、Webページの表示速度・操作性・視覚的安定性を診断し、改善提案まで提示してくれるGoogle公式の無料ツールです。総合スコア(0〜100)はLighthouseがシミュレーションしたラボデータの結果で、SEOに直接効くのはその背後にあるCore Web Vitals(LCP・INP・CLS)のフィールドデータです。LCP≦2.5秒、INP<200ms、CLS≦0.1という「良好」基準を75パーセンタイル値で満たすことが、SEO観点・ユーザー体験観点の双方で合格圏内の条件となります。
改善方法は、影響度の大きい順に「画像の最適化」「レンダリングを妨げるリソースの排除」「サーバー応答時間の短縮とCDN活用」「JavaScriptの軽量化とサードパーティスクリプトの整理」「レイアウトシフトの抑制」「Webフォントとアイコンの読み込み最適化」「計測と改善の運用サイクル化」の7つに整理できます。LCPに効く施策(1〜3)から着手し、INPとCLSに対応し(4〜5)、サイト基盤と運用の整備(6〜7)へと進める順序が、最小工数で最大効果を出す現実的な進め方です。
重要なのは、「100点を目指すこと」自体を目的にせず、「実ユーザーの体験を悪化させているボトルネックを潰し、事業指標(CV数・売上・滞在時間)にどう貢献したか」で評価することです。本記事を出発点に、自社サイトのPageSpeed Insightsを計測し、Core Web Vitalsを「良好」帯に揃えるロードマップを設計し、Search Consoleと並走させた継続的な改善サイクルに踏み出してください。
SEOチェキの使い方を初心者向けに徹底解説。無料SEOチェックツールの定番「SEOチェキ」の基本概念と6つの主要機能（サイトSEOチェック／検索順位チェック／発リンクチェック／キーワード出現頻度／Whois情報／HTTPヘッダ情報）の使い方...
SEO内部対策とは何かを、外部対策・コンテンツ対策との違い、3つの目的（クローラビリティ／インデクサビリティ／ユーザビリティ）、HTMLタグ・サイト構造・クロール制御・構造化データ・ページエクスペリエンス・画像最適化などのカテゴリ別実装ガイ...
マーケティングKPI設計の全体像を、KGI・KPI・KSFの関係整理から、KGI因数分解とファネル展開によるKPIツリーの作り方、SMART原則による指標選定、認知～ロイヤル化までの代表的KPI（リーチ・指名検索・CVR・CPA・ROAS・...
