PageSpeed Insightsを開くと、最初に点数が目に入ります。赤や黄色の表示を見ると、すぐに満点へ近づけたくなります。表示速度の改善で先に見るのは、点数よりも実際の訪問者がどの場面で待たされているかです。

速度改善は、訪問者が内容を読み、比較し、問い合わせへ進みやすくするための改善です。Google検索セントラルも、ページエクスペリエンスは検索結果に関わる要素の一つだと説明しつつ、良いツール結果だけで上位表示が保証されるとはしていません。だから、点数の上下より先に、読者の判断がどこで止まるかを見ます。

PageSpeed Insightsは点数よりユーザーの待ち時間を見る

PageSpeed Insightsの点数は、状態をつかむ入口として便利です。ただし、点数だけを追うと、読者が困っている場所とは違う修正に時間を使うことがあります。

たとえば、広告のランディングページで最初の見出しとフォームが遅れて表示されるなら、問い合わせ機会に直接影響します。サービスページでメインビジュアルが重く、本文へ進む前に待たされるなら、比較検討の途中で離脱されるかもしれません。検索流入の多い記事で読み込み中にレイアウトがずれると、本文を読み始めた読者の集中が切れます。

見るべきなのは、ページの役割と遅さの症状です。点数はその症状を探すための目印にします。

フィールドデータとラボデータは測っているものが違う

PageSpeed Insightsには、実際のユーザー環境に基づくフィールドデータと、Lighthouseが一定条件で測るラボデータがあります。両方の数値が違って見えることは珍しくありません。

フィールドデータは、Chromeユーザー体験レポートに基づく実ユーザーのデータです。過去の訪問者がどのような環境でページを体験したかを見る入口になります。事業上の影響を考えるときは、こちらが参考になります。ただし、十分なアクセスがないURLではデータが表示されないことがあります。

ラボデータは、今そのURLを診断して原因を探すために使います。画像が重い、JavaScriptの処理が長い、フォントや第三者タグの読み込みが遅いなど、修正候補を見つけるときに役立ちます。実ユーザーの平均ではなく、制御された条件での診断だと理解して読む必要があります。

LCP、INP、CLSで何が壊れているかを分ける

Core Web Vitalsは、ページ体験を大きく三つの症状で見ます。主要な内容が見えるまでの遅さ、操作への反応の遅さ、読み込み中のレイアウトのずれです。指標名を覚えることより、その遅さが読者の行動をどう邪魔しているかを見るほうが重要です。

LCPが悪いときは、ページの主要な内容が見えるまで時間がかかっています。最初に表示される大きな画像、メインビジュアル、サーバー応答、CSSやフォントの読み込みが原因になりやすいです。

INPが悪いときは、ユーザーが操作したあとの反応が遅くなっています。メニューを開く、ボタンを押す、フォームに入力するなどの直後に、重いJavaScriptが動いていないかを見ます。

CLSが悪いときは、読み込み中に表示位置がずれています。画像や埋め込みの高さが確保されていない場合、後から広告やフォームが挿入される場合、フォント読み込みで文字の幅が変わる場合に起きやすいです。

この三つを分けて見ると、PageSpeed Insightsの提案をそのまま上から処理するより、原因へ近づきやすくなります。LCPの問題なのに計測タグだけを削る、CLSの問題なのに画像圧縮だけを続ける、といった遠回りを避けられます。

速度改善の優先順位はページの事業役割で決める

すべてのページで満点を目指す必要はありません。改善の順番は、スコアの赤い項目の数ではなく、そのページが事業上どれだけ重要かで決めます。

優先度が高いのは、広告のランディングページ、問い合わせ前に読まれるサービスページ、検索流入が多い記事、スマートフォンで読まれる比率が高いページです。これらのページで読み込みが遅いと、集客や相談判断に影響しやすくなります。

逆に、アクセスが少なく、問い合わせ判断にもあまり関わらないページで細かな点数改善を続けても、事業上の効果は限られます。主要ページでは、画像、第三者タグ、フォーム、ファーストビューを見直すほうが実務上の意味は大きくなります。

画像、JavaScript、レイアウトずれは壊れる場所が違う

原因を探すときは、「重いものを全部削る」と考えないほうがよいです。ページの役割を壊さず、症状に合う場所から見ます。

LCPの改善では、最初に表示される大きな画像を確認します。必要以上に大きい画像を配信していないか、表示サイズに合った画像になっているか、重要な画像の読み込みが後回しになっていないかを見ます。サーバー応答やCSSの読み込みが遅い場合は、画像だけでは解決しません。

INPの改善では、操作の直後に何が動いているかを見ます。タグ、解析ツール、チャット、外部フォームなどの第三者スクリプトが増えると、操作への反応が重くなることがあります。必要な計測まで消すのではなく、読み込み順や設置範囲を見直します。

CLSの改善では、後から高さが変わる要素を探します。画像、動画、埋め込み、フォーム、バナーには、表示前から必要な領域を確保します。見た目のずれは小さく見えても、読者が本文を読み始めたあとに起きると体験を損ねます。

満点よりも公開後に悪化を見つける運用へ組み込む

PageSpeed Insightsの提案は便利ですが、すべてを同じ重さで扱う必要はありません。問い合わせ導線を壊す圧縮や、ブランド上必要な画像を雑に削る改善は避けます。点数を上げた結果、フォームが使いにくくなるなら、速度改善としては失敗です。

表示速度は、新しい画像、計測タグ、埋め込みフォーム、外部スクリプトを足すたびに変わります。だからこそ、公開前の確認と公開後の監視に組み込むことが大切です。

公開前には、主要ページのファーストビュー、フォーム、メニュー操作、スマートフォン表示を確認します。公開後には、検索流入や広告流入のページで悪化が起きていないかを見ます。PageSpeed Insightsは、その変化に気づくための診断道具です。点数を目的にせず、読者が必要な情報へ早く到達できるかを基準に改善します。