PageSpeed Insightsとは？使い方と活用方法を徹底解説！

自社サイトのPageSpeed Insightsのスコアが思ったより低くて、どこから手をつければいいか分からない。そんなお悩みではないでしょうか。

この記事では、PageSpeed Insightsの数字の正しい読み方から、表示速度を実際に上げるための改善手順、現場でやりがちな失敗の避け方までを、できるだけ専門用語をかみ砕いて解説します。非エンジニアの方でも、今日から自社サイトの「遅い原因」を見つけて動けるようになります。

Contents / 目次

1. PageSpeed Insightsで本当に見るべきは3つの数字だけ
2. PageSpeed Insightsの使い方と改善の進め方
3. 表示速度を上げると何が変わるのか
4. PageSpeed Insightsでやりがちな失敗と回避法
5. 現場で見えてくる、速度改善の落とし穴と本音
6. よくある質問

PageSpeed Insightsで本当に見るべきは3つの数字だけ

結論からお伝えします。PageSpeed Insightsを開いたときに、まず気にしてほしいのは総合スコア（0〜100の点数）ではありません。本当に見るべきは、ページの体験を表す「コアウェブバイタル」と呼ばれる3つの数字です。

もう少し詳しく言うと、Googleが検索順位を決めるときに参考にしているのは、点数そのものではなく「実際にサイトを訪れた人がどんな速さで体験したか」というデータです。これをフィールドデータと呼びます。点数を満点に近づけることより、この3つの数字を「良好」の範囲に収めることを目標にしましょう。

その3つの指標が、次の表です。専門用語が並びますが、かんたんに言うと「表示の速さ」「反応の速さ」「画面のガタつきの少なさ」の3点だと考えてください。

指標（呼び方）	かんたんに言うと	「良好」の目安
LCP（最大コンテンツの表示）	メイン画像や見出しが表示されるまでの速さ	2.5秒以内
INP（操作への反応）	ボタンやリンクを押したときの反応の速さ	200ミリ秒以内
CLS（画面のずれ）	読み込み中に文字や画像がガタッとずれない度合い	0.1以下

ここがポイント。2024年3月に、操作への反応を測る指標が従来のFID（First Input Delay）からINP（Interaction to Next Paint）に正式に置き換わりました（2026年6月13日時点）。今から改善に取り組むなら、INPを前提に考えるのが正解です。

やるべきことの全体像はシンプルです。第一に、PageSpeed InsightsとあわせてGoogle Search Consoleのコアウェブバイタルレポートで「実際のユーザーの数字」を確認すること。第二に、「不良」と判定された項目から優先的に直すこと。第三に、画像・コード・サーバーの順に効果の大きいところから手を入れることです。サーチコンソールの使い方そのものは検索流入を増やすならここから！Googleサーチコンソール徹底活用術でも詳しく解説しています。

PageSpeed Insightsの使い方と改善の進め方

では実際の進め方を見ていきましょう。難しそうに見えますが、順番どおりにやれば大丈夫です。まずは測定から始めます。

まずは測定する。最初の3ステップ

測定そのものは数分で終わります。最初にやることは次の3つです。

• URLを入力して測定する：GoogleのPageSpeed Insights公式ページに、調べたいページのURLを貼って実行します。
• モバイルを優先して見る：Googleはスマホ表示を基準に評価するため、まずモバイルの数字を確認しましょう。結果はモバイルとパソコンで切り替えられます。
• フィールドデータの有無を確認する：画面上部に「実際のユーザーの環境で評価する」という実データの欄が出ていれば、そこを最優先で読みます。出ていない場合はアクセス数が少なく、下のラボデータ（シミュレーション）で代用します。

つまり、点数の上下に一喜一憂する前に「実際のユーザーがどう体験しているか」を起点にする、ということです。ここを外すと、直しても順位に効かない無駄打ちが増えてしまいます。

改善の優先順位。効果が大きい順に手を入れる

診断結果の下のほうに「改善できる項目」が並びます。ここで全部に手を出すと時間がいくらあっても足りません。効果が大きく、かつ取り組みやすい順に整理すると、おおむね次のようになります。

