表示速度の改善手順｜Core Web Vitalsの原因と対策

PageSpeed Insightsで自社サイトを測ったら、モバイルのスコアが赤い数字だった。何が悪いのかは書いてあるようだが、結局どこから手を付ければいいのか分からない。中小企業のサイト運用では、よくある行き詰まり方です。

先に結論を書きます。スコアそのものを目標にしても改善は進みません。見るべきはLCP・INP・CLSという3つの指標で、この3つは悪化する原因がまったく違います。原因を特定しないまま施策を並べても、たいてい空振りします。

この記事では、ラボデータとフィールドデータの読み分け方、3指標それぞれの原因を分解する手順、実際に手を入れる対象（画像・Webフォント・JavaScript・広告タグ）、WordPressのような既存サイトで着手できる順番を、2026年9月時点の公式情報をもとに整理します。

スコアではなく、3つの指標のどれが悪いかを見る

PageSpeed Insightsが出す0〜100のスコアは複数の計測値を合成した要約値で、要約だけを見ていても何が起きているのかは分かりません。検索での評価に使われるのもスコアではなく、Core Web Vitalsと呼ばれる3つの指標のほうです。まずは3つが何を測るのかを押さえ、自社サイトのどれが基準を外れているかを確認します。指標の定義と閾値はGoogleが公開しているCore Web Vitalsの解説に一次情報があります。

指標	測っているもの	「良好」の目安
LCP	主要なコンテンツが表示されるまでの時間	2.5秒以下
INP	操作してから画面が反応するまでの時間	200ミリ秒以下
CLS	表示中に起きるレイアウトのズレの大きさ	0.1以下

この表で押さえておきたいのは、判定が「平均」ではなく訪問全体の75パーセンタイルで行われる点です。つまり、4人に3人が基準を満たしていれば良好、逆に言えば遅い環境の4分の1が足を引っ張ります。自分のPCで速く表示されるからといって合格にはなりません。なお、INPは2024年3月にFID（First Input Delay）に代わって正式な指標になったもので、古い解説記事はFIDのままのことがあります。上の目安は2026年9月時点の値です。変更され得るため、公式ページで現在の基準を確認してください。

ラボデータとフィールドデータを混同しない

改善が空回りする原因としてよく挙がるのが、この2種類のデータの取り違えです。PageSpeed Insightsの画面は上下で別のものを表示しています。上段の「実際のユーザーの環境で計測されたデータ」がフィールドデータ、下段のスコアと診断項目がラボデータで、測っている対象も用途も違います。どちらを見て判断しているのかを常に意識してください。

フィールドデータは、実際にそのページを訪れたChromeユーザーから集められた記録です。検索での評価に使われるのはこちらで、実環境の回線速度や端末性能が反映されています。ただし訪問数が少ないページはデータが集まらず「十分なデータがありません」と表示されます。

ラボデータは、Lighthouseがその場で一定の条件（低速回線・低性能端末の想定）を再現して測った結果です。同じ条件で何度でも測り直せるので、原因の切り分けと修正後の確認に向いています。一方で、実際のユーザーが体験している速度そのものではありません。

使い分けは単純です。「直すべきページを見つける」のはフィールドデータ、「原因を突き止めて直す」のはラボデータ、「直った証拠にする」のはまたフィールドデータです。

Search Consoleで直すべきページ群を絞る

サイト全体を1ページずつ測るのは現実的ではありません。Google Search ConsoleのCore Web Vitalsレポートは、フィールドデータをもとに似た構造のURLをグループにまとめ、「不良」「改善が必要」「良好」に分類してくれます。ここで不良と出たグループの代表URLをPageSpeed Insightsで詳しく測る、という流れなら無駄がありません。

このレポートは一定期間ぶんの実測データを集計しているため、修正しても数字が変わるまでには時間差があります。直した当日に動かなくても失敗ではありません。

なお、かつてSearch Consoleにあった「モバイルユーザビリティ」レポートは2023年12月に提供終了しています。この項目を前提にした手順を書いている解説記事は情報が古いので、その前提でチェックリストを組まないでください。スマートフォンでの見え方や操作性は、ホームページのスマホ対応の観点として実機で確認する必要があります。

LCPは4つの区間に分解すると原因が見える

LCPが遅いとき、「画像が重いのだろう」と決め打ちして圧縮しても直らないことがよくあります。LCPは「サーバーが応答するまで」「表示すべき要素の読み込みが始まるまで」「その要素を読み込み終わるまで」「読み込み終えてから実際に描くまで」という4つの区間の合計だからです。どの区間で時間を食っているかによって、打つ手が変わります。

