PageSpeed Insightsスコアの見方 点数より改善の順番を決める

PageSpeed Insightsを見るたびに、現場では同じ誤解が起きがちです。90点を超えたから安心、60点台だから危険と、点数だけで判断してしまうこと。実務では危うい見方です。検索流入が落ちる原因は、点数そのものではありません。実ユーザーが読む途中で待たされること、押したのに反応しないこと、本文やボタンがずれることにあります。

結論から言えば、PageSpeed Insightsは総合点を読む道具ではなく、改善の順番を決める道具として使うべきです。検索流入の入口ページや成果に近いページほど、この読み方の差が結果の差になります。高得点を目標に置くのではなく、LCP・INP・CLSのどれが事業に近い損失を生んでいるのかを切り分けること。そこが正しい出発点です。

最初に見るのは総合点ではなく実ユーザー情報

最初に確認すべきなのは、PageSpeed Insights の上部に出る実ユーザー情報です。ここで良好判定かどうかを見ずに、下部のLighthouseスコアだけで改修に入る運用は避けてください。Googleのページ エクスペリエンスでも、検索順位は単一の指標で決まるものではなく、Core Web Vitalsだけで上位表示が保証されるわけでもないと明記されています。逆に言えば、総合点100だけを追っても、成果に近い問題を取り逃がすことがあります。

特に月間PVが10万未満のサイトでは、点数の上下に運用が引っ張られやすい傾向があります。限られた開発時間を使うなら、総合点の見栄えより、自然検索の入口ページで実害が出ている指標に絞るべきです。記事一覧もLPも同じ基準で眺めるのではなく、実ユーザー情報で落ちている指標を一つ特定してから診断項目を読む。この順番なら、工数は散りません。

現場で最初に固定したい四段階の読み順序

1. 実ユーザー情報で Core Web Vitals が通っているかを確認する
2. 落ちている指標が LCP・INP・CLS のどれかを一つに絞る
3. その指標に対応する診断項目だけを下にたどる
4. 最後に総合点を見て、未着手の論点が残っていないかを確かめる

この順序を会議や定例で固定してください。改善会議の冒頭で総合点を映す運用は、今日からやめるべきです。実ユーザー情報が良好なのに総合点だけ低いページは、原則として大規模改修の対象から外すのが妥当です。例外は二つあります。ひとつは広告出稿やメール配信で短期に大量流入を受けるLP。もうひとつは公開前で実ユーザー情報がまだ蓄積されていない新規ページです。この二つだけはラボデータを重く見ても構いません。

Core Web Vitalsの全体像から整理したい場合は、Core Web Vitals改善の進め方 最新評価軸に合わせて表示速度と操作体験を立て直す を先に読むと、LCP・INP・CLSの役割の違いをつかみやすくなります。

フィールドデータとラボデータの役割を分ける

PageSpeed Insightsで迷う最大の原因は、フィールドデータとラボデータを同じ意味で扱ってしまうことです。web.devのWeb Vitals解説では、Core Web Vitalsは実環境での体験を見る指標として整理されています。重要なのは、平均値ではなく、一定期間に蓄積された実測の中で悪い側も含めて評価される点です。開発端末で3回続けて速かった結果より、実ユーザーの体験のほうが重い。ここは運用ルールとして明確にしておく必要があります。

公開後の改善判断では、URL単位のフィールドデータがあるならそれを最優先にしてください。URLデータがない場合はオリジン全体の傾向を見ます。ただし、オリジンデータは「このページが遅い」という裏付けにはなりません。別テンプレートの問題が混ざるためです。そのため、オリジンデータしかない状態でページごとの細かい改修に入るのは非効率です。テンプレート単位で直したほうが成果につながります。

三種類のデータをどう使い分けるべきか

月間5,000セッション未満のサイトで、URLごとの差を細かく追い続ける運用はおすすめできません。検証が遅く、改善の因果関係を読み取りにくいからです。その規模なら、記事詳細、記事一覧、サービスLP、問い合わせ完了前のフォームなど、入口や成果に近いテンプレートを4〜6種類に分けて管理するほうが確実です。

