先に要点
- 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 ライブラリ