優先度	やること	難易度
1（まずここ）	画像の圧縮・サイズ最適化・次世代フォーマット化	低〜中
2	使っていないCSS・JavaScriptの削減、遅延読み込み	中
3	サーバーの見直し（高速サーバー・PHP更新・キャッシュ）	中
4	不要なプラグイン整理（WordPressの場合）	低〜中

多くのサイトで、表示が遅い原因の一番手は「重たい画像」です。ひとことで言うと、スマホで見るのに何メガもある大きな写真をそのまま載せている状態です。具体的な直し方は次のとおりです。

• 表示サイズに合わせて縮小：横幅2000pxの写真を、実際の表示幅（例えば800px）に合わせて書き出し直します。
• WebPやAVIFに変換：JPEGやPNGより軽い次世代フォーマットに変えると、見た目を保ったままファイルが半分以下になることもあります。
• 遅延読み込み（Lazy Load）を使う：画面下のほうにある画像は、スクロールして近づいてから読み込ませます。ただし最初に見えるメイン画像には使わないこと。ここは後ほど失敗例で詳しく説明します。
• 幅と高さを指定する：画像タグにwidthとheightを入れておくと、読み込み中のガタつき（CLS）を防げます。

AIに「翻訳」させると改善のハードルが下がる

PageSpeed Insightsの診断結果は、正直なところ専門用語だらけで読みにくいです。「レンダリングを妨げるリソースの除外」と言われても、何のことかピンと来ませんよね。

ここで2026年ならではの使い方として、生成AIに診断結果を読ませて「自社サイトの場合、何を、どの順番で直せばいいか」を翻訳してもらう方法があります。具体的には、PageSpeed Insightsの「改善できる項目」のテキストや、自社サイトのコードの一部をAIに貼り付けて、「非エンジニアにも分かる言葉で、優先順位をつけて説明して」と頼みます。そうすると、専門用語が日常の言葉に変わり、判断がぐっと楽になります。

ただし、AIが出したコードの修正案を中身を理解しないまま本番サイトに貼り付けるのは危険です。テーマやプラグインと相性が悪く、表示が崩れたりサイトが真っ白になったりすることがあります。必ずバックアップを取り、テスト環境で確認してから反映しましょう。

表示速度を上げると何が変わるのか

「速くして本当に意味があるの？」と感じる方もいるでしょう。ここでは、速度改善がビジネスにどうつながるのかを具体的な数字でお伝えします。

表示速度は、検索順位だけでなく、売上や問い合わせ数に直結します。報告されている事例を挙げると、ある通信会社ではLCP（メイン表示の速さ）を31%改善した結果、売上が8%増えたとされています。また、表示が3.2秒から1.8秒に短縮されたことで、検索順位が平均7位上がったという報告もあります。

なぜここまで効くのか。理由はシンプルで、人は待たされると離れるからです。スマホで開いて2〜3秒たっても表示されなければ、多くの人は戻るボタンを押します。せっかく広告費をかけて呼んだお客さまも、表示が遅いだけで会う前に帰ってしまうイメージです。逆に言えば、速度を上げることは「取りこぼしを減らす」もっとも費用対効果の高い改善の一つなのです。

知っておきたい現実。2026年時点でも、世界中のサイトのうちコアウェブバイタルの3つの基準をすべて満たしているのは半数ほどにすぎません。モバイルでは半数以上が基準未達とされています。裏を返せば、ここをきちんと整えるだけで競合に差をつけられる、ということです。

成果を出している企業に共通しているのは、一度直して終わりにせず、月に1回など定期的に測って改善を続けている点です。問い合わせが増えない原因が速度以外にあるケースも多いので、あわせてホームページから問い合わせが来ない理由とは？改善で変わる反応率！も確認しておくと、改善の的を外しません。

PageSpeed Insightsでやりがちな失敗と回避法

ここからは、現場で本当によく見かける失敗を紹介します。先に知っておくだけで、無駄な労力をかなり減らせます。

失敗1。100点満点を目指して消耗する

もっとも多いのがこれです。総合スコアを100点にしようと頑張りすぎるケースです。実は、ラボデータで100点を取るには、Googleアナリティクスや広告タグ、SNSの埋め込みといった計測・集客に必要なものをすべて外す必要があり、現実的ではありません。

