PageSpeed Insightsの点数が低いとき、何から直す？中小企業の改善優先順位

PageSpeed Insights（以下、PSI）のモバイル点数が低いと、画像を圧縮する、キャッシュ系プラグインを追加する、といった作業から始めたくなります。しかし、点数だけでは「実際の利用者が困っているか」「どのページが事業上の問題になっているか」「何を直せば改善するか」までは決まりません。

先に決めるべきなのは、問い合わせや資料請求などの完了行動に関わる重要ページです。そのうえで、過去28日間の実ユーザーデータを確認し、LCP（主な内容の表示）・INP（操作への反応）・CLS（レイアウトの安定性）のどれが利用者に影響しているかを読み、ラボデータで原因候補を絞ります。改修後の検収条件まで揃えてから発注範囲を決めると、点数だけを追う改修を避けられます。

Googleは、Core Web Vitalsをランキングシステムで利用すると説明しています。一方、Search Consoleなどで良好な結果を得ても上位表示は保証されず、SEOだけを理由に完璧な点数を目指すことが最善とは限りません。点数100は目的ではなく、利用者が重要な操作を完了しやすい状態を作るための診断材料です。Google for Developers +1

PageSpeed Insightsの点数だけで改修を決めない

PSIのパフォーマンス点数は、Lighthouse（一定条件でページを診断するツール）がシミュレーション環境で取得した複数の指標をまとめたラボスコアです。90以上は「良好」と分類されますが、測定時のネットワークや実行環境などで結果は変動します。実ユーザーがさまざまな端末・回線で体験した速度を、その場の点数がそのまま表しているわけではありません。Google for Developers

そのため、改修対象を選ぶときは「最も点数が低いURL」ではなく、ページの役割から考えます。たとえば、サービス内容を理解するページ、問い合わせフォームへ進むページ、フォームを送信するページでは、利用者が完了したい行動が異なります。表示の遅さが同じでも、完了行動を止める度合いは同じではありません。

判断の起点は、次の二つです。

守るべき重要ページを決める：トップページ、主力サービスページ、問い合わせフォームなど、事業上の完了行動に近いURLを選びます。
ページごとの完了行動を言葉にする：「内容を読める」「料金や条件を確認できる」「ボタンを押せる」「送信を完了できる」など、利用者が終えたい行動を定義します。

点数が低くても主要な内容と操作に支障がないページと、点数は比較的高くても送信ボタンが反応しにくいページでは、後者を先に調べるべきです。点数は候補の抽出に使い、改修順は利用者への影響とページの役割で決めます。

フィールドデータとラボデータを分けて読む

実ユーザーデータ、ラボ診断、重要ページ、改善候補、検収という流れを示す文字なし判断フローを整理した図 — PageSpeed Insightsの結果から改修判断へ進む順序を理解しやすくするために、実ユーザーデータ、ラボ診断、重要ページ、改善候補、検収という流れを示す文字なし判断フローを整理しています。

PSIには、実際の利用状況を集計したフィールドデータと、Lighthouseによるラボデータが並びます。フィールドデータはChrome User Experience Report（CrUX）に基づき、過去28日間の実ユーザー体験を75パーセンタイル、つまり閲覧の4回に3回がその値以下に収まる境界で示します。対象URLのデータが足りない場合は、サイト単位に近いオリジン全体の値へ切り替わり、オリジンにも十分なデータがなければ表示されません。Google for Developers

ラボデータは、一定の端末・ネットワーク条件を模した一回の再現テストです。現実の利用状況そのものではありませんが、読み込み過程や実装上の原因候補を調べるのに向いています。一方、Search ConsoleのCore Web Vitalsレポートは実ユーザーデータを、モバイル・パソコン別、問題指標別、類似するURLグループ別にまとめます。個別URLの精密診断ではなく、複数ページへ広がる問題の発見に使うレポートです。Google ヘルプ