一方で、月間100万PVを超えるサイトでは事情が変わります。URL単位の実測が十分に集まりやすいため、自然検索流入上位20URLと、成果につながる上位3〜5URLは個別に責任を持つべきです。大規模サイトで「全部テンプレートの問題」とまとめてしまうと、重要ページの改善が遅れます。

LCPとINPとCLSで改善の順番を変える

Core Web Vitalsの現行指標はLCP、INP、CLSの三つです。web.devのWeb Vitalsと、それぞれの解説で示されている良好の目安は、LCPが2.5秒以下、INPが200ミリ秒以下、CLSが0.1以下です。逆に、LCPが4.0秒超、INPが500ミリ秒超、CLSが0.25超なら、優先度はかなり高いと見てください。ここで大切なのは、三つを同時に追わないことです。最初の一か月は、ページ群ごとに事業損失の大きい指標から着手するべきです。

いまの現場で特に見落とされやすいのがINPです。昔の手順書に引っ張られて、初回表示だけを改善対象にしてしまうケースがまだ残っています。しかし、INPの解説が示す通り、INPは操作に対する反応そのものを見る指標です。問い合わせ、資料請求、絞り込み検索、比較表の開閉が多いページでは、LCPより先にINPを見たほうが成果に近い。押してから300ミリ秒以上反応しない操作が続くなら、ユーザーはページを「遅い」と判断します。

ページの役割ごとに優先指標を明確に決める

シナリオ別に言い切るなら、次の判断を推奨します。

• 記事中心のメディアなら、まずLCPを2.5秒以内、CLSを0.1以下に戻すべきです。初見の読みやすさを損ねるページは、自然検索流入の受け皿として弱いからです。
• 問い合わせや資料請求が主目的のLPなら、INPを最優先で見てください。LCPが2秒台でも、ボタン反応が重ければ成果は伸びません。
• 検索や絞り込みが多いページでは、LCPより先にINPを200ミリ秒台前半へ戻す判断が妥当です。操作の遅さは回遊にも売上にも直接響きます。
• 広告差し込みや外部埋め込みが多いページでは、CLSが0.1を超えた時点で放置すべきではありません。0.15前後でも読書体験は十分に悪化します。

例外もあります。記事ページでも、サーバー応答が遅くLCPが4秒台に張り付いているなら、INPやCLSより先にLCPへ集中するべきです。逆にLPでも、レイアウトが大きくずれて送信ボタンの位置が動くなら、CLSを先に止めるほうが安全です。

LCP悪化時は画像より先に到達経路を見る

LCPが悪いと聞くと、真っ先に画像圧縮へ向かう現場は少なくありません。しかし、それでは半分しか当たりません。LCPの解説とLCPの最適化では、LCPは単に画像が重いかどうかではなく、サーバー応答、リソースの発見の遅れ、読み込み時間、描画の遅れに分けて考えるべきだと整理されています。LCPが4.0秒を超え、同時にTTFBが0.8秒を超えているなら、最初に疑うべきはサーバー応答とキャッシュ設計です。ここで画像だけ軽くしても、改善幅は限られます。

TTFBの解説とクリティカル レンダリング パスを読むと、HTMLが届くまでの遅さと、届いてから描画が始まるまでの詰まりは別の問題だと分かります。LCP改善で成果が出る順番は、多くのサイトで共通しています。まずTTFBを削る。次にLCP要素を早く見つけさせる。最後に画像やCSSの調整へ入る。この順序を外すと、改善したつもりでも体感差が出にくいまま終わります。

LCPが遅いときに先に切るべき三つの論点

1. TTFBが0.8秒を超えていないか

1秒前後まで悪化しているなら、アプリケーション応答、キャッシュ、不要なリダイレクト、データ取得の順番を先に見直すべきです。

1. LCP要素がすぐ見つかる構造か

ファーストビュー画像を遅延読み込みにしている、CSSやJavaScriptの後ろで初めて読み込まれる、表示直前まで非表示にしている。こうした実装は避けるべきです。

1. 描画を止める資産が先頭に並んでいないか

大きなCSS、使っていないJavaScript、外部タグの読み込み順が前に寄り過ぎていると、LCP要素の表示が後ろへずれます。

