Domain 9 / 225

Core Web Vitals は LCP / INP / CLS の 3 指標で UX を測る

Core Web Vitals の要点

Core Web Vitals は実体験 UX を計測する 3 指標。LCP(読み込み 2.5 秒以内)/ INP(応答性 200ms 以内)/ CLS(視覚安定性 0.1 以下)。ページ体験全体の 1 要素で、完璧スコアを SEO 目的だけで追うのは推奨されない

なぜこれを学ぶか

Core Web Vitals は Google が「ページ体験」をランキングに組み込む際の主要シグナル。 ここを無視すると、コンテンツが良くてもユーザーがすぐに離脱して順位が伸びないし、競合と僅差の SERP では Core Web Vitals のスコアが順位の決め手になる。

EC・メディア・大規模サイトでは特に効果が大きく、改善 1 つで CTR と CV 率が同時に上がる「無料の UX 投資」として優先度が高い。

学ばないと起きること

よくある事故被害
LCP が 4 秒超えのまま放置ユーザーの 50% が離脱、検索順位も伸びない
INP が 500ms 超え(クリック → 反応が遅い)フォーム入力 / 検索 / カートに追加でユーザーがストレス、CV 率低下
CLS が 0.5 超え(広告で内容がガクガク動く)誤クリック / 読み戻し発生でユーザー体験悪化、Better Ads 違反の温床
FID(旧指標)を改善し続けてしまう2024 年に INP に置き換え済み、FID は廃止指標
Lighthouse の Lab スコアだけ追う実ユーザーの Field データ(CrUX)と乖離して、Search Console の評価と食い違う
Core Web Vitals 完璧を SEO 目的だけで追求Google 公式が「順位を保証しない、ユーザー体験のための指標」と明言、工数が報われない

学ぶメリット

  • ユーザーの離脱を減らして、コンテンツ品質をフルに評価される土台を作れる
  • Google のページ体験評価で他サイトより優位を取れる
  • Search Console の Core Web Vitals レポートを正しく読み解いて、改善優先度が判断できる
  • 「LCP は読み込み / INP は応答性 / CLS は視覚安定性」と即答できれば技術 SEO の基礎力を示せる

仕組み

3 指標の概要

指標計測する内容良好値改善必要不良
LCP(Largest Contentful Paint)主要コンテンツの読み込み時間2.5 秒以下4.0 秒以下4.0 秒超
INP(Interaction to Next Paint)クリック / タップへの応答性200ms 以下500ms 以下500ms 超
CLS(Cumulative Layout Shift)視覚的な安定性(要素のズレ)0.1 以下0.25 以下0.25 超

「良好」評価には、ページのフィールドデータ(実ユーザーアクセス)の 75 パーセンタイルが基準値以下 になっている必要がある。

LCP(Largest Contentful Paint)

ページ内で最大の要素(多くの場合ヒーロー画像 / 大見出し / 動画サムネイル)が viewport 内に表示されるまでの時間。

改善手法効果
画像を WebP / AVIF 化ファイルサイズ削減で読み込み高速化
ヒーロー画像に fetchpriority="high" を指定優先取得でレンダリング前倒し
クリティカル CSS をインライン化レンダリングブロック削減
サーバー応答時間(TTFB)の改善LCP の前段階を短縮
大きな画像の遅延読み込みを ATF(above the fold)から外す主要コンテンツが先に出る

INP(Interaction to Next Paint)

ユーザーがクリック / タップ / キー入力した時、画面が次に更新されるまでの時間。 2024 年 3 月に旧指標 FID(First Input Delay)を置き換えた。

改善手法効果
メインスレッドをブロックする JavaScript を分割重い処理を細切れにして応答性向上
サードパーティスクリプト(広告 / 分析)を遅延読み込み初期インタラクション時の負荷軽減
requestIdleCallback で非緊急処理を後回しユーザー操作の応答を優先
React の useDeferredValue / useTransition を使う重い更新を中断可能にする

CLS(Cumulative Layout Shift)

ページ読み込み中に要素が想定外に動くことで起きる視覚的不安定さの累積スコア。

改善手法効果
画像 / 動画に width / height 属性を必ず指定レイアウト計算が確定して動かない
広告枠を固定サイズ予約広告が後から差し込まれてもズレない
Web フォントは font-display: optional または swap を慎重に使うフォント切り替え時のテキストずれ最小化
動的に追加するコンテンツは ATF を避けるスクロール位置のズレを防ぐ

キー概念

Core Web Vitals は「ページ体験」の一部

Google 公式立場: Core Web Vitals は単一のランキングシグナルではなく、ページ体験全体の中の 1 要素

ページ体験を構成する他の要素:

  • HTTPS 化されているか
  • モバイル対応されているか
  • 邪魔なインタースティシャル(ポップアップ)がないか
  • 広告がコンテンツを邪魔していないか
  • メインコンテンツとそれ以外が見分けやすいか

計測の 2 つの方法

方法データ源用途
Lab データLighthouse / PageSpeed Insights のシミュレーション開発時の改善効果検証
Field データChrome User Experience Report(CrUX)= 実ユーザーアクセスSearch Console / SEO 評価で使われる

開発時は Lab、SEO 評価は Field。両者は乖離することがあり、Field データが Search Console の判定に使われる。

完璧スコアを SEO 目的で追わない

Google 公式の警告:

Search Console の Core Web Vitals レポートで良い結果を得ても、検索結果のトップに必ず出るわけではない。スコアは SEO のためというより、ユーザー全体の体験を改善するためのもの。

Core Web Vitals は 順位を保証する指標ではなく、悪いと足を引っ張る守備指標。完璧スコアを目指すより、不良判定を避ける方が ROI が高い。

モバイル / デスクトップで別評価

Core Web Vitals はデバイス別に測定される。モバイルファーストインデックスにより、Google はモバイル版のスコアを主要シグナルとして使う。 モバイルが弱い場合、デスクトップが良好でも順位への影響はモバイルが優先する。

よくある誤解

よくある誤解実際のところ出典
Core Web Vitals は LCP / FID / CLS の 3 指標FID は 2024 年 3 月に INP に置き換えられた。現在は LCP / INP / CLSCore Web Vitals
TTFB は Core Web Vitals に含まれる含まれない。LCP に影響する関連指標同上
完璧スコアを取れば検索結果のトップに出る出ない。Google が公式に否定Page Experience
Lighthouse のスコアが Search Console の評価と一致しないことがある。Lab データと Field データの乖離同上
CWV が良ければページ体験は OKページ体験は HTTPS / モバイル対応 / 広告 / インタースティシャルなど複数要素の総合評価同上
Core Web Vitals はサイト全体で評価される基本はページ単位で評価。ただしサイト全体の評価軸も一部存在同上
デスクトップが良ければモバイルが悪くても OKモバイルファーストインデックスで、モバイル版のスコアが優先されるモバイルファーストインデックス
CWV を改善すれば即座に順位が上がるページ体験は数あるシグナルの 1 つ。コンテンツの関連性が低ければ CWV 改善でも上位は取れないPage Experience

実務での適用

改善優先順位の決め方

  1. Search Console の Core Web Vitals レポートで「不良」「改善必要」の URL を特定
  2. PageSpeed Insights で各 URL の Field データを確認、3 指標のどれが原因か特定
  3. テンプレート単位で問題を切り分け(記事ページ全体 / 商品ページ全体 / トップページのみなど)
  4. テンプレート単位で修正して、影響が広い順に対処

LCP 改善のクイックウィン

<!-- ヒーロー画像に fetchpriority -->
<img src="hero.webp" fetchpriority="high" alt="...">

<!-- preload で重要リソースを先取り -->
<link rel="preload" as="image" href="hero.webp">

<!-- WebP / AVIF に変換 -->
<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="...">
</picture>

INP 改善のクイックウィン

// 重い処理は分割
async function processLargeData(items) {
  for (let i = 0; i < items.length; i++) {
    process(items[i]);
    if (i % 100 === 0) {
      // 100 件ごとにブラウザに制御を返す
      await new Promise(r => setTimeout(r, 0));
    }
  }
}

// React なら useDeferredValue
const deferredValue = useDeferredValue(searchQuery);

CLS 改善のクイックウィン

<!-- 必ず width / height を指定 -->
<img src="article.jpg" width="800" height="450" alt="...">

<!-- 広告枠は固定サイズで予約 -->
<div style="width: 300px; height: 250px;" id="ad-slot"></div>

トラブル別の対処

症状確認すべきこと
Search Console「Core Web Vitals」で URL が大量に「不良」にテンプレ単位で原因切り分け、PSI の Field データで指標を特定
LCP が突然悪化したヒーロー画像のサイズ変更 / CDN 変更 / サーバー応答時間の劣化を確認
INP が悪化、特にモバイルで広告 / 計測タグ / チャットウィジェットなど後追加スクリプトを疑う
CLS スコアが 0.5 超え広告枠の固定化、画像 width / height、フォント切り替えを確認
Lighthouse は 90 点なのに Search Console で「不良」Lab と Field の乖離。Field データ(CrUX)の改善が SEO 評価に直結

公式ソース

自己テスト

Q1. Core Web Vitals の 3 指標は?

LCP(Largest Contentful Paint)/ INP(Interaction to Next Paint)/ CLS(Cumulative Layout Shift)。 旧 FID は 2024 年 3 月に INP に置き換えられた

Q2. LCP の良好値は?

2.5 秒以下。実ユーザーの 75 パーセンタイルが 2.5 秒以下になっている必要がある

Q3. INP の良好値は?

200ms 以下。クリック / タップから次のレンダリングまでの応答時間

Q4. CLS の良好値は?

0.1 以下。ページ読み込み中の累積レイアウトシフトのスコア

Q5. TTFB は Core Web Vitals に含まれるか?

含まれない。ただし TTFB(Time to First Byte)は LCP に影響する関連指標として重要

Q6. Core Web Vitals を完璧にすれば検索結果のトップに出るか?

出ない。Google 公式が「Core Web Vitals は順位を保証する指標ではない」と明言。 ページ体験全体の 1 要素にすぎず、コンテンツの関連性や品質が前提

Q7. Lighthouse のスコアと Search Console の Core Web Vitals 評価が一致しないのはなぜ?

Lighthouse は Lab データ(シミュレーション)、Search Console は Field データ(CrUX = 実ユーザーアクセス)を使う。 SEO 評価には Field データが使われる

Q8. デスクトップが良好でモバイルが不良の場合、SEO 評価はどうなる?

モバイルが優先される。モバイルファーストインデックスで Google はモバイル版を主要シグナルとして使う

これらの内容を採点付きで挑戦したい場合は、本ドメインのプロ試験で 5 問形式で確認できる。