スマホでリンクを開いて、白い画面のまま2〜3秒待たされて、そのまま前の画面に戻ってしまう。よくある光景だが、本人は「遅かったから離脱した」とは意識していないことが多い。
Googleはこの「一瞬の遅さ」を、LCP・INP・CLSという3つの指標で数値化し、検索順位の評価にも組み込んでいる。にもかかわらず、世界のWebサイトのうち3指標すべてで基準を満たしているのはモバイルでまだ48%——半分以上のサイトが、気づかないまま訪問者を取りこぼしている計算になる。まずは自社サイトが今どの段階にあるか、この記事のチェックポイントで確認してほしい。
目次
Core Web Vitalsとは（定義）
Core Web Vitalsとは、Googleが定めるWebページの表示速度・操作への反応・レイアウトの安定性を測る3つの指標（LCP・INP・CLS）の総称です。「LCP（Largest Contentful Paint）＝画面内の最大コンテンツが表示されるまでの速さ」「INP（Interaction to Next Paint）＝クリックやタップへの反応速度」「CLS（Cumulative Layout Shift）＝表示中の要素のガタつき（レイアウトのずれ）」の3つを指し、それぞれに「Good（良好）」「Needs Improvement（改善が必要）」「Poor（不良）」の基準値が設けられています。基準は、LCPが2.5秒以内、INPが200ミリ秒以内、CLSが0.1以内であれば「Good」評価です（出典: Google web.dev「Largest Contentful Paint (LCP)」「Interaction to Next Paint (INP)」「Cumulative Layout Shift (CLS)」）。この3つすべてで基準を満たして初めて、Core Web Vitalsが「良好」なページと判定されます。
指標ごとに、悪化する原因はだいたい決まっている。LCPが遅いサイトの大半は、圧縮していないヒーロー画像、読み込みを妨げるCSS・JavaScript、サーバーの応答そのものが遅い（TTFBが長い）のいずれかが原因になっている。INPが悪いサイトは、チャットウィジェットや広告タグ、アクセス解析など複数のサードパーティスクリプトが同時にブラウザのメインスレッドを占有し、タップしても反応が返ってこない状態に陥っているケースが多い。CLSが悪いサイトは、サイズを指定していない画像や広告枠が読み込み途中に挿入され、読んでいた文章が下にずれる——Webフォントの切り替わり（読み込み前後で文字の見た目が変わる現象）も同じ原因で起きる。原因が指標ごとに違う以上、「なんとなく重い」で一括りにせず、どの指標が悪いのかを先に特定することが対策の出発点になる。
なぜ今、表示速度・Core Web Vitals対策が必要なのか
「体感で重い」と「指標で悪い」は別物だ、というのがここ数年のGoogleの姿勢である。
Googleは2020年5月、Core Web Vitalsを検索順位の評価要素に組み込むと正式発表しました。
モバイル検索への反映は2021年6月から数か月かけて段階的に、デスクトップへの適用は2022年2月から。今のGoogleは、コンテンツの中身だけでなく「読み込み体験」そのものを順位算定に織り込んで判定しています。
出典: Google Search Central Blog「Evaluating page experience for a better web」
世界のWebサイトのうち、Core Web Vitalsの3指標すべてで基準を満たしているのはモバイルでまだ48%です。
2023年は36%、2024年は44%、2025年は48%と着実に伸びてはいますが、伸び幅は年々小さくなっており、この先も一定数のサイトが基準未達のまま残ると見られます。デスクトップですら56%です。
スマートフォンでWebサイトの表示を待てる時間は、10秒以下と答えた人が71.3%にのぼります。
もっとも多い回答は「4〜5秒程度」（27.3%）、ストレスを感じ始めるのは「6〜10秒程度」から（27.4%）が最多でした。ユーザーが許容する時間は思っているより短く、しかもその境界線は数秒単位でシビアに引かれています。
Webサイト担当者の42.0%が、自社サイトの表示速度に不満を感じたことがあると回答しています。
一方で、表示速度を明確な改善項目として認識しているのは37.4%にとどまります。不満はあっても優先度には上がっていない——「気になってはいるが、後回しにしている」担当者は、決して少数派ではありません。
「速い方がいいのは分かるが、どこまでやればいいのか」が分かりにくいのがこの分野の難しさだ。まずは自社サイトが今どの段階にあるかを、次の比較で確認してみてほしい。
表示速度対策 状態別比較
Webサイトの表示速度対策は、次の3段階のどこかに当てはまる。どこまで対応できているか確認してみてほしい。
← 横にスクロールできます →
| チェック項目 | 対策していない | ツールに任せて放置 | 体系立てて改善（推奨） |
|---|---|---|---|
| LCP（表示の速さ） | 計測したことがない | キャッシュ系プラグインを入れただけ | 2.5秒以内を目標に画像・サーバーまで見直し済み |
| INP（操作の反応） | 意識したことがない | 不要なJavaScriptが残ったまま | 200ミリ秒以内を目標に不要なスクリプトを整理済み |
| CLS（レイアウトのずれ） | 広告や画像でガタつきが起きている | 気づいた箇所だけ対応 | 画像・広告枠にあらかじめサイズを指定済み |
| 画像の最適化 | 撮影・入稿したままの容量 | 一部のページのみ圧縮 | 次世代フォーマット・圧縮を全ページで統一 |
| キャッシュ・CDN設定 | 未設定 | プラグイン任せで内容を未確認 | 設定内容を把握し、定期的に見直している |
| モバイルでの確認 | PCでの見た目しか確認していない | 表示は見るが速度は未計測 | 実際のユーザーデータ（CrUX）でモバイルを個別に確認 |
初めて手を付けるなら、優先順位はシンプルに決めてよい。①まずLCP——画像の圧縮とサーバー応答の見直しは、工数のわりに数値が動きやすい。②次にCLS——広告枠や画像にwidth・heightを指定するだけで改善するケースが多く、費用対効果が高い。③最後にINP——原因になっているスクリプトの特定に時間がかかるため後回しにされがちだが、放置すれば数値は動かない。キャッシュ系プラグインを入れること自体は、どのサイトでも同じスタートラインに立てる。差がつくのはそこから先、指標ごとの実測値を見てこの順番で手を付けているかどうかだ。
表示速度・Core Web Vitals対策が効く活用シーン
- 新規のホームページ制作時 — 設計段階でヒーロー画像のサイズやフォントの読み込み方針まで決めておけば、公開後に「調べたら重かった」と慌てて手戻りする事態を防げる。
- リニューアル前の現状診断 — 作り直す前に旧サイトのLCP・INP・CLSを計測しておくと、何が遅かったのかが分かり、新しいサイトで同じ原因を繰り返さずに済む。
- 広告出稿と合わせたランディングページ — 広告を出した初日に「クリックはあるのに申込みが伸びない」となり、原因を追うとページの表示に4秒以上かかっていた、というのはよくある話だ。広告費をかけて呼び込んだ訪問者ほど、表示の遅さには厳しい。
- ECサイト・予約フォームなどコンバージョンに直結するページ — カートに入れた直後や決済画面で数秒固まると、その場で離脱される。後からログを見返しても「なぜこのステップで離脱が多いのか」までしか分からず、原因は表示速度だったというオチも珍しくない。
自社サイトを見直すときのチェックポイント
- 実測値を確認しているか — Google PageSpeed Insightsなど無料ツールで、体感ではなく実際の数値（LCP・INP・CLS）を確認しているか
- モバイルとデスクトップを分けて見ているか — Web Almanacの調査でもモバイルの方が合格率が低く、モバイルを優先して確認する必要があるか
- 改善対象の指標を絞れているか — 「なんとなく重い」で終わらせず、LCP・INP・CLSのどれが基準未達なのかを特定できているか
- 継続的にモニタリングできる体制か — 一度改善して終わりでなく、新しい画像やプラグインの追加で悪化していないか定期的に確認できるか
よくある質問（FAQ）
Q. LCP・INP・CLS、どれから改善すればいいですか？
A. 優先順位は影響範囲と工数のバランスで決めるのが実務的です。LCPは画像圧縮やサーバー応答時間の見直しだけで数値が動きやすく、多くの場合最初に着手する指標になります。CLSも広告・画像にサイズ指定を入れるだけで直ることが多く、費用対効果が高い部類です。INPは原因になっているスクリプトの特定に時間がかかるため後回しにされがちですが、放置すると改善しません。
Q. PageSpeed InsightsとSearch ConsoleのCore Web Vitalsレポート、どちらを見ればいいですか？
A. 両方見る必要があります。PageSpeed Insightsは「今この瞬間」を計測した実験室データ、Search Consoleは実際に訪れたユーザーの直近28日間の実測データです。実験室データだけ良くても、実際のユーザー環境（回線・端末）で悪ければ、検索順位の評価には実測データの方が使われます。
Q. 一度改善したのに、数か月後にまた数値が悪化していました。なぜですか？
A. 新しく追加した画像・プラグイン・広告タグが、気づかないうちにLCPやCLSを悪化させているケースが典型です。表示速度は一度直して終わりではなく、追加・更新のたびに数値がぶれるため、定期的な計測が欠かせません。
Q. モバイルとPCでスコアが大きく違うのは普通ですか？
A. 普通です。モバイルは回線速度・端末の処理性能でPCより不利な条件で計測されるため、同じサイトでもスコアが下がりやすくなります。HTTP Archiveの調査でもモバイルの合格率（48%）はデスクトップ（56%）より低く、モバイルを基準に改善計画を立てるのが安全です。
まとめ: 表示速度対策は「実測してから直す」が基本
Core Web Vitalsは、LCP・INP・CLSという3つの数値に「遅い」「使いにくい」という感覚を翻訳した指標だ。世界の半分以上のサイトがまだ基準に届いていないという現状は、裏を返せば、計測して直すだけで一歩抜け出せる余地が大きいということでもある。何から手をつけるか迷ったら、この記事の比較表で示した順番——LCP→CLS→INP——から着手すれば遠回りにならない。
「何から手をつければいいか分からない」という場合は、サイト全体の設計・サーバー選定まで含めて相談できる制作会社に頼るのも一つの方法だ。liensでは、表示速度対策も含めたホームページ制作・リニューアルの相談を受け付けている（なお、liensはAIチャットボット「LIENS BOT」の開発・運用代行も手がけている）。
関連記事: WordPressのSEO設定ガイド：公開前に整えたい6つの基本設定 ／ 独自ドメイン・レンタルサーバーの選び方——ホームページを持つ前に決めること
出典一覧
- Google Search Central Blog「Evaluating page experience for a better web」（2020年5月）
- Google Search Central Blog「More time, tools, and details on the page experience update」（2021年4月）
- Google Search Central Blog「Timeline for bringing page experience ranking to desktop」（2021年11月）
- Google web.dev「Largest Contentful Paint (LCP)」
- Google web.dev「Interaction to Next Paint (INP)」
- Google web.dev「Cumulative Layout Shift (CLS)」
- HTTP Archive「2025 Web Almanac」Performanceチャプター
- MMD研究所×株式会社TeN「消費者のWEBサイトの表示に関する調査」（2025年6月）
- MMD研究所×株式会社TeN「WEBサイト表示速度に関する担当者の意識調査」（2025年6月）