PageSpeed Insightsの見方｜初心者が確認したい数値と改善の優先順位

公開: 2026年9月19日更新: 2026年9月27日

PageSpeed Insightsでサイトを測定すると、点数や専門用語が数多く表示されます。モバイルの点数が低く、「すぐにプラグインやサーバーを変更すべきだろうか」と不安になることもあるでしょう。

しかし、PageSpeed Insightsの点数は、サイトの状態を確認するための一つの手がかりです。一回の測定結果や総合点だけで、サイトの良し悪しがすべて決まるわけではありません。

この記事では、PageSpeed Insightsを初めて使う方に向けて、最初に見る場所と改善の優先順位を整理します。

PageSpeed Insightsで分かること

PageSpeed Insightsは、URLを入力してWebページの状態を確認できるGoogleのツールです。モバイルとデスクトップの両方を測定でき、表示速度や操作性に関する指標と改善のヒントが表示されます。

結果には、大きく分けて次の2種類の情報があります。

実際のユーザー環境から集計されたデータ
一定の条件でページを読み込んだ診断データ

この2つは目的と測定条件が異なるため、数値が一致しないことがあります。まずは両者を区別して読むことが大切です。

「実際のユーザーの環境」と「パフォーマンスの問題を診断する」を区別する

PageSpeed Insightsの上部に表示される「実際のユーザーの環境で評価する」は、Chromeユーザーの利用状況を匿名で集計したChrome UX Report（CrUX）のデータです。過去28日間の実際の閲覧環境が反映されます。

一方、「パフォーマンスの問題を診断する」は、Lighthouseが特定の端末や通信条件を想定して実行するラボデータです。改善箇所を調べるために役立ちますが、実際のすべての利用者の体験をそのまま示すものではありません。

公開直後のページやアクセス数が少ないページでは、実ユーザーデータが十分に集まっていない場合があります。その場合は、ページ単位ではなくサイト全体のデータが表示されたり、実ユーザーデータ自体が表示されなかったりします。これは測定の失敗とは限りません。

Core Web Vitalsの3指標を見る

実ユーザーデータでは、Core Web Vitalsと呼ばれる次の3指標を確認します。

LCP：主要な内容が表示されるまでの時間

LCP（Largest Contentful Paint）は、画面内の主要な画像や大きなテキストが表示されるまでの時間を表します。良好とされる目安は2.5秒以内です。

LCPが遅い場合は、大きなメイン画像、サーバーの応答時間、読み込みを妨げるCSSやJavaScriptなどが関係している可能性があります。

INP：操作への反応の速さ

INP（Interaction to Next Paint）は、クリックやタップ、キーボード操作に対して画面が反応するまでの時間を示します。良好とされる目安は200ミリ秒以内です。

重いJavaScriptや長時間続く処理があると、ボタンを押しても反応が遅いと感じることがあります。なお、INPは実際のユーザー操作を必要とするため、ラボ環境では同じ方法で直接測定できません。診断ではTotal Blocking Time（TBT）なども手がかりになります。

CLS：表示中のレイアウトのずれ

CLS（Cumulative Layout Shift）は、読み込み中に画像やボタンなどの位置が予期せず動く度合いを表します。良好とされる目安は0.1以下です。

画像に幅と高さが指定されていない、広告や埋め込みコンテンツの領域が事前に確保されていない、読み込み後にフォントが切り替わる、といった場合に悪化することがあります。

モバイルとデスクトップは別々に確認する

PageSpeed Insightsでは、モバイルとデスクトップの結果が分かれています。一般にモバイルの診断は、端末性能や通信条件を厳しく想定するため、デスクトップより点数が低くなることがあります。

そのため、デスクトップが高得点だから問題がない、モバイルが低得点だから直ちにサイト全体が使えない、と単純には判断できません。

まず、読者が多く利用する側を優先しながら、両方で次の点を確認します。

主要な文字や画像が表示されるまで長く待たされないか
メニューやボタンを問題なく操作できるか
読み込み中に文字やボタンの位置が大きく動かないか
フォームやリンクなど主要な機能が使えるか

数値だけでなく、実際の端末でも表示と操作を確認します。

パフォーマンススコアは100点だけを目指さない

診断結果のパフォーマンススコアは、複数の指標を重み付けして0から100で表したものです。Googleの区分では、90〜100が良好、50〜89が改善の余地あり、0〜49が不良とされています。

ただし、測定時の通信状況、配信される広告、A/Bテスト、端末、ブラウザ拡張機能などによって、結果が変動することがあります。100点を一度取ることより、主要ページで深刻な問題がなく、変更前より安定して改善しているかを見る方が実務的です。

同じページを複数回測定し、大きく数値が異なる場合は中央値を参考にします。変更前後は、できるだけ同じURL、同じ時間帯、同じ測定方法で比較します。

改善項目は影響と安全性で並べる

PageSpeed Insightsには多くの改善候補が表示されますが、すべてを同時に対応する必要はありません。次の順で整理すると、作業による不具合を避けやすくなります。

1. 大きな画像と不要な埋め込みを確認する

容量の大きな画像や、使っていない動画・SNS埋め込みは比較的見つけやすい項目です。表示サイズに合った画像へ変更し、必要に応じてWebPやAVIFへの変換、圧縮、遅延読み込みを検討します。

2. WordPressとプラグインの状態を確認する

使っていないプラグインや、各ページで不要なCSS・JavaScriptを読み込むプラグインがないか確認します。ただし、停止によってフォームやセキュリティ機能が使えなくなることもあるため、本番環境で一括停止はしません。

3. サーバーの応答とキャッシュを確認する

ページのHTMLが返り始めるまで遅い場合は、サーバーの応答やキャッシュ設定が関係している可能性があります。契約中のサーバーが提供するキャッシュ機能を確認してから、追加のプラグインを検討します。

4. CSSやJavaScriptの最適化は慎重に行う

「使用していないJavaScriptの削減」や「レンダリングを妨げるリソース」と表示されても、ファイルを機械的に削除してはいけません。遅延、結合、圧縮の設定によって、メニューやアニメーション、フォームが動かなくなることがあります。

バックアップやステージング環境を用意し、一項目ずつ変更して確認します。

測定結果を保存してから改善する

改善前の結果を残しておくと、変更の効果を判断しやすくなります。最低限、次の内容を記録します。

測定したURL
測定日時
モバイルまたはデスクトップ
パフォーマンススコア
LCP・INP・CLSの状態
主な改善候補
変更した内容
変更後の結果

複数の対策を同時に行うと、効果や不具合の原因が分からなくなります。一項目変更したら、キャッシュを削除し、同じページを再測定して、実際の端末でも確認します。

WordPressサイト全体の改善手順は、WordPressが遅いときの改善方法｜初心者でも確認できる7つのポイントで整理しています。

まとめ

PageSpeed Insightsを見るときは、総合点だけでなく、まず実ユーザーデータと診断データを区別します。そのうえでLCP・INP・CLSを確認し、実際の端末で閲覧や操作に問題がないか確かめます。

改善は、画像や不要な埋め込みなど確認しやすい項目から始め、プラグイン、キャッシュ、CSS・JavaScriptへ進みます。100点を目標に設定を重ねるのではなく、一項目ずつ安全に変更し、前後の結果を比較することが大切です。

参考資料

確認日：2026年9月15日