最初に確認するのは、そのページのLCP要素が何かということです。PageSpeed Insightsの診断結果や、Chrome DevToolsのPerformanceパネルで、どの要素がLCPとして判定されたかを表示できます。ファーストビューの大きな画像が該当することもあれば、見出しテキストや背景画像がLCP要素になっている場合もあり、後者の対処は画像圧縮ではありません。

第1区間、サーバーの応答（TTFB）が遅い場合は、フロント側をいくらいじっても上限が変わりません。共有サーバーのプラン、PHPのバージョン、データベースの重いクエリ、キャッシュの有無が原因になります。ここに時間がかかっているなら、レンタルサーバーの見直しやページキャッシュの導入が先です。

第2区間、読み込みの開始が遅いケースは見落とされがちです。LCP画像がCSSの背景画像として指定されていたり、JavaScriptで後から差し込まれていたりすると、ブラウザはHTMLを読んだ時点でその画像の存在に気づけません。img要素として直接書き、必要ならpreloadで先読みを指示します。加えて、ファーストビューの画像に遅延読み込み（loading="lazy"）が付いていると開始が遅れるため、LCP候補の画像だけは対象から外します。

第3区間になって、ようやく画像そのものの重さの話になります。第4区間の描画遅延はCSSやJavaScriptがレンダリングを止めている場合に起きるため、ブロックするスクリプトを後回しにする、使っていないCSSを削るといった対応になります。

INPの悪化はJavaScriptの実行時間を疑う

INPは、クリックやタップ、キー入力に対して画面が次に描き替わるまでの応答性を測る指標です。表示が速いサイトでもINPだけが悪いことは珍しくありません。よくあるのは、メインスレッドが長く占有されていて、ユーザーの操作をすぐ処理できていないケースです。分解して見ると、入力の待ち時間・処理そのものの時間・画面を描き替えるまでの時間の3つに分かれます。

入力の待ち時間が長い場合は、操作した瞬間に別の処理が走っていて順番待ちになっています。読み込み直後の重い初期化処理や、スクロールに反応する処理が典型です。処理時間が長いならイベントハンドラ自体が重く、描き替えまでが長いならDOMが巨大か、一度に大量の要素を書き換えています。

計測はChrome DevToolsのPerformanceパネルで行います。遅いと感じる操作を記録し、長く伸びているタスクを探せば、どのスクリプトが原因かまで辿れます。合成計測では操作を再現できないため、INPだけはこの手動の再現が欠かせません。

対処は3つです。重い処理を分割して途中でブラウザに制御を返すこと、入力直後には最小限だけを実行して残りを後回しにすること、そして不要になったスクリプトを消すこと。三番目は根本的な対処ですが、手を入れる範囲が広く見えるためか後回しにされがちです。

CLSは「いつズレたか」を特定してから直す

CLSは、表示中にコンテンツが勝手に動いた量の累積です。数値だけ見ても直せないので、まず「どの瞬間に、どの要素が動いたか」を特定します。Chrome DevToolsのPerformanceパネルで記録すると、レイアウトシフトが発生した時点と対象要素が表示されます。この特定を飛ばして推測で直そうとすると、別の場所が原因だったという結果になりがちです。

発生源はパターン化しています。サイズ未指定の画像、後から差し込まれるお知らせバーやクッキー同意の帯、遅れて表示される広告枠、Webフォント読み込み時の字形の切り替え、YouTubeや地図の埋め込み。いずれも「後から高さが確定するもの」が既存のコンテンツを押し下げることで起きます。

対処の原則はひとつ、確定していない要素の場所をあらかじめ確保することです。画像と動画には幅と高さを属性で書くか、CSSでアスペクト比を指定します。広告枠や後から入るバナーには最低限の高さを先に確保します。フォント切り替えによるズレは、代替フォントの見え方を本番フォントに寄せる指定で緩和できます。

もうひとつ忘れられがちなのが、既存コンテンツの上に何かを差し込まないという設計上の判断です。画面上部にキャンペーンの帯を後から出す実装は、CLSの観点では避けたい部類に入ります。出すなら最初から場所を空けるか、画面に重ねる形にします。

画像・フォント・JavaScript・広告タグの扱い方

3指標の原因を辿ると、修正対象は最終的にこの4つに集約されます。指標ごとではなく素材ごとに整理したほうが作業しやすいので、それぞれ何をすればよいかをまとめます。共通するのは「減らす」「後回しにする」「場所を先に確保する」の3つで、新しく何かを足す作業はほとんどありません。

