先に要点
- Core Web Vitals (CWV) は Google が定める Web ページ品質の中核指標。LCP(最大要素表示時間)・CLS(レイアウトのずれ)・INP(操作応答性)の 3 つで構成され、SEO のランキング要素として継続的に影響している。
- 2024 年 3 月に FID(First Input Delay)が INP(Interaction to Next Paint)に置き換わり、より厳しい応答性評価に変わった。「INP は全インタラクションの応答性を見る」 ので、シングルページアプリや JS が重いサイトで悪化しやすい。
- 3 指標の合格ライン: LCP ≤ 2.5 秒 / CLS ≤ 0.1 / INP ≤ 200ms。75 パーセンタイルで合格判定するため、「平均は良いが裾の長いサイト」 は油断できない。
- 改善の優先順位は LCP → CLS → INP。LCP は CDN + 画像最適化(AVIF / WebP)で短期改善しやすい。CLS は 「画像/iframe の width/height 明示」 と 「Web フォントの swap」 で大半が解決。INP は 「重い JS の分割 / メインスレッド開放」 で改善するが、根本対応に時間がかかる。
- 計測は PageSpeed Insights / Search Console の Core Web Vitals レポート / Chrome User Experience Report (CrUX) / Real User Monitoring (RUM) を使い分ける。「Lab データ(Lighthouse)」 と 「Field データ(実ユーザー計測)」 で順位やスコアが違うので両方見る。
「サイトの表示速度を改善したい」「SEO 順位を上げたい」── これらの相談で必ず出てくるのが Core Web Vitals(CWV) です。Google が 「ページの体験」 を定量化するために導入した指標で、「検索順位に影響する Web 品質スコア」 として 2021 年以降ずっと注目されています。
ざっくり言うと、CWV は LCP(表示の速さ)・CLS(レイアウトの安定性)・INP(操作の応答性) の 3 つの数値で 「ユーザー体験」 を測ります。各指標の合格ラインを満たすかどうかが、検索順位 + ユーザー体験の両方に直結します。
この記事では、CWV の 意味・現状(2024〜2026 の変化)・計測ツール・改善施策の優先順位 を実務目線で整理します。画像最適化との関係では AVIF / WebP も併読してください。
Core Web Vitals とは — 3 指標と合格ライン
Google が 「Web ページの体験を定量化するため」 に選んだ中核指標です。
| 指標 | 正式名 | 何を測るか | 合格ライン (Good) | 要改善ライン |
|---|---|---|---|---|
| LCP | Largest Contentful Paint | ページ内で最大の要素(画像 / 見出し / 動画)が表示されるまでの時間 | ≤ 2.5 秒 | 2.5〜4 秒 |
| CLS | Cumulative Layout Shift | ページ読み込み中に発生する 「予期しないレイアウトのずれ」 の累積 | ≤ 0.1 | 0.1〜0.25 |
| INP | Interaction to Next Paint | クリック / タップ / キー入力に対する 「反応の遅さ」 の中央値〜長い側 | ≤ 200ms | 200〜500ms |
「75 パーセンタイル」 で評価されるため、「平均は良いが、遅い 25% のユーザーがいる」 状況は合格にならない点が重要です。
INP の登場(2024) — FID からの大きな変化
2024 年 3 月に FID(First Input Delay)が INP に正式に置き換わりました。これは CWV 史上の大きな変化で、「SPA / JS が重いサイトのスコアが軒並み悪化」 した転換点でした。
FID の問題
FID は 初回操作の遅延だけを測っていたため、「ページ読み込み後の操作応答性」 が見えなかった。「初回は速いが、その後の操作が重いサイト」 は FID が良くてもユーザー体験は悪い、という矛盾があった。
INP の改善点
INP は ページ滞在中の全インタラクションの応答性を測る。「スクロール、クリック、キー入力、タップ」 などすべての操作で 「次の描画までの時間」 を計測し、その中の長い側(98 パーセンタイル)を採用。
影響
移行時に 多くのサイトが INP で要改善判定に。特に SPA / React 重ね / 大量の useEffect / 重いライブラリを持つサイトで悪化。「FID では合格だったが INP では失格」 のサイトが多数発生。
対策の方向性
「 メインスレッドの長時間ブロックを避ける」 が核心。重い処理を Web Worker / requestIdleCallback / setTimeout で分割、「React の useDeferredValue / useTransition」 を活用、「サードパーティスクリプトの遅延読み込み」 で改善する。
計測ツール — Lab vs Field の使い分け
CWV を計測するツールは複数あり、「Lab(模擬環境)」 と 「Field(実ユーザー計測)」 で結果が違います。
PageSpeed Insights
Google 公式の Web ツール。Lab データ(Lighthouse)と Field データ(CrUX)を両方表示。「URL を入れるだけで指標 + 改善提案を出してくれる」 ので、最初の現状把握に最適。
Search Console の CWV レポート
サイト全体の URL 別 CWV ステータス(良好 / 改善が必要 / 不良)を表示。「どの URL が遅いか」 を一覧で把握できる。Search Console を導入していれば必ず見るべき。
Chrome User Experience Report (CrUX)
Chrome ユーザーの 実際の体感データを集計した公開データセット。「BigQuery で生データを取得」 もでき、「競合サイトの CWV を見る」 こともできる。Web パフォーマンス改善の 「真の事実」 を持つデータソース。
Real User Monitoring (RUM)
「 自分のユーザーの実測値を継続収集」 するツール。web-vitals.js ライブラリ + Datadog / New Relic / SpeedCurve / Calibre などで実装。「自社特有の遅いページ / 遅いユーザー層」 を特定できる。
「Lab データは改善施策の効果確認、Field データは実際の SEO 影響」 で見るのが基本です。
LCP 改善 — もっとも効果が出やすい
LCP は 「ページの最大要素(画像 or テキスト)が表示されるまでの時間」。改善施策が効きやすく、まず手をつける指標です。
「画像最適化 + CDN + preload + クリティカル CSS」 でほぼ全サイトが LCP 2.5 秒以内に到達できる、というのが現代の経験則です。
CLS 改善 — 「予期しないずれ」 を消す
CLS は 「読み込み中に画面要素が予期せず動く現象」。多くは サイズ未指定の画像 / iframe / 広告 / Web フォントが原因。
画像と iframe に width / height を必ず明示
HTML に 「width」 と 「height」 属性を必ず書く。「CSS で width 100% にする場合」 でも、「HTML 属性は実寸を書いて aspect-ratio を効かせる」。これだけで CLS の半分以上が改善するサイトが多い。
Web フォントの swap 設定
「 font-display: swap」 を CSS に明示。「font-display: block」 だと 「フォント未ロード時にテキスト非表示 → ロード後に表示でレイアウトがずれる」 という典型 CLS 原因。「Self-host + preload + swap」 が現代の標準。
広告 / ダイナミックコンテンツの予約スペース
「 後から差し込まれる広告 / Cookie 同意バナー / おすすめ枠」 のために min-height で予約スペースを確保する。「差し込み時にレイアウトが押し下がる」 のを防ぐ。
アニメーションは transform で
` 要素を動かすときは 「top / left / margin」 ではなく 「transform: translate」 を使う。transform は レイアウト計算を発生させないため CLS を生まない。
INP 改善 — メインスレッドを開放する
INP 改善は CLS / LCP より 根本対応に時間がかかるのが現実。「JS の重さ」 が直接効く指標です。
サードパーティスクリプトの整理
「 Google Analytics / GTM / 広告タグ / チャットウィジェット」 など サードパーティ JS が INP の最大の敵。「Partytown で Web Worker に追い出す』 『 重要でないものは遅延読み込み』 『 不要なものは削除」 で改善する。
React の重い更新を分割
React 18+ の 「useTransition」 / 「useDeferredValue」 で 「重い再レンダリングを優先度の低い更新として遅延」 できる。「大量リストの再描画 / 検索結果フィルタ」 で効果大。
長い JS タスクを分割
「 1 つの JS タスクが 50ms を超えるとブロックされる感覚が出る」。「scheduler.yield()」 (新 API) / 「setTimeout 0」 / 「requestIdleCallback」 で処理を分割する。
バンドルサイズの削減
「 重い依存(moment / lodash 全部読み込み)を tree-shaking』 『 動的 import で必要な時だけロード』 『 軽量代替(date-fns / dayjs)に切り替え」 で、初回パースのコストを下げる。
改善施策の優先順位
「どこから手を付けるか」 を整理します。
ハマりやすいポイント
実装で踏みやすい落とし穴を整理します。
Lab と Field のスコアが違って混乱
「 PageSpeed Insights の Lighthouse スコアは良いのに、CrUX (実ユーザー)では不良」 が頻発。Lighthouse は単発測定、CrUX は実ユーザーの 28 日平均なので、「現実のユーザー環境(古いスマホ、遅い回線、バックグラウンドアプリ多数)」 を反映する。改善判断は 必ず Field データを優先。
改善が反映されるまで時間がかかる
CrUX / Search Console の CWV は 28 日のローリング平均。「今日改修して明日改善」 ではなく、「改修してから 4 週間程度待たないと指標が動かない」。短期効果は Lab、長期は Fieldで見る。
モバイルとデスクトップで別計測
CWV は モバイルとデスクトップで別々に評価される。Google はモバイル指標を重視するので、「スマホで遅いと SEO に直接効く」。「モバイル優先で施策を考える」 のが現代の標準。
ページ単位ではなく URL 単位
同じテンプレートでも 「URL ごと」 に CWV は計測される。トラフィックの多いトップページや人気記事から優先改善が効率的。「サイト全体平均で見ると埋もれる」 個別ページの問題を Search Console で見つける。
Core Web Vitals に関するよくある質問
Q. Lighthouse スコア 90 以上なら CWV 合格と言えますか?
A. 必ずしも合格ではありません。Lighthouse スコア(Performance Score)と CWV(LCP / CLS / INP の合格判定)は別物。Field データ(CrUX)で 75 パーセンタイルが Good ライン以下であることが、SEO 上の合格条件です。Lighthouse スコアは改善施策の効果確認に使い、最終判断は Field データで。
Q. INP が悪い時、まず何を見るべきですか?
A. サードパーティスクリプトのリストアップから。GA / GTM / 広告 / Heatmap / Cookie 同意バナーなどを洗い出し、本当に必要か / 遅延読み込みできないかを一つずつ確認。「Partytown」 のようなツールで Web Worker に追い出すと一気に改善することも多い。
Q. CLS をゼロにすることは可能ですか?
A. ほぼゼロにはできる。「画像 / iframe に width/height 明示 + Web フォント swap + 広告枠予約 + transform アニメ」 を徹底すれば、CLS 0.05 以下は実現可能。完全ゼロは難しいですが、合格ライン(0.1)を大きく下回ることは現実的です。
Q. CDN を入れれば LCP は改善しますか?
A. ほぼ確実に改善します。特に 海外ユーザーがいるサイトで効果大。CDN を入れていない場合、「東京サーバ → 米国ユーザー」 の往復で 300ms 以上消費するため、CDN の効果が劇的。日本国内のみのサイトでも、「画像 / CSS / JS の並列配信 + Edge キャッシュ」 で 100〜500ms 改善する事例が多い。
Q. SSR と SPA、どちらが CWV に有利?
A. SSR(または SSG)が有利。SPA は 「初回読み込みで大量の JS をパースしてから描画」 するため LCP が遅くなりやすい。SSR / SSG は サーバ側で HTML を生成して即座に表示できるため、LCP が短くなる。INP は SPA で悪化しやすいので、SSR + 部分的ハイドレーション(Islands Architecture)が現代の理想形。
Q. WordPress でも CWV を改善できますか?
A. 改善可能。「Smush / WP Rocket / NitroPack / Perfmatters」 のような最適化プラグイン + 「軽量テーマ(GeneratePress / Astra)」 + 「CDN(Cloudflare)」 の組み合わせで、多くの WordPress サイトが Good ラインに到達できる。「重いテーマ + 大量プラグイン」 は INP が悪化しやすいので注意。
Q. CWV が悪いと SEO 順位はどれくらい下がりますか?
A. 大きくはないが確実に効く。Google は 「CWV は同等品質のページがあった時の tiebreaker 的に効く」 と説明しており、「コンテンツ品質に圧倒的差があれば CWV が悪くても上位」 もあり得る。一方、競合と僅差なら CWV の差が順位に直結するため、「競合が CWV 改善している中で放置すると差が広がる」 のが現実。
まとめ
Core Web Vitals は Google の SEO ランキング要素として継続的に重要で、「LCP / CLS / INP の 3 指標を Good ラインに収める」 ことが Web パフォーマンスの現代基準です。
「LCP は画像最適化と CDN で短期改善、CLS は HTML 属性とフォント設定で大半解決、INP はサードパーティ JS 整理と JS タスク分割で根本対応」 が改善のセオリー。Lab データで施策効果を確認しながら、Field データ(CrUX / Search Console)で SEO への反映を待つのが運用パターンです。AVIF / WebP 導入と組み合わせれば、LCP 改善はさらに加速します。
参考リンク
- web.dev: Core Web Vitals
- Google: PageSpeed Insights
- web.dev: INP の改善
- Chrome User Experience Report: CrUX
- GitHub: web-vitals JavaScript ライブラリ