PageSpeed Insightsの点数が低くても、すぐにサイト全体の画像を圧縮する必要はありません。対象URLと端末を固定し、実ユーザーの体験を示すフィールドデータと、再現用のラボデータを分けて読みます。そのうえでLCP・INP・CLSのうち弱い体験を特定し、同じ条件で変更前後を比べるのが確認の基本です。
この記事では、モバイルとデスクトップの点数差や二種類のデータに迷う経営者・広報・Web担当者へ、どのページの何を優先するか判断する順番を示します。
結論｜点数より先に対象URL・端末・データ種別を固定する
PageSpeed Insightsを開いたら、最初に確認するのは点数ではなく測定条件です。同じホームページでも、トップページと問い合わせページでは読み込む画像や機能が異なります。モバイルとデスクトップも別の条件なので、両者の点数をそのまま横に並べて優劣を決めることはできません。
担当者は、次の順番で画面を読みます。
測定したURLが、トップ・主要サービス・問い合わせのどれかを確認する
モバイルとデスクトップのどちらを見ているか固定する
フィールドデータが表示されているか、URL単位かサイト全体のデータかを確認する
LCP・INP・CLSのうち、評価が弱い指標を見つける
ラボデータと診断項目から、再現できる原因候補を絞る
事業上の優先度を決め、同じ条件で変更前後を比較する
PageSpeed Insightsは、モバイルとパソコンの両方について、フィールドデータとラボデータを提供します。ラボ側のパフォーマンススコアは複数の指標を基に計算され、測定時の状況によって変動します。そのため「90点未満だから失敗」「前回より3点下がったから改修が必要」と、単発の数字だけで判断するのは適切ではありません。出典 出典
Google for Developers +1
記録には「トップページ／モバイル／測定日時」のように条件を書きます。数値だけを共有すると、別URLや別端末の結果が混ざり、制作会社も調査範囲を定められません。
PageSpeed Insightsの二つのデータを分けて読む
二つのデータは、どちらか一方が正解という関係ではありません。フィールドデータは実際の利用状況、ラボデータは再現した問題の原因候補を見るために使います。
フィールドデータは実際の利用者に起きた結果を見る
フィールドデータは、Chromeユーザーエクスペリエンスレポート（CrUX）に基づく実ユーザーのデータです。過去28日間のLCP・INP・CLSなどが表示されるため、一度の試験結果ではなく、さまざまな利用環境で生じた体験の蓄積として読みます。出典
Google for Developers
ページ単位の表示には十分なサンプルが必要です。公開直後や閲覧数が少ないページではサイト全体を表すオリジン単位へ切り替わり、それでも不足するとフィールドデータは表示されません。 Google for Developers
したがって「データなし」は、表示速度が良いという意味でも悪いという意味でもありません。記録には、数値だけでなく「フィールドデータなし」「オリジン単位」といった表示範囲も残します。
ラボデータは再現用の条件で原因を探す
ラボデータは、Lighthouseが指定URLをシミュレーション環境で分析した結果です。変更前後の再検査や原因候補の確認に向く一方、実ユーザーの端末・回線・操作は一定ではないため、ラボの点数だけで実際の体験を断定できません。出典
Google for Developers
担当者の読み分けは明快です。「利用者にどの問題が起きているか」はフィールドデータで捉え、「どこを変更すると改善する可能性があるか」はラボデータと診断項目で探します。両者の数値が違っても、測っている期間と条件が違うため、直ちに矛盾とは限りません。 Google for Developers
LCP・INP・CLSを利用者の困りごとへ言い換える
Core Web Vitalsは、利用者の体験を「読み込み」「操作への反応」「表示の安定性」の三つの面から見る指標です。担当者は略称を覚えるだけでなく、自社サイトで起きる困りごとへ置き換えると、調査対象を選びやすくなります。
LCPは主な内容が見えるまでの待ち時間
LCP（Largest Contentful Paint）は、主要なコンテンツのうち大きな要素が描画されるまでを測ります。トップページのメイン画像や、サービスページ冒頭の画像・説明部分が対象になることがあります。
LCPが弱いと、利用者は「見たい内容がなかなか出ない」と感じます。良好の目安は2.5秒以内です。PageSpeed Insightsで対象要素を確かめ、データ量や読み込み方に見直す余地があるかを確認します。 web.dev
INPは押したあとの反応の遅さ
INP（Interaction to Next Paint）は、クリックやタップなどに対して次の画面表示が返るまでの反応性を見ます。メニューが開かない、フォーム操作後に表示が止まるといった体験に当たります。
良好の目安は200ミリ秒以下です。利用者の操作がないLighthouseではINPを直接測れないため、ラボではTotal Blocking Time（TBT）や診断項目を手掛かりにします。TBTはINPそのものではなく、反応を妨げる処理を探す代理指標です。出典
web.dev
CLSは表示途中に位置がずれる不安定さ
CLS（Cumulative Layout Shift）は、読み込み中に文章、画像、ボタンなどが予期せず動く度合いです。押そうとしたボタンが移動する、文章が下へずれるといった困りごとに当たります。
良好の目安は0.1以下です。LCP・INP・CLSは、モバイルとデスクトップに分けた75パーセンタイルで評価されます。これは、計測された体験の75%がその値以下に収まる位置です。三つの状態から、多くの利用者に安定した体験を提供できているかを読みます。出典
web.dev
弱い指標から原因候補を絞る
PageSpeed Insightsの診断項目を上からすべて直すのではなく、先に弱い指標を決めます。その指標が表す困りごとと、実際のページで見える症状を結び付けてから、原因候補を狭めます。
| 見る項目 | 利用者の困りごと | 確認する原因候補 | 残す記録 |
|---|---|---|---|
| LCP | 主な画像や説明が出るまで待たされる | LCP対象の主要画像、サーバー応答、表示を妨げる読み込み | 対象要素、画像URL・容量、表示時間、画面 |
| INP | メニューやボタンを押しても反応が遅い | 操作を止める長い処理、JavaScript、外部機能、ラボのTBT | 遅い操作、発生ページ、フィールドINP、TBT・診断項目 |
| CLS | 読み込み途中に文章やボタンが動く | 後から入る画像・埋め込み・表示要素、領域の確保方法 | 動いた要素、発生時点、変更前後の画面 |
この表は、制作会社に調査してほしいページ・症状・候補を決めるための整理材料です。原因を確定するものではないため、実装前に対象要素と影響範囲を確認します。
LCPが弱く、対象要素がページ冒頭の大きな画像だった場合は、画像容量、表示サイズ、形式、配信方法が調査候補になります。画像容量を見直す段階では、画像容量を小さくする具体的な方法 も確認できます。ただし、LCPはサーバー応答や表示を妨げるリソースにも影響されるため、画像圧縮だけで解決するという決めつけは避けてください。出典
web.dev
INPが弱い場合は、どの操作で待たされるかを再現します。メニュー、絞り込み、フォームなどを動かし、ラボのTBTやJavaScript関連の診断を手掛かりにしながら、フィールドデータと実操作の両方へ戻って判断します。
CLSでは「何が、いつ動いたか」を画面で確認します。画像や埋め込み、案内表示など、ずれが起きる条件を記録すると対象箇所を追いやすくなります。
すべてのページを同じ優先度で直さない
ホームページ全体を一度に測るのではなく、事業上の役割が異なる代表ページから始めます。最初の候補は、会社やサービスへの入口となるトップページ、売上や相談につながる主要サービスページ、行動の直前に使われる問い合わせページです。
優先順位は、点数が低い順だけでは決まりません。問い合わせページでボタンやフォームの反応が遅ければ、閲覧数がトップページより少なくても先に確認する判断があります。一方、古いお知らせ記事でわずかな表示ずれが出ていても、利用者への影響と事業上の役割が小さければ後へ回せます。
三つのページを並べると、ページ固有の問題か、サイト共通の問題かも見えやすくなります。たとえば複数ページで同じ操作の反応が遅い場合は、共通のメニューや外部機能などが調査候補になります。特定ページだけLCPが弱ければ、そのページの主要画像や構成が優先する確認対象です。
「サイト全体を高速化する」ではなく、「モバイルの問い合わせページで操作反応を確認する」のように、URL・端末・体験を一組にして改善対象を決めます。
制作会社へ渡す測定記録と変更条件
制作会社へ相談するときは、PageSpeed Insightsのスクリーンショットだけでなく、測定条件と利用者の症状を一緒に渡します。最低限、次の内容がそろっていると、調査の入口を共有できます。
対象URLと、そのページの役割
モバイルまたはデスクトップ
測定日時
フィールドデータの有無と、URL単位・オリジン単位の別
LCP・INP・CLSのうち弱い指標
ラボデータで表示された対象要素、TBT、診断項目
実際に感じる遅さやずれの操作手順
変更対象、影響しそうなページ、公開予定
作業前のバックアップ方法と、問題時の戻し方
依頼文は「モバイルを90点にしてください」ではなく、「問い合わせページのモバイルでINPが弱く、操作に遅れを感じる。二つのデータを分けて原因を調べ、バックアップと戻し方を確認して変更したい」とすると目的が伝わります。
画像、テーマ、プラグイン、外部タグの変更は、対象外のページへ影響する場合があります。共通部品かページ固有か、更新後にどのページを確認するかを整理し、表示崩れやフォーム動作も完了条件に含めます。
変更前後を同じ条件で比べる
ラボのパフォーマンススコアは、ページを変えていなくても測定時の状況によって動くことがあります。Lighthouseのスコアは複数指標の加重平均であり、診断項目そのものが直接点数になるわけではありません。単発の一回で成功・失敗を決めず、同じURL・端末・測定方法で複数回の傾向を見ます。出典
Chrome for Developers +1
変更前後の記録では、少なくともURL、端末、測定日時、公開した変更内容をそろえます。比較の途中で別の画像を追加したり、外部タグを増減したりすると、何が結果へ影響したか分からなくなります。可能な範囲で一度に変える対象を絞り、変更内容を残します。
公開直後は、ラボデータで対象要素と診断の変化を確認できます。一方、PageSpeed Insightsのフィールドデータは過去28日間の利用状況を反映するため、改修直後に全面的な変化が出るとは限りません。公開日を記録し、一定期間後に同じURLと端末へ戻ってLCP・INP・CLSを読み直します。出典
Google for Developers
総合点が上がっても問い合わせ操作が遅いままなら、目的は未達です。点数の変化が小さくても、主要内容の表示、ボタンの反応、表示のずれが改善していれば、利用者の体験に沿って評価できます。
まとめ｜代表3ページの記録から始める
PageSpeed Insightsで最初に行うのは、点数を上げる作業ではなく、比較できる記録を作ることです。トップ、主要サービス、問い合わせの三ページを選び、同じ形式で測定内容を残してください。
対象URLをトップ・主要サービス・問い合わせから選んだ
モバイルとデスクトップを分けて記録した
測定日時とフィールドデータの有無・表示範囲を残した
LCP・INP・CLSのうち弱い指標を特定した
利用者の症状とラボの対象要素・診断項目を結び付けた
変更対象、バックアップ、戻し方を決めた
同じURL・端末・方法で変更前後を比較した
この一枚があれば、優先するページと体験を社内で決め、制作会社へ調査条件を渡せます。フィールドデータで体験を確認し、ラボデータで原因候補を調べ、公開後に同じ条件へ戻る流れを保ちます。
「PageSpeed Insights について」Google for Developers（Google）、最終更新日：2025年7月25日。出典
Google for Developers
「Web Vitals」web.dev（Google、著者：Philip Walton）、公開日：2020年5月4日、最終更新日：2024年10月31日。出典
web.dev
「Lighthouse のパフォーマンス スコアリング」Chrome for Developers（Google）、最終更新日：2019年9月19日。出典
Chrome for Developers