画像でまずやるのは、表示サイズに対して過大な原寸画像を配らないことです。スマートフォンで幅400ピクセルに表示される画像に2000ピクセルの元データを送っていれば、圧縮率をいじる前にそこが問題です。次にWebPなど軽い形式への変換、画面外の画像への遅延読み込みと進みます。

Webフォントは、日本語では特に影響が大きい要素です。日本語フォントは収録する文字数が多いぶんファイルサイズが大きくなりやすく、書体を1つ足すだけで読み込み時間が伸びます。使う文字だけのサブセットにする、太さのバリエーションを絞る、本文は端末標準のフォントで済ませる、装飾的な書体は見出しだけに限定する、といった判断が現実的です。

JavaScriptとサードパーティタグは、棚卸しから入ります。アクセス解析、広告のコンバージョンタグ、チャットツール、ヒートマップ、SNSの埋め込み。数年運用したサイトには、誰も見ていないツールのタグが残っていることが珍しくありません。使っていないものを消し、残すものは読み込みを非同期にし、チャットのように操作するまで不要なものは後から読み込みます。

ただし、タグの削除・追加は表示速度以外の観点も確認してから行ってください。計測タグやクッキー同意の表示は、個人情報の取り扱いやユーザー情報の外部送信に関する説明と結び付いていることがあります。何をどこまで記載・通知する必要があるかは、取得している情報や事業の形態によって変わり、一律には決まりません。プライバシーポリシーの記載と実際に動いているタグが食い違っていないかを点検し、判断に迷う箇所は弁護士など法務の専門家に確認してください。

WordPressサイトで手を付ける順序

既存サイト、特にWordPressの改善では、順序を間違えると原因が分からなくなります。プラグインを一度に複数入れると、どれが効いてどれが壊したのかを切り分けられません。テスト環境を用意し、1つ変えるたびに測る。地味ですが、切り分けができるぶん結果的に早く終わります。バックアップを取ってから始めるのは前提として、以下の順で進めます。

1. 現状のフィールドデータとラボデータを記録する（比較の基準になる）
2. サーバーのプランとPHPのバージョンを確認する（TTFBの上限を決める）
3. ページキャッシュを有効にする
4. 画像の配信サイズ・形式・遅延読み込みの除外設定を直す
5. 使っていないプラグインとテーマを削除する
6. Webフォントの本数と読み込み方を見直す
7. 計測タグ・外部ツールを棚卸しする
8. テーマやページビルダーそのものを見直す

1から7までは既存サイトのまま実施できます。8だけは性質が違い、実質的に作り直しの判断です。ページビルダーで組まれたサイトは1ページに大量のCSSとJavaScriptを読み込む構造になっていることがあり、部分的な調整では限界が来ます。ここに当たったら、改善に投じる工数と作り直しの費用を比べる段階です。ホームページ制作・リニューアルのサービスでは、計測結果をもとに部分改修で足りるのか作り直すべきかを切り分けるところから相談を受け付けています。

WordPress本体にも、ページ冒頭の大きな画像を遅延読み込みの対象から外す仕組みが入っています。ただしテーマやプラグインの実装によっては期待どおりに働かないことがあるため、実際に出力されたHTMLでimg要素の属性を確認してください。WordPressの導入・運用全般の設定と合わせて点検すると漏れが減ります。

直したあとに何を確認し、どう維持するか

修正が終わっても、そこで完了にはなりません。ラボデータのスコアは即座に変わりますが、検索での評価に使われるフィールドデータは、実際の訪問が積み上がるのを待つ必要があります。この時間差を理解していないと、「直したのに評価が変わらない」と誤った結論を出してしまいます。確認の順番と、悪化を繰り返さない仕組みまでを設計に含めてください。

まずラボデータで、狙った区間が短くなったかを確認します。LCPならLCP要素の読み込み開始が早まっているか、CLSならシフトが消えているか。スコアの上下ではなく、原因として特定した箇所が改善したかを見ます。次にSearch Consoleで検証を開始し、フィールドデータが追いつくのを待ちます。

そのうえで、悪化を戻さない仕組みを作ります。表示速度は、記事を1本追加した、バナーを差し込んだ、タグを1つ足したという日常の運用で簡単に元へ戻ります。公開前のチェック項目に「画像のサイズを指定したか」「新しいタグを足していないか」を入れておくだけで、再発はかなり防げます。SEO内部対策の全体像の中の運用ルールとして組み込むのが現実的です。