PageSpeed InsightsとSearch Consoleの測定結果の読み分け
確認場所	データの性質	分かること	判断時の注意
PSI「実際のユーザーの環境で評価」	CrUXによる過去28日間のフィールドデータ	URLまたはオリジンで利用者が経験したLCP・INP・CLS	URL単体の値かオリジン全体の値かを確認する
PSI「パフォーマンスの問題を診断」	Lighthouseによるシミュレーション測定	その測定条件での点数、指標、改善候補	一回の点数を実ユーザー全体の結果として扱わない
Search Console「Core Web Vitals」	CrUXをURLグループと端末別に集計	問題の広がり、推移、代表URL	グループ値と個別URLのPSI結果が一致するとは限らない
「データがありません」	実ユーザーのサンプル不足など	良好・不良を判定できない状態	問題なしとは見なさず、ラボ測定と実画面確認を行う

重要URLのフィールドデータが不良で、利用不能や主要導線への影響が再現するなら緊急対応へ進みます。フィールドは良好でもラボで問題が再現する場合は原因調査、実ユーザーデータがない場合はラボと実画面を確認しながら経過観察とし、点数とURLグループの警告は同じ尺度で比べません。Google for Developers +1

LCP・INP・CLSは困り方が違う

主な内容の表示、操作への反応、レイアウトの安定という3領域を示す文字なし比較図を整理した図 — 三つの指標と利用者が感じる問題を対応付けるために、主な内容の表示、操作への反応、レイアウトの安定という3領域を示す文字なし比較図を整理しています。

Core Web Vitalsは、LCPが主な内容の表示、INPが操作への反応、CLSがレイアウトの安定性を測る指標です。良好の目安は、ページ閲覧の75パーセンタイルでLCPが2.5秒以下、INPが200ミリ秒以下、CLSが0.1以下です。三つを一括して「遅い」と捉えず、利用者がどこで困るかへ翻訳します。web.dev

LCPは「主な内容が見えるまで待たされる」問題

LCP（Largest Contentful Paint）は、表示領域内の最大画像や大きなテキストブロックなど、主要コンテンツが描画されるまでの時間です。ファーストビューの画像や見出しがなかなか現れず、利用者がページの内容を判断できない状態が典型です。

LCPが悪いからといって、原因が画像容量とは限りません。LCPは、最初のHTMLが届くまでの時間、LCP要素の読み込み開始までの遅れ、リソースの読み込み時間、読み込み後に画面へ描画されるまでの遅れに分けて調べられます。画像圧縮で短くなるのは主にリソースの読み込み部分であり、JavaScriptの処理待ちで表示が止まっていれば、画像だけを軽くしても全体のLCPが改善しない場合があります。web.dev +2 web.dev +2

INPは「押したのに反応しない」問題

INP（Interaction to Next Paint）は、クリック、タップ、キーボード操作に対するページ全体の応答性を表します。メニューを開く、フォームへ入力する、選択肢を切り替える、送信ボタンを押すといった場面で反応が遅いと、利用者は操作を受け付けたのか判断できません。

フィールドデータでINPに警告がある場合は、点数だけを見るのではなく、重要ページで主要操作を実際に再現します。反応が遅れる操作、発生しやすい端末、外部スクリプトやJavaScript処理が重なる条件を記録し、制作会社へ渡せる状態にします。Lighthouseのラボ欄にはフィールドのINPと同じ実利用履歴があるわけではないため、ラボ診断と操作再現を組み合わせて原因を探します。Google for Developers +1

CLSは「読んでいる途中で位置がずれる」問題

CLS（Cumulative Layout Shift）は、ページの表示中に起きる予期しないレイアウト移動を測ります。読もうとした文章が下へ動く、押そうとしたボタンの位置が変わる、フォームの入力欄がずれるといった不安定さです。速度が速く見えても、誤操作につながる移動があれば優先度は高くなります。

原因候補は、表示後に高さが確定する埋め込みや、後から挿入される部品などです。画像やフォーム部品を含め、どの要素がいつ動いたかを記録します。初期表示だけでなく、メニュー展開、入力エラー表示、同意欄の表示など、完了行動の途中まで確認します。web.dev +1