こうなると、点数のために本来必要な機能を削るという本末転倒が起きます。防ぎ方は明確です。点数はモバイルで60〜70点台、パソコンで85点前後を安定して出せれば十分と割り切り、あとはフィールドデータ（実ユーザーの数字）を良好に保つことに集中しましょう。Googleが順位評価に使うのも、点数ではなくこの実データのほうです。

失敗2。メイン画像にまで遅延読み込みをかけてしまう

速度改善の定番である遅延読み込み（Lazy Load）を、サイト全体に一括で適用してしまうケースです。一見良さそうに見えますが、最初に表示されるメイン画像（LCP要素）にまで遅延をかけると、かえってメインの表示が遅くなり、LCPが悪化します。

つまり「良かれと思った設定が、一番大事な数字を下げる」という状態です。回避するには、ファーストビュー（最初に見える範囲）の画像だけは遅延読み込みの対象から外す設定にします。WordPressのプラグインを使う場合は、除外設定の項目があるか確認してから有効にしましょう。

失敗3。安いサーバーのまま、コードだけいじり続ける

画像もコードも整えたのに数字が上がらない。そんなときに見落とされがちなのが、サーバーの応答速度です。安価な共有サーバーは、他の利用者の影響を受けて反応が不安定になりやすく、実ユーザーの数字（CrUX）が悪化することがあります。

この場合、いくらコードを削っても土台が遅いので効果が頭打ちになります。防ぎ方としては、PHPのバージョンを最新に上げる、ブラウザキャッシュやBrotli・gzipといった圧縮を有効にする、それでも改善しないなら高速なサーバーへの引っ越しを検討する、という順で見直します。

失敗4。1ページずつ直して、全体が一向に終わらない

トップページだけ手作業で直して満足してしまうパターンです。サイトは多くの場合、同じテンプレート（共通の型）から各ページが作られています。1ページずつ直すより、テンプレートのレベルで直したほうが、全ページにまとめて効きます。最初に「どの型を直せば一番多くのページに効くか」を考えてから着手すると、労力が何分の一にもなります。

現場で見えてくる、速度改善の落とし穴と本音

ここまで読んで「自分でもできそう」と感じた方もいれば、「やっぱり難しそう」と感じた方もいると思います。最後に、教科書には載りにくい現場の本音をお伝えします。

正直に言うと、画像の圧縮やプラグインの整理あたりまでは、社内でも十分に取り組めます。ここは外注するより、自分たちで回せるようにしたほうがコストも納期もコントロールしやすいです。一方で、CSSやJavaScriptの削減・分割、サーバー設定の最適化になると話は別です。中身を理解せずに触ると、見た目や機能が壊れるリスクが一気に上がります。ここが「自分でやる範囲」と「プロに任せる範囲」の分かれ目です。

最近増えているのが、AIにサイトのコードを書かせて短期間で作る、いわゆるVibe codingで立ち上げたサイトの速度問題です。見た目はきれいでも、不要なライブラリを大量に読み込んでいたり、画像が最適化されていなかったりして、公開後にPageSpeed Insightsの数字が思ったより伸びないケースをよく見かけます。AIで速く作れる時代だからこそ、公開前の速度チェックは欠かせません。

もう一つの落とし穴がコストの見落としです。速度改善だけを単発で外注すると、毎回費用がかかるうえ、サイトを更新するたびに数字が元に戻ることもあります。本当に大事なのは「直すこと」より「速い状態を保てる作り方」に変えることです。だからこそ私たちは、その場しのぎの改善ではなく、社内で測定・改善を回せる状態づくりまで含めて伴走することを大切にしています。業者を選ぶときも、点数を上げるだけでなく「なぜ遅いのか」「どう保つのか」を自社の言葉で説明してくれる相手かどうかを基準にすると、失敗が減ります。サイト全体の設計から見直したい方は自社サイトを企業の強みにする方法 最新版Webデザインの基本もあわせてどうぞ。

よくある質問

ここまで読んで、画像までは自分たちでやれそうだけど、コードやサーバーまで含めて「速い状態を保てる作り方」に変えるのは難しそう、と感じた方もいるかと思います。コレットラボでは、AIを活用したサイトの内製化・運用効率化の伴走支援を行っています。まずは現状のサイトを一緒に整理するだけでも大丈夫です。気になった方はAI業務システム化の詳細はこちらから、お気軽にお話を聞かせてください。