計測はPageSpeed Insightsを月次で回す程度で足ります。表示速度がランキング要因としてどう扱われるかは、Google検索セントラルのCore Web Vitalsに関するドキュメントに一次情報があるので、方針を決める前に一度目を通しておくことをおすすめします。

よくある質問

PageSpeed Insightsのスコアは何点を目指せばよいですか

スコア自体に目標を置く必要はありません。検索での評価に使われるのはスコアではなく、LCP・INP・CLSの3指標がそれぞれ基準を満たしているかどうかです。スコアは原因の切り分けと修正後の比較に使う道具と考え、Search Consoleで3指標が「良好」に入ることを目標にしてください。点数そのものが目的になると、体感速度に関係のない指摘への対応に時間を使うことになります。

「十分なデータがありません」と表示される場合はどうすればよいですか

そのページを訪れたユーザーの数が、フィールドデータを集計するのに足りていない状態で、アクセスの少ないページでは珍しくありません。この場合はラボデータ（Lighthouse）で判断することになりますが、想定条件での計測なので実際の端末や回線とは乖離し得ます。アクセスの多い代表ページのフィールドデータも参考にしながら、明らかな問題から直していくのが現実的です。

スマートフォンとPCでスコアが大きく違うのはなぜですか

計測条件が違うためです。モバイルの計測は低性能な端末と遅い回線を想定しており、PCより厳しくなります。加えて、Core Web Vitalsの評価はモバイルとPCで分けて行われます。訪問がスマートフォン中心であれば、モバイルの数値を優先して改善してください。

高速化プラグインを入れれば解決しますか

原因が一致すれば効きますが、万能ではありません。キャッシュ系のプラグインはサーバー応答（TTFB）には効きますが、JavaScriptの重さが原因のINPには効きません。またJavaScriptやCSSの結合・遅延読み込み機能は、テーマやほかのプラグインと衝突して表示崩れを起こすことがあります。テスト環境で1機能ずつ有効にし、動作を確認しながら進めてください。

修正してからSearch Consoleの評価が変わるまでどのくらいかかりますか

一定期間ぶんの実測データを集計する仕組みのため、反映には時間差が生じます。修正した当日や翌日に数字が動かないのは正常です。ラボデータで狙った箇所の改善を確認したうえで検証を開始し、待っても変わらない場合は、直した箇所が主要因ではなかった可能性を疑ってください。

自社で対応できる範囲と、外注すべき範囲の線引きは

画像のサイズ調整、使っていないプラグインやタグの削除、サーバープランの見直しは、社内でも進められる範囲です。一方、テーマのテンプレート改修、JavaScriptの分割、CSSの整理はコードを触れる人が必要です。社内でできる範囲を実施して測り直し、それでも基準を満たさない部分だけを切り出して依頼すると、見積もりも判断しやすくなります。

まとめ

• スコアではなくLCP・INP・CLSの3指標を見る。判定は訪問の75パーセンタイルで行われ、自分の環境で速いことは根拠にならない
• 直すページを見つけるのはフィールドデータ、原因を特定するのはラボデータ。この使い分けを外すと施策が空振りする
• LCPは「サーバー応答・読み込み開始・読み込み時間・描画」の4区間に分解してから対処する
• INPはJavaScriptの実行時間を疑う。Chrome DevToolsで実際の操作を記録し、長いタスクを特定する
• CLSは発生した瞬間と要素を特定し、場所をあらかじめ確保する方向で直す
• 修正対象は画像・Webフォント・JavaScript・サードパーティタグに集約される
• タグの削除・追加は、プライバシーポリシーの記載との整合も確認し、迷う箇所は法務の専門家に相談する
• WordPressでは1つ変えるたびに測る。複数を同時に入れると切り分けができなくなる
• Search Consoleの数値が動くまでには時間差がある。ラボデータで改善を確認してから待つ

関連記事

• SEO内部対策の基本｜サイト構造・タグ設計・表示速度改善 - 表示速度を含む内部対策全体の位置づけが分かる親記事
• Google Search Consoleの使い方完全ガイド - Core Web Vitalsレポートの見方と初期設定
• WordPress導入・運用ガイド - 改善作業の前提となるテーマ・プラグインの運用設定
• レンタルサーバー比較｜中小企業のホームページに最適な選び方 - TTFBが原因のときに検討する乗り換え先の比較軸
• ホームページのスマホ対応ガイド｜レスポンシブ化の方法と費用相場 - モバイルでの見え方と操作性を実機で確認する観点