PageSpeed Insightsは、上部の実際の利用データで問題を確かめ、下部のLighthouseの試験結果で原因を探す順番で読みます。丸い点数だけを保存しても、何を直すかは決まりません。
主力製品と技術記事のURLを用意し、PageSpeed Insightsでモバイルから調べてください。結果では、測ったURL、端末、実測の対象範囲、指摘されたファイルを残します。
LCP・INP・CLSの意味と基準値はCore Web Vitalsの説明で扱っています。このページでは、その指標が画面のどこから来たかと、診断を修正依頼へ変える方法に絞ります。
上部と下部は、何を別々に測っている？
GoogleのPSI仕様は、実際の利用データと、管理された環境で測る試験データを分けています。画面の二つの評価を、同じテストの重複表示として読まないでください。
| 画面の領域 |
データの出どころ |
確かめること |
| 実際のユーザーの環境で評価する |
CrUX |
過去の利用体験に問題があるか |
| パフォーマンスの問題を診断する |
Lighthouse |
試験で何が表示や処理を遅らせたか |
CrUXは、Chromeの実際の利用体験を集計したデータです。画面では過去28日間を扱います。Lighthouseは、その測定時の条件でページを読み込み、原因を調べます。スマホで一度測る試験が、過去の全訪問を再現するわけではありません。
同じページでも、実測は良好なのに試験の点数が低いことがあります。反対の組み合わせもあります。片方が間違いと決めず、期間、端末、対象範囲と、下部に表示される試験条件を照合します。
このURLとオリジンは、どう見分ける？
実測欄の対象が、入力した一つのページなのか、配信元全体なのかを確認します。オリジンはプロトコル、ドメイン、ポートの組です。製品詳細を入れても、データ不足で同じ配信元全体の値に切り替わることがあります。
GoogleのPSI仕様には、次の説明があります。
PSI will fall back to origin-level granularity
ページ単位のサンプルが足りないと、オリジン単位の値を使うという説明です。オリジンにも十分なデータがなければ、実測は表示されません。
製品ページの改修を報告するなら、「対象URLの実測」か「オリジンの実測」かを必ず添えます。オリジン全体が良好でも、その製品ページだけの良好を確認したことにはなりません。
実測が無いページも、操作して確認する
データ不足を、遅くない証拠には使えません。診断結果を読み、スマホでメニュー、資料へのリンク、問い合わせまで試します。訪問数が増えるまで不具合を放置する必要はありません。
Lighthouseの点数は、順位を示す？
パフォーマンススコアは、複数の測定指標から作る試験の点数です。スコアの公式説明では、指摘の件数を減点方式で数えるのではなく、指標のスコアを重み付けして計算するとしています。
そのため、指摘を一件消すと何点上がる、とは決まりません。サーバー応答や配信内容などが変われば、未修正でも点数が揺れることがあります。一度だけ高かった結果を、改修の成果として選んで報告しないようにします。
Googleのページ体験と検索の説明は、Core Web Vitalsを順位づけに使うとしています。同時に、ツールで良い結果を得ても上位表示は保証されず、SEOだけのために満点を追うことへ注意を促しています。
ここから、Lighthouseの点数そのものをGoogleの順位要因や合格点として扱うことはできません。速度の改善と、どの検索語で表示されたかの評価は分けます。検索側の変化はSearch Consoleの実績の読み方で確かめてください。
Lighthouse単体は、いつ使う？
Chromeの公式ガイドでは、開発者ツールやコマンドから実行できます。PageSpeed Insightsで公開URLを調べた後、制作担当が修正前後のページを試験するときに使えます。
Chromeの開発者ツールでLighthouseを開き、対象の端末や検査するカテゴリを指定して実行します。公開前のページを試すなら、社内の許可された環境で確認してください。試験のために、非公開の図面や顧客情報を外部へ公開する必要はありません。
PSIと手元のChromeで点数が違うときは、環境を見ます。実行端末、回線の制限、拡張機能、Lighthouseの版が一致するとは限りません。毎月の比較には、どの道具で、どの条件で測ったかも残します。
パフォーマンス以外のSEOやアクセシビリティの点数も、担当を決めるために読みます。SEOが高得点でも、製品の対応材質が本文に足りているか、営業へ必要な相談が届くかまで採点した数字ではありません。
指摘された項目から、何を制作担当へ渡す？
診断を開き、該当するファイルや要素を確認します。項目名だけで一括修正を依頼せず、その部品がページで何を担うかを調べてください。以下は、診断に出たときの読み方です。出現頻度を調査したランキングではありません。
画像の転送量や表示開始を指摘されたとき
最初に見える製品写真なのか、下部の設備写真なのかを確認します。LCP改善の公式手順は、画像の容量だけでなく、取得開始までの待ち時間も分けて調べています。
大きな写真なら表示寸法に合う画像を用意します。最初に必要な画像の読み込みが遅れているなら、全画像を一括で遅延読み込みする修正にはしません。製品の加工面を判別できるかも、圧縮後の画面で確認します。
JavaScriptの処理を指摘されたとき
チャット、計測タグ、製品の絞り込みなど、該当ファイルの役割を確認します。使っていない部品なら削除を、必要な機能なら処理の分割や実行時期の変更を制作担当と検討します。
INP改善の公式手順は、操作への反応を処理段階ごとに調べます。通常の読み込み試験で出るTBTは、訪問中の操作を測るINPそのものではありません。絞り込み後に画面が固まるなら、その操作も別に再現します。
表示のずれを指摘されたとき
CLS改善の公式手順を使い、寸法のない画像、埋め込み、後から入る内容を調べます。指摘された要素が動いた原因は、直前へ挿入された別の部品かもしれません。
問い合わせボタンが下へ押し出されるなら、動いたボタンだけを固定して済ませず、何の表示が場所を変えたかを確認します。枠の寸法を先に確保できるか、不要な挿入自体を止められるかを判断します。
直す順番は、どこで決める？
私たちは、操作を妨げている不具合、主要ページに共通する原因、そのページだけの負担の順で作業範囲を決めます。Googleが全サイト共通に指定した順番ではありません。
製造業なら、技術記事から製品詳細へ進み、図面相談を送る流れを試します。全ページに不要な動画が読み込まれるなら共通部品を見直します。製品詳細だけで巨大な写真を配信しているなら、その画像を直します。
点数を上げるために問い合わせ機能を外してしまっては、目的を失います。問い合わせ導線の点検と合わせて、必要な機能を残しながら負担を減らしてください。
修正後の報告には、何を残す？
対象URL、端末、測定日時、実測の対象範囲、試験条件、直したファイルを記録します。修正前後は同じ条件で測り直し、結果が揺れるなら複数回の結果も残します。
公開直後には下部の試験と実機操作で確認します。上部には修正前の利用体験も残るため、修正日と分けて推移を追います。レポートの色が変わるまでを、即日の納品条件として約束しないでください。
制作担当へは、点数だけでなく、問題の画面と操作も渡します。計測と改善で使う報告は、「何点上がったか」に加えて、「製品を選び、相談へ進む操作のどこが直ったか」を確認できる形にします。
仕様・出典の確認日：2026年10月22日。