具体的には、LCPが3.5秒超かつTTFBが1秒超なら、最初の一週間は画像編集よりキャッシュと配信経路の確認に使うべきです。逆にTTFBが0.4秒前後で安定しているのにLCPだけが悪いなら、ファーストビュー画像の取得順、圧縮、表示サイズ、CSSの読み込み順を見たほうが早い。ここで初めて画像最適化が効いてきます。

例外は、商品画像や施工事例画像がページの主役で、かつその画像がLCP要素だと分かっているケースです。この場合は、配信経路に問題がなくても画像形式やサイズの見直しが先に効くことがあります。ただし、それでもLCP要素の発見が遅い設計なら伸びません。画像改善だけで終わらせない姿勢が必要です。

INPとCLSは操作中の詰まりから洗い出す

INPとCLSは、読み込み直後だけ見ても原因を取り切れません。PageSpeed Insightsでフィールドデータが悪いのに、Lighthouseでは再現しない。そういうときほど、読み込み後のずれや操作中の詰まりを疑うべきです。INPの最適化では、イベント後に長い処理が続くと入力反応が悪化すると説明されています。CLSの解説とCLSの最適化でも、読み込み後に差し込まれる広告、埋め込み、同意バナー、エラーメッセージがずれの典型原因として挙げられています。

つまり、INPが悪いときはJavaScriptの量そのものより、クリック後に何が走るかを確認するべきです。絞り込み条件の再計算、外部タグの発火、モーダル表示時の重い初期化、API待ちに伴う描画更新。このあたりが詰まると、ユーザーは「押したのに動かない」と感じます。成果ページでINPが200ミリ秒を超えているなら、A/Bテストやヒートマップの追加より先に、その操作のイベント処理を軽くするほうが優先です。

CLSも同じです。本文やボタンが動いて見えても、原因はその下ではなく、上流にあることが多いものです。画像サイズの未指定、広告領域の未確保、遅れて出るフォームエラー、同意バナーの割り込み。この四つは先に潰すべき論点です。特にLPでは、送信ボタンの位置が動くだけで機会損失が起きます。CLSが0.1を超えているなら、軽微だと片付けないほうが安全です。

DevToolsで最初に見るべき記録条件を絞る

Chrome DevToolsのPerformance機能は、PageSpeed Insightsで見えた異常の原因を探すときに向いています。条件は増やし過ぎないほうがよいでしょう。最初は次の三つで十分です。

• モバイル実機、もしくはそれに近い画面幅
• 通信制限ありの初回訪問
• 読み込み後に実際の操作を一つ実行すること

この条件で記録すると、LCPだけでなく、スクロール時のずれ、開閉操作後の詰まり、ボタン押下後の長い処理が見えてきます。再現しないから後回しではなく、再現しにくい問題ほどフィールドで起きている可能性が高いと考えてください。

例外として、管理画面や会員専用画面のように実機検証が難しい領域もあります。その場合でも、操作後に高さが変わる要素、遅れて追加される部品、外部タグの依存関係は洗い出せます。INPとCLSは、公開側だけの問題ではありません。

サイト規模とページ種別で優先順位を決める

速度改善は、技術だけで優先順位を決めると外しやすい領域です。大切なのは、どのページ群が自然検索流入を受け、どの操作が成果に近いかという視点。月間PV、流入構造、成果地点の位置によって、最初に触るべきページは変わります。全部を一律に直そうとすると、たいてい失敗します。

月間規模別に最初の担当範囲を決める

ここで明確におすすめしたいのは、検索流入の60〜70%を占めるページ群から着手することです。月間30万PVのサイトで2,000URLを順番に見ても、改善は遅いままです。入口ページ群と成果ページ群に分け、先に影響の大きい群だけを直してください。記事群はLCPとCLS、LP群はINPとCLS、会員機能や検索機能はINP。この分け方が最もぶれにくい進め方です。