三指標のしきい値は調査の目安であり、事業上の合否を自動で決めるものではありません。数値が「良好」でもフォームが使えないなら修正対象です。反対に、軽微なラボ値の改善しか見込めず、利用者の行動に影響しない作業は後順位にできます。

改善対象は重要ページと共通部品から選ぶ

全ページを同じ深さで調べると、調査費用と確認作業が広がります。代表URLを選ぶときの判断軸は、完了行動への近さと、修正がほかのページへ及ぶ範囲です。

トップページ：主要サービスへの入口、ファーストビュー、共通ヘッダーやナビゲーションを確認する
主力サービスページ：サービス内容の理解、比較材料、問い合わせ導線まで読めるかを確認する
問い合わせフォーム：入力、エラー表示、確認、送信まで操作が止まらないかを確認する
記事テンプレート：同じレイアウトを使う記事群に、画像・広告・埋め込み・共通スクリプトの影響が広がっていないかを確認する

Search Consoleで同じ問題に複数URLがまとまっている場合、代表URLだけの固有問題ではなく、テンプレートや共通部品に原因がある可能性を調べます。反対に、PSIで一つのURLだけが外れ値なら、そのページ固有の画像、埋め込み、スクリプト、コンテンツ構成を切り分けます。Search ConsoleのURLグループは類似したユーザー体験を持つページをまとめるため、波及範囲を考える入口になります。Google ヘルプ

測定結果の読み分けとは別に、社内整理から制作会社へ相談する流れは、ホームページの表示が遅いと感じたときの相談手順も参照してください。相談前に、発生ページ、端末、操作、更新直後かどうかを揃えておくと、重要ページと共通部品のどちらから調べるかを話しやすくなります。

点数が低いときの改善優先順位

改修順は、点数の低い順でも、実装が簡単な順でもありません。利用者が行動を完了できるか、事業上重要な導線か、何ページへ影響するか、原因を再現できるかで並べます。

利用不能または誤操作につながる問題フォームを送信できない、ボタンが反応しない、表示移動で別の要素を押してしまう、主要コンテンツが表示されない、といった問題です。点数に関係なく、完了行動を止めるなら最優先で再現と修正を行います。
主要導線を待たせる問題主力サービスの内容が現れるまで長く待つ、問い合わせボタンの反応が遅い、フォーム操作の途中で固まるなど、重要ページのLCPやINPが該当します。フィールドデータで不良が確認できる場合は、実ユーザーへの影響が継続している根拠として扱います。
複数ページへ波及する問題共通ヘッダー、記事テンプレート、共通JavaScript、外部サービスの埋め込みなどが原因なら、一つの修正が多数のURLへ影響します。Search ConsoleのURLグループと代表URLを使い、共通原因とページ固有原因を分けます。
軽微な点数改善利用者の完了行動に支障がなく、フィールドデータにも大きな問題がなく、ラボ点数だけを少し上げる作業は後順位です。低リスクでほかの改修と同時に行えるなら候補になりますが、重要な不具合の調査を後回しにしてまで着手する理由にはなりません。

画像圧縮は、LCP要素が画像であり、読み込み時間が原因だと確認できたときに有効な施策です。プラグイン追加やキャッシュ設定も同様に、監査項目へ表示されたから採用するのではなく、対象URL、原因候補、既存機能への影響、戻し方を確認して実装します。LCPは読み込み全体の複数段階から成るため、単独の「速くする施策」を先に決めないほうが、手戻りを抑えられます。web.dev

制作会社へ渡す測定結果と条件

「モバイルが35点なので100点にしてください」という依頼では、対象ページ、原因調査の範囲、実装内容、検収方法が決まりません。制作会社へは、点数のスクリーンショットだけでなく、誰がどの条件で何を確認したかを渡します。

