PageSpeed Insightsでは、最初にパフォーマンススコアを見るのではなく、モバイル・パソコン別のフィールドデータとCore Web Vitalsを確認することが重要です。実際の利用者が感じている表示速度、操作への反応、レイアウトの安定性を把握してから改善項目を読むと、優先順位を誤りにくくなります。
モバイルは端末性能や通信環境の影響を受けやすく、パソコンよりスコアが低く出ることがあります。ただし、片方の点数だけでサイト全体の品質を断定するべきではありません。重要ページをデバイス別・ページ種別ごとに確認することが必要です。
この記事では、PageSpeed Insightsの結果を読む順番、モバイルとパソコンの違い、LCP・INP・CLSを起点にした改善の優先順位、WordPressで確認しやすいポイントを解説します。
最初に確認するのはスコアではなく実ユーザーのCore Web Vitals
PageSpeed Insightsで優先すべきなのは、「実際のユーザーに関する指標」に表示されるフィールドデータです。対象URL、またはURL単位のデータが不足する場合はサイト全体（オリジン）の実ユーザー体験をもとに、Core Web Vitalsを満たしているか確認します。
改善の起点は点数ではなく実ユーザー体験です。フィールドデータでLCP・INP・CLSのいずれかが不良なら、その指標に関係する課題を優先してください。フィールドデータが良好で、ラボデータのパフォーマンススコアだけが低い場合は、実際の影響、再現性、実装コストを見て対応を判断します。
PageSpeed Insightsは、Chrome UX Report（CrUX）にもとづく過去28日間のフィールドデータと、Lighthouseが一定条件下で取得するラボデータを表示します。ラボデータは技術的な原因調査や変更前後の比較に有用ですが、すべての利用者の環境を再現するものではありません。
出典：Google for Developers「About PageSpeed Insights」
PageSpeed Insightsの結果画面はこの順番で見る
結果画面の警告を上からすべて処理する必要はありません。以下の順で確認すると、「利用者に起きている問題」と「技術的な原因候補」を切り分けやすくなります。
- モバイルとパソコンを切り替える
- 「実際のユーザーに関する指標」とCore Web Vitalsの評価を見る
- LCP・INP・CLSのどれが問題かを特定する
- パフォーマンススコアをラボ環境での比較指標として確認する
- 「改善できる項目」「診断」から原因候補を絞る
モバイルとパソコンを同じURLで比較する
PageSpeed Insightsは、同じURLでもモバイルとパソコンで別々の結果を表示します。まず両方を確認し、問題がどちらかに集中しているのか、共通しているのかを見分けてください。
重要ページはデバイス別に比較します。トップページだけでなく、記事、商品詳細、カテゴリ、問い合わせなど、テンプレートや機能が異なるページ種別も計測します。ヘッダー、広告、商品画像、フォーム、レビュー機能が違えば、原因と対策も変わるためです。
フィールドデータはURL単位で表示される場合と、十分なURL単位データがないためオリジン単位で表示される場合があります。結果を判断する前に、どちらのデータかを確認しましょう。
出典：Google for Developers「About PageSpeed Insights」
Core Web Vitalsで問題の種類を特定する
「実際のユーザーに関する指標」では、LCP、INP、CLSなどが良好・改善が必要・不良の区分で示されます。色だけで施策を決めず、どの指標が悪いかを確認することが重要です。
赤やオレンジは原因調査の優先信号です。たとえばLCPだけが悪い場合は、画像、サーバー応答、初期表示のリソースを中心に調べます。INPやCLSと関係が薄い細かな警告を先に消すより、問題の指標に直結する要因を確認するほうが効率的です。
Core Web Vitalsの評価は、各指標の75パーセンタイル値を基準に判定されます。最も条件のよい一部の利用者だけではなく、比較的厳しい環境を含む利用者体験を評価する考え方です。
出典：web.dev「How the Core Web Vitals metrics thresholds were defined」
パフォーマンススコアは原因調査と比較に使う
パフォーマンススコアは、Lighthouseのラボデータをもとに算出されます。スコアが低い場合は、初期表示やJavaScript処理に課題がある可能性を確認するきっかけになります。
スコア100点を目標にする必要はありません。ラボデータが良くてもフィールドデータが悪いことがあり、その逆もあります。スコアは、同じURL・同じデバイス区分・近い条件で、変更前後を比較する用途に向いています。
Googleは、ラボデータが管理された環境でのデバッグに役立つ一方で、実環境におけるすべてのボトルネックを反映しない場合があると説明しています。
出典：web.dev「Why lab and field data can be different (and what to do about it)」
「改善できる項目」と「診断」は対応候補として読む
「改善できる項目」や「診断」は、すべてを必ず修正するToDoリストではありません。Lighthouseが検出した改善機会や、確認すべき技術的な兆候として読みます。
主要指標への影響を確認して選別します。推定削減時間が大きくてもLCP・INP・CLSが必ず改善するとは限りません。反対に、全ページに共通する重いタグやレンダリングを妨げるCSSは、表示上の警告が小さく見えても優先度が高い場合があります。
- どのCore Web Vitalsに影響する可能性があるか
- 対象ページだけの問題か、全ページ共通の問題か
- 機能、デザイン、広告、計測タグに副作用がないか
- 修正後に検証できる環境があるか
モバイルとパソコンで結果が違う主な理由
モバイルとパソコンの結果が異なることは珍しくありません。特にラボデータは端末性能とネットワーク条件の影響を受けるため、モバイルのほうが厳しい数値になりやすい傾向があります。
モバイルは処理性能と通信環境の制約を受けやすい
モバイルでは、JavaScriptの解析・実行、画像のダウンロード、外部ドメインへの接続が、パソコンより大きな負担になりやすいことがあります。画像やスクリプトの量が同じでも、端末のCPU性能や通信状況によって体感差は広がります。
重いJavaScriptは操作性を悪化させやすい要因です。長時間メインスレッドを占有する処理があると、タップやメニュー操作に対する画面更新が遅れ、INPに悪影響を与える可能性があります。
出典：web.dev「Optimize long tasks」
デバイス別のページ構成が異なる場合がある
レスポンシブサイトでも、モバイルでは画像サイズ、メニュー構造、広告枠、カルーセル、追従ボタン、埋め込みコンテンツが変わることがあります。パソコンでは非表示の要素がモバイルで読み込まれていたり、モバイルで別画像を表示していたりするケースもあります。
モバイルだけ悪い場合は実際の読み込み内容を確認します。単にスマートフォンの性能差と考えず、モバイル用のHTML、CSS、画像、広告、タグの読み込み順を調べてください。ラボデータは一度だけで断定せず、複数回の測定とフィールドデータの照合で傾向を判断します。
Core Web Vitalsの見方と主な改善方向
改善の優先順位を決めるには、指標名を覚えるだけでは不十分です。各指標がどの利用者体験を示し、どのような原因とつながりやすいかを把握しましょう。
LCP：メインコンテンツが表示されるまでの速さ
LCP（Largest Contentful Paint）は、表示領域内で最も大きな画像またはテキストブロックが描画されるまでの時間です。記事のアイキャッチ、商品画像、ファーストビューのヒーロー画像、大きな見出しなどがLCP要素になることがあります。
LCPは2.5秒以下が良好の目安です。4秒超は不良とされます。LCPが悪い場合は、PageSpeed InsightsでLCP要素を確認し、その画像やテキストが早く発見・取得・描画されているかを調べます。
- メイン画像が表示サイズに対して著しく大きい
- ファーストビューの画像に遅延読み込みが設定されている
- サーバー応答が遅く、HTMLの取得開始が遅い
- 初期表示を妨げるCSSやJavaScriptが多い
- JavaScriptで後から主要コンテンツを生成している
LCP候補の画像へ一律に遅延読み込みを適用すると、読み込み開始が遅れ、LCPを悪化させる可能性があります。
出典：web.dev「Optimize Largest Contentful Paint」
INP：操作に対する画面の反応の良さ
INP（Interaction to Next Paint）は、クリック、タップ、キーボード入力などに対し、画面が視覚的に反応するまでの応答性を示す指標です。以前のFIDとは別の現行指標であるため、古い解説を参照する際は混同しないよう注意してください。
INPは200ミリ秒以下が良好の目安です。悪化している場合は、メニュー、検索、絞り込み、カート追加、フォーム送信、タブ切り替えなど、利用者が実際に操作する箇所を確認します。
原因には、重いテーマ機能、不要なプラグイン、広告・アクセス解析・チャットなどの第三者JavaScript、複雑なイベント処理、大量のDOM要素が考えられます。JavaScriptファイルの容量だけでなく、読み込み後にどの処理がメインスレッドを長く占有しているかを見ることが重要です。
出典：web.dev「Optimize Interaction to Next Paint」
CLS：表示中のレイアウトずれの大きさ
CLS（Cumulative Layout Shift）は、ページを読んでいる途中でボタンや文章が押し下げられるなど、予期しないレイアウトずれを数値化した指標です。誤って別のボタンを押す原因にもなります。
CLSは0.1以下が良好の目安です。主な原因は、サイズが予約されていない画像・動画・広告枠・埋め込み要素、後から挿入されるバナー、Webフォントの切り替わりなどです。
画像や動画には幅と高さを指定するか、CSSで表示領域の比率を確保します。広告やiframeも、表示後にコンテンツを押し下げないよう、あらかじめスペースを確保する設計が必要です。
出典：web.dev「Optimize Cumulative Layout Shift」
FCP・TBT・Speed Indexは原因を絞る補助指標
FCPは最初のコンテンツが表示されるまで、TBTはメインスレッドを長くブロックする処理の傾向、Speed Indexは画面の見た目がどの程度早く埋まるかを把握するためのラボ指標です。
補助指標はCore Web Vitalsの原因特定に使います。たとえばFCPからLCPまでの差が大きい場合は、メイン画像や主要コンテンツの表示が遅れている可能性があります。TBTが高い場合は、JavaScriptの実行や外部スクリプトを確認するきっかけになります。
改善項目はこの優先順位で判断する
改善は、警告の数や推定削減時間だけで順番を決めません。実ユーザーへの影響、影響範囲、実装リスクを合わせて優先順位を付けます。
優先1：フィールドデータで不良のLCP・INP・CLS
最優先は、フィールドデータで不良になっているCore Web Vitalsです。実際の利用者に継続的な問題が起きている可能性があるため、対象URLとページ種別を確認し、どの利用体験が悪いかを特定します。
実ユーザーで不良な指標を先に直します。たとえば商品詳細ページだけでLCPが不良なら、商品画像、在庫表示、レビューウィジェット、関連商品など、そのテンプレート固有の要因を調査します。
優先2：主要指標に直結する課題
LCPではメイン画像の読み込み開始、サーバー応答、レンダリングを妨げるリソースを確認します。INPでは長いJavaScript処理や操作イベント、CLSでは表示領域の未確保を中心に確認してください。
最適化は機能への影響を確認して実施します。CSSやJavaScriptをすべて遅延させると、表示崩れや機能不全を起こすことがあります。初期表示に必要なものと不要なものを分け、検証環境で確認してから公開します。
出典：Chrome for Developers「Eliminate render-blocking resources」
優先3：全ページに影響する共通要素
ヘッダー、共通CSS、テーマの基本機能、フォント、タグ管理ツール、広告タグ、キャッシュ設定などは複数ページに影響します。1ページだけの軽微な最適化より、共通部分の改善が大きな効果につながる場合があります。
横展開できる課題は費用対効果を確認します。広告、コンバージョン計測、同意管理、チャットは事業上必要な場合があります。単純に削除するのではなく、読み込みタイミングの変更、必要ページへの限定、代替手段の検討を行います。
優先4：軽微な診断項目は効果と副作用で選別する
未使用CSS、未使用JavaScript、DOMサイズ、細かな画像圧縮などの診断は、サイトによって重要度が異なります。主要指標に問題がない状態でも、保守性や転送量の削減を目的に取り組む価値はあります。
警告を消すこと自体を目的にしません。機能を壊してスコアだけを上げても、利用者体験、売上、計測精度を損なうおそれがあります。変更内容、期待する効果、影響範囲、元に戻す方法を記録してから実施しましょう。
WordPressで確認したい代表的な改善ポイント
WordPressでは、テーマ、プラグイン、画像運用、広告、計測タグ、キャッシュ設定が複合して速度に影響します。プラグインを増やす、または削除するだけでは解決しないため、どのページで何が読み込まれているかを確認することが前提です。
画像のサイズ・形式・表示領域を見直す
画像はLCPとCLSの両方に関係しやすい要素です。アップロード画像が表示領域より著しく大きい、テーマが適切なサムネイルサイズを使っていない、ファーストビューの画像まで遅延読み込みしている、といった状態がないか確認します。
最初に見える重要画像は遅延読み込みしません。一方、ページ下部の画像や一覧後半の画像は遅延読み込みが有効な場合があります。WebPやAVIFの採用も選択肢ですが、画質、対応環境、変換処理、既存画像の運用を含めて判断してください。
出典：web.dev「Browser-level image lazy loading for the web」
テーマ・プラグイン・外部JavaScriptを棚卸しする
特定ページでしか使わない機能が全ページで読み込まれていることがあります。スライダー、SNS埋め込み、地図、チャット、広告、アクセス解析、ヒートマップは確認対象です。
停止前に必ず検証環境で影響を確認します。プラグインを無効化すると、フォーム送信、購入計測、会員機能、セキュリティ、バックアップに影響する可能性があります。不要と判断したものも、表示・機能・計測・管理画面への影響を確認したうえで整理してください。
キャッシュ導入後は更新と購入導線を確認する
ページキャッシュ、ブラウザキャッシュ、CDN、圧縮設定は有効な場合があります。ただし、更新した画像やCSSが反映されない、ログイン状態の表示が崩れる、ECサイトのカート内容が正しく表示されない、といった問題も起こり得ます。
キャッシュは更新との両立が必要です。導入後は、未ログイン時・ログイン時・フォーム送信・購入導線を分けて確認しましょう。
改善後の再計測と効果確認
改善施策は、実装して終わりではありません。ラボデータとフィールドデータの性質が異なるため、何をもって改善と判断するかを事前に決めておくと評価がぶれにくくなります。
同じURL・同じデバイス区分で変更前後を比較する
比較時は、同じURL、同じモバイルまたはパソコン区分で確認します。変更前の画面、指標値、実施内容、実施日時、表示や計測への影響を記録すると、複数施策を行った後でも効果を追いやすくなります。
一度に大きく変えすぎないことも重要です。複数のプラグイン、画像、テーマ設定、タグを同時に変更すると、どの施策が効果または不具合の原因か判断しにくくなります。
フィールドデータは変更直後に評価しない
ラボデータは実装後の確認にすぐ使えます。一方、PageSpeed Insightsのフィールドデータは過去28日間の実ユーザー体験をもとにした集計であるため、変更直後に大きく変わらないことがあります。
フィールドデータは時間をかけて評価します。改善後すぐにラボデータで原因が解消したかを確認し、その後にフィールドデータやGoogle Search ConsoleのCore Web Vitalsレポートで傾向を確認する流れが実務的です。
出典：Chrome for Developers「CrUX Tools」
PageSpeed Insightsに関するよくある質問
PageSpeed Insightsを運用する際に迷いやすい点を、本文の補足として整理します。固定のスコアだけで判断せず、利用者とサイトの目的に合わせて確認してください。
モバイルとパソコンはどちらを優先すべきですか？
アクセスや売上への影響が大きいデバイスを優先します。ただし、どちらかで不良なCore Web Vitalsを放置しないことが原則です。モバイル流入が中心ならモバイルを先に、パソコン利用が多いサイトならパソコンも重視しつつ、両方の共通原因を確認します。
パフォーマンススコアは何点なら問題ありませんか？
固定の点数だけでは判断できません。ラボデータでは90点以上が緑の目安ですが、重要なのはフィールドデータのCore Web Vitals、重要ページでの体感、操作や購入導線に支障がないかです。スコアより不良指標の有無を優先します。
フィールドデータが表示されないのはなぜですか？
公開直後のページやアクセス数が少ないページでは、CrUXに十分な実ユーザーデータが集まっていない場合があります。URL単位のデータがないときはオリジン単位のデータが表示されることがあり、オリジン単位でも不足していればフィールドデータは表示されません。
その場合もラボデータで初期表示の課題や改善候補は確認できます。ただし、ラボデータだけで実ユーザー体験を断定しないようにしてください。
出典：Google for Developers「About PageSpeed Insights」
まとめ：スコアではなく実ユーザー体験を基準に改善する
PageSpeed Insightsの見方で最も大切なのは、パフォーマンススコアを最初の結論にしないことです。モバイル・パソコン別にフィールドデータを確認し、LCP・INP・CLSで、利用者がどの体験に困っている可能性があるかを把握します。
改善は不良なCore Web Vitalsから始めます。LCPならメインコンテンツの表示、INPなら操作を妨げるJavaScript、CLSならレイアウトずれを優先します。その後、全ページに影響するテーマ・タグ・画像運用・キャッシュを見直し、軽微な診断項目は効果と副作用を比較して対応しましょう。
改善後はラボデータで技術的な変化を確認し、時間をかけてフィールドデータの傾向を追います。点数を競うのではなく、訪問者が速く見られ、迷わず操作できる状態を目指すことが、PageSpeed Insightsを活用する目的です。