また、速度改善を事業判断につなげるなら、GA4側の設計を曖昧にしたまま進めるべきではありません。どのページが商談や問い合わせに近いのかが見えていないと、改善優先度を誤ります。計測の整理が必要なら、GA4の使い方を初心者向けに整理 SEO実装で迷わない計測設計と活用の基本 を先に読み、CV定義が揺れているなら GA4のコンバージョン設定で迷わない 事業判断に効く設計とベストプラクティス もあわせて確認してください。

JPSM SEO 編集事業部への相談でも、PageSpeed Insightsの数字そのものより、「どのページを先に直すか」が曖昧な状態で手が止まっているケースが目立ちます。改善の正しさは、技術の細かさより、優先順位の切り方で決まる場面が多いものです。

よくある誤読を先に潰して改善工数を守る

速度改善の現場で工数を浪費する誤読は、ある程度共通しています。ここを先に潰しておくと、無駄な議論は大きく減ります。

改善前に先に捨てるべき五つの思い込み

• 「90点を超えたから終わり」

終わりではありません。実ユーザー情報でLCP・INP・CLSが通っているかを見るべきです。総合点は合否判定ではなく、診断の補助です。

• 「LCPが悪いなら画像だけ軽くすればいい」

これは危険です。TTFBや読み込み順が詰まっていれば、画像圧縮だけでは伸びません。まず到達経路を見てください。

• 「フィールドデータがないなら問題もない」

早計です。新規ページや流入の少ないページではデータが不足します。その場合はオリジン傾向とテンプレート構造で判断する必要があります。

• 「モバイルだけ悪くてもPCが速いから問題ない」

自然検索流入の多くがモバイルなら、この判断は通用しません。モバイル実測が悪いページは後から確実に効いてきます。

• 「全部まとめて直したほうが早い」

たいてい逆です。LCP、INP、CLSを同時に大改修すると検証がぼやけます。1指標、1原因、1テンプレートで進めたほうが成果判定までぶれません。

あわせて、Web Vitalsの最適化も見ておくと、指標ごとに改善対象を切り分ける考え方を整理しやすくなります。特に担当者が複数いる組織では、「この施策は何の指標を何秒、何ミリ秒、いくつ改善するのか」を最初に明文化しておくべきです。

最初の30日で実行する改善手順を固定する

最後は、行動を固定します。PageSpeed Insightsの見方で迷わないようにするには、点数を見る習慣を変えるだけでは足りません。改善の手順そのものを固定する必要があります。最初の30日は、広く触る時期ではなく、入口ページ群と成果ページ群で、優先度の高い1指標だけを確実に下げる時期だと考えてください。

一か月で終えるべき実務チェック項目

1. 自然検索流入上位10URLと、CVに最も近い3URLを選ぶ
2. 各URLで、実ユーザー情報がURL単位かオリジン単位かを確認する
3. LCP・INP・CLSのうち、今回の主対象を一つだけ決める
4. その指標の悪化要因をPageSpeed Insightsの診断項目で仮説化する
5. DevToolsでモバイル相当、初回訪問、操作ありの条件で再現を試す
6. テンプレート単位で共通原因がないかを確認する
7. 修正後は同じURL、同じ条件で再計測し、改善前後を記録する
8. GA4と検索流入データを照合し、成果に近いページ群の次順位を決める

進め方の目安も置いておきます。 1週目は対象URLの選定と指標の切り分け。 2週目はDevToolsで原因特定。 3週目はテンプレート改修。 4週目は再計測と次の対象群の選定。

この一か月で目指す数字は、欲張らないほうがよいでしょう。たとえば、記事詳細テンプレートのLCPを3.8秒から2.5秒台へ、問い合わせLPのINPを320ミリ秒から200ミリ秒台前半へ、広告入り記事のCLSを0.18から0.1未満へ戻す。このくらい具体的に切ると、改善の成否がぶれません。

PageSpeed Insightsは、点数を眺めるだけでは役に立ちません。実ユーザー情報を起点に、指標を一つに絞り、テンプレート単位で直す。この使い方に変えた瞬間から、改善の精度は上がります。今日やるべきことは一つです。まず PageSpeed Insights で自然検索流入上位10URLを開き、総合点ではなく実ユーザー情報だけを見て、LCP・INP・CLSのどれを今月の対象にするか決めてください。