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 / CLS | Core 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 |
実務での適用
改善優先順位の決め方
- Search Console の Core Web Vitals レポートで「不良」「改善必要」の URL を特定
- PageSpeed Insights で各 URL の Field データを確認、3 指標のどれが原因か特定
- テンプレート単位で問題を切り分け(記事ページ全体 / 商品ページ全体 / トップページのみなど)
- テンプレート単位で修正して、影響が広い順に対処
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 評価に直結 |
公式ソース
- Core Web Vitals と Google 検索結果について
- ページ エクスペリエンスについて
- LCP の最適化(web.dev)
- INP の最適化(web.dev)
- CLS の最適化(web.dev)
- Search Console Core Web Vitals レポート
自己テスト
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 問形式で確認できる。