制作会社へ渡す表示速度改善の確認資料
資料	記録する内容	自社で確認すること	制作会社と決めること
重要URL一覧	URL、ページの役割、完了行動、優先度	問い合わせや閲覧で守るページか	調査対象と対象外
測定記録	端末区分、測定日時、結果画面、フィールド・ラボ区分	同じURLと条件を記録したか	再測定条件と比較方法
Search Console記録	問題指標、ステータス、URLグループ、代表URL	影響ページの広がり	共通部品と固有ページの調査範囲
再現メモ	LCP要素、遅れる操作、移動する要素、発生手順	実画面で再現できるか	原因調査と修正案の成果物
更新・運用条件	CMS、更新担当、公開手順、触れられない機能	日常更新を続けられるか	実装方法、停止時間、戻し方
検収条件	ラボ再測定、実画面確認、公開後監視の項目	合否を判断できる表現か	完了条件、確認担当、監視期間

この表で、自社が準備する事実、制作会社が調べる原因、実装担当、検収担当を分けられます。未確認の欄は推測で埋めず、「未確認」として調査範囲へ含めるのが、見積もりと成果物のずれを減らす方法です。

発注前には、次の項目が揃っているかを確認します。

□ 重要URLと、そのページで利用者に完了してほしい行動
□ モバイル・パソコンのどちらで問題を確認したか
□ 測定日時と、結果画面または共有できる記録
□ フィールドデータとラボデータのどちらを示しているか
□ LCPの対象になった画像・見出し・テキストなどの要素
□ 反応が遅いクリック・タップ・入力・送信操作
□ 位置が動いた画像・ボタン・入力欄と発生タイミング
□ CMS更新、プラグイン、外部タグ、公開時間などの更新制約

ここまで揃えば、「調査だけを依頼する」「原因が確定した範囲を実装する」「公開後の監視まで依頼する」を分けて選べます。原因調査を含む契約では、修正コードだけでなく、対象URL、原因候補、採用した対策、見送った対策、再測定条件を成果物として残す範囲も発注前の確認事項です。

改善後は一回の再測定で終わらせない

公開直後にPSIを一回実行し、点数が上がっただけで完了とすると、測定のばらつきや実画面の不具合を見落とします。ラボ測定は同じURL、端末区分、条件で複数回行い、改修前後の傾向とばらつきを比較します。PSIのラボ値はネットワークや実行環境などで変わるため、単発の最高点ではなく、再現する改善かを見ます。Google for Developers

検収は、次の四段階に分けます。

ラボ再測定：対象URLを同じ条件で測り、LCP要素、診断項目、点数の変化を記録する
実画面確認：スマートフォンを含む対象端末で、表示、メニュー、フォーム、送信、レイアウト移動を確認する
Search Consoleの推移確認：公開後にCore Web Vitalsレポートの対象グループを追い、必要に応じてトラッキングを開始する
更新後の再確認：画像差し替え、記事追加、プラグインや外部タグの更新後も、重要ページに再発がないか確認する

フィールドデータは過去28日間の実利用を集計するため、公開翌日にすべての評価が切り替わるものではありません。Search Consoleの修正検証も28日間のモニタリングで問題の再発を確認します。したがって、公開直後はラボと実画面で実装を検収し、その後は実ユーザーデータの推移で効果と再発を確認する、という二段階の完了条件が必要です。Google for Developers +1

保守・運用では、初回の改善値だけでなく、どの更新をきっかけに再測定するかを決めます。主力ページの大きな画像変更、フォーム機能の変更、共通テンプレートや外部スクリプトの更新は、同じ検収項目を再確認する契機です。継続監視の対象を重要ページに絞れば、毎回サイト全体を調べ直さずに変化を追えます。

まとめ

PageSpeed Insightsの点数が低いときは、100点へ近づける施策を先に選ぶのではなく、重要URLと完了行動を決め、フィールドデータの有無を確認し、LCP・INP・CLSを利用者の困り方へ置き換えます。その後、ラボ診断と実画面で原因候補を絞り、共通部品への波及、更新制約、検収条件まで含めて発注範囲を決めます。