SEO最終更新日: 2026年6月17日初出: 2026年5月4日

Core Web Vitals入門｜LCP・INP・CLSをやさしく解説

Core Web Vitalsの3指標LCP・INP・CLSを初心者向けに解説。2026年最新の目標値、計測方法、改善の優先順位を実践レベルでまとめました。

文責: LLMOツール編集部

#Core Web Vitals#ページ速度#UX指標

目次（52項目）

はじめに
Core Web Vitalsとは
Core Web Vitals が SEO にどう効くか
LCP（Largest Contentful Paint）の詳細
LCP 要素として認識されるもの
LCP を構成する 4 つのフェーズ
LCPを改善する方法
LCP 悪化のよくあるアンチパターン
INP（Interaction to Next Paint）の詳細
FID から INP への移行（2024 年 3 月）
INPを改善する方法
INP のフレームワーク別注意点
CLS（Cumulative Layout Shift）の詳細
CLS スコアの計算式
CLSを改善する方法
CLS の優先対応リスト
計測ツール
各ツールの使い分け早見表
PageSpeed Insights の読み解き方
Search Console の Core Web Vitals レポート
フィールドデータと Lab データの違い
モバイルとデスクトップの戦略の違い
業界別の Core Web Vitals 戦略
失敗事例
失敗 1: 画像最適化を「圧縮」だけで済ませた
失敗 2: タグマネージャに 30 個以上のタグを詰め込んだ
失敗 3: AdSense 自動広告を有効化したまま
失敗 4: フォント最適化を後回し
失敗 5: SPA のクライアント側ルーティング
改善ロードマップ
AI / LLMO への影響
ツール一覧
Core Web Vitals の最適化フロー
LCP（Largest Contentful Paint）改善の手順
INP（Interaction to Next Paint）改善の手順
CLS（Cumulative Layout Shift）改善の手順
実機計測の重要性
改善の優先順位
SEOへの影響
2026年のトレンド
2026年の Core Web Vitals 動向
よくある質問
Q1. WordPressでCore Web Vitalsを改善するには？
Q2. ページ速度はランキング1位を取れる要因ですか？
Q3. PageSpeed Insightsとフィールドデータでスコアが違うのはなぜ？
Q4. LCPを2.5秒以下にできない場合、SEOに不利ですか？
Q5. CLS が突然悪化しました。どこから調査すべきですか？
Q6. SPA で Core Web Vitals が悪い場合、SSR にすべき？
Q7. AI クローラー（GPTBot 等）にも Core Web Vitals は効きますか？
関連用語
関連記事
参考文献・出典

Core Web Vitals入門｜LCP・INP・CLSをやさしく解説

この記事の結論: Core Web VitalsはLCP（表示速度）・INP（操作反応）・CLS（レイアウト安定性）の3指標です。それぞれ2.5秒以下、200ms以下、0.1以下が目標値で、Search Consoleで計測できます。

最終更新日: 2026-05-05

はじめに

「ページ速度がSEOに効くって聞いたけど、何を測るの？」という疑問に答える記事です。Googleが2020年に発表したCore Web Vitalsの3指標を、初心者向けに分かりやすく解説します。改善の優先順位や計測ツールも紹介します。

本記事は単なる用語紹介で終わらせず、LCP / INP / CLS それぞれを「何が原因で悪化し、どうやって直すか」まで踏み込みます。さらに、2024年3月の FID → INP 移行、モバイルファーストインデックス時代の評価軸、AI クローラーとの関係、業界別の戦略、失敗事例、改善ロードマップまで網羅します。 → 詳しくはSEOとは？初心者向け完全ガイド【2026年版】も参照してください。

Core Web Vitalsとは

Core Web VitalsはGoogleが定義したUX（ユーザー体験）の核心指標で、ページがどれだけ「気持ちよく」使えるかを定量化したものです。2021年6月からランキングシグナルとして組み込まれ、2024年3月からは指標が更新されました。

3つの指標で構成されます。

指標	意味	良好	要改善
LCP	最大コンテンツ描画	2.5秒以下	4秒超
INP	操作反応	200ms以下	500ms超
CLS	レイアウト安定性	0.1以下	0.25超

ここで重要なのは、Google は「3指標すべてが良好（Good）の URL」を理想としている点です。1つでも要改善（Needs Improvement）や不良（Poor）があると、そのページグループ全体が「Core Web Vitals 不良」として扱われます。 → 詳しくはGoogle Search Consoleの使い方｜初心者の最初の30分で計測手順を確認できます。

Core Web Vitals が SEO にどう効くか

Google 公式は「Core Web Vitals は数あるシグナルの 1 つで、コンテンツの関連性や品質を上回るものではない」と明言しています。一方で、ヘルプフルコンテンツアップデート以降、UX 全体の評価が強化されているのも事実です。つまり「コンテンツが拮抗したときの差別化要素」として CWV は無視できません。

シグナル区分	重要度	説明
コンテンツ関連性	最重要	クエリと内容のマッチ
E-E-A-T	高	経験・専門性・権威性・信頼性
被リンク・ページオーソリティ	高	外部からの参照
Core Web Vitals	中	UX シグナル群の 1 つ
HTTPS / モバイル対応	中	基礎的な体験要件

LCP（Largest Contentful Paint）の詳細

LCPは、ページ内で最も大きいコンテンツ（通常はメインビジュアルやヒーロー画像）が表示完了するまでの時間です。ユーザーが「読み始められる」と感じる瞬間を近似するための指標です。

LCP 要素として認識されるもの

LCP の対象になるのは次の要素です。

<img> 要素
<svg> 内の <image> 要素
<video> のポスター画像
CSS の background-image（url() で読み込まれるもの）
テキストノードを含むブロックレベル要素

つまり、ヒーローセクションに大きな写真があればそれが LCP 対象、写真がなければ大見出しのテキストが LCP 対象になることが多いです。Chrome DevTools の Performance タブで「LCP」ピンを確認すると、自分のページの LCP 要素が一目で分かります。

LCP を構成する 4 つのフェーズ

LCP は単に「画像が出るまで」ではなく、4 つのフェーズの合計時間です。これを理解すると、どこを直せばよいかが明確になります。

フェーズ	内容	典型的な改善策
TTFB（Time to First Byte）	サーバー応答	CDN、サーバー強化、キャッシュ
リソースロード遅延	画像読み込み開始までの待ち	preload、優先度ヒント
リソースロード時間	画像のダウンロード	WebP/AVIF、サイズ最適化
描画遅延	DOM 構築・レンダリング	CSS / JS のブロック解消

特に TTFB は LCP の 40% を占めることもあり、サーバー側のチューニングを軽視できません。 → 詳しくはサイトマップ・robots.txtの基礎と書き方でクローラビリティ全体の最適化も確認できます。

LCPを改善する方法

画像の最適化（WebP/AVIF形式、適切なサイズ）
画像のlazy-loading（ただしLCP要素はeager）
CDN利用
サーバー応答時間（TTFB）の改善
レンダリングブロッキングなJavaScript・CSSの除去
フォントの最適化（preload、font-display: swap）

ポイント: LCP要素の画像にはfetchpriority="high"を指定すると優先読み込みされます。

加えて、Next.js / Nuxt などのフレームワークでは <Image> コンポーネントが自動的に srcset を生成し、デバイスごとに最適なサイズを配信します。これだけで LCP が 1〜2 秒短縮するケースも珍しくありません。

LCP 悪化のよくあるアンチパターン

ヒーロー画像を loading="lazy" にしてしまい、表示が遅延する
巨大な未圧縮 PNG を背景画像で読み込む
同期的な外部スクリプト（広告 SDK・チャットツール）が <head> に複数並ぶ
フォントが描画ブロックして「白画面」が長引く
React の SSR を行わず、CSR でヒーロー画像 URL を後から決定する

INP（Interaction to Next Paint）の詳細

INPは、ユーザーがクリック・タップ・キー入力をしてから、画面が応答（描画更新）するまでの時間です。2024年3月にFID（First Input Delay）から置き換えられました。

INPはページ滞在中の全インタラクションを評価します。FIDが「最初の操作だけ」だったのに対し、INPは「最悪のケース」を見るので、より厳しい指標です。

FID から INP への移行（2024 年 3 月）

旧指標 FID は「最初の操作の入力遅延」だけを計測する設計で、現実のユーザー体験との乖離が大きいという批判がありました。INP はページ滞在中のすべての操作を見て、98 パーセンタイル（最も悪いインタラクション）を採用するため、ユーザーが体感する「重さ」をはるかに正確に反映します。

観点	FID（旧）	INP（新）
計測対象	最初の入力のみ	全インタラクション
計測内容	入力遅延のみ	入力遅延＋処理＋次の描画まで
良好値	100ms 以下	200ms 以下
採用統計	平均	98 パーセンタイル
移行時期	2024-03 廃止	2024-03 公式採用

INP は「処理時間」と「描画時間」も含むため、単に JavaScript を高速化するだけでは不十分で、レンダリング負荷（再描画されるノード数、CSS の複雑度）も意識する必要があります。 → 詳しくはSEO/LLMOの効果測定｜GSC・GA4・AIメンション計測で UX 指標の総合的な追い方を整理しています。

INPを改善する方法

JavaScriptの実行時間を短縮
メインスレッドのブロックを減らす（Web Workerの活用）
重いイベントハンドラの分割
不要なサードパーティスクリプトの削除
React/Vueなどのコンポーネント最適化

INP のフレームワーク別注意点

フレームワーク	典型的な悪化原因	対策
React	巨大な State 更新で再レンダリング	`useMemo`、`startTransition`、仮想化
Vue	watcher の連鎖発火	computed への切替、shallowRef
Svelte	過度なリアクティブ宣言	`$:` の最小化、ストア整理
jQuery	巨大な DOM 走査	セレクタキャッシュ、event delegation
静的サイト	サードパーティ JS の集中ロード	遅延読み込み、Partytown

特にタグマネージャ経由で 10 個以上のサードパーティタグを入れているサイトは、INP が 500ms を超える典型例です。月次でタグの棚卸しを行うだけで INP が劇的に改善することがあります。

CLS（Cumulative Layout Shift）の詳細

CLSは、ページ読み込み中に予期せぬレイアウト崩れがどれだけ起きたかの累積値です。「読もうとした瞬間に広告が割り込んでクリック誤爆」のような体験を防ぐための指標です。

CLS スコアの計算式

CLS は「影響範囲の割合 × 移動距離の割合」で求めた個々のシフトの累積です。たとえば画面の上半分（影響範囲 0.5）が 25%（移動距離 0.25）下にずれると、そのシフトは 0.5 × 0.25 = 0.125 となり、これだけで「不良（0.1 超）」に到達します。

実務上は「ファーストビュー（above the fold）」のシフトが致命傷になりがちです。広告枠、後から差し込まれるバナー、Web フォントの差し替えによるテキスト位置変動などが代表例です。

CLSを改善する方法

画像・iframe・動画にwidth/height属性を必ず指定
広告枠の高さを事前に確保
フォントの遅延読み込みを最適化（FOIT/FOUTの削減）
動的に挿入されるコンテンツは既存要素の上に配置しない

CLS の優先対応リスト

要素	推奨対応
メイン画像	`width` `height` または `aspect-ratio` を必ず指定
動的バナー	`min-height` で先にスペース確保
Web フォント	`font-display: swap` ＋ `size-adjust`
iframe（YouTube 等）	親要素にアスペクト比を CSS で固定
Cookie バナー	ページ上部に被せず、下部から表示

計測ツール

Core Web Vitalsの状態は次のツールで計測できます。

ツール	種類	用途
Search Console	実測値	サイト全体のページグループ別
PageSpeed Insights	両方	個別URLの詳細分析
Chrome DevTools	ラボ環境	開発中のチェック
CrUX Dashboard	実測値	過去28日のトレンド
Web Vitals Extension	実測値	リアルタイム測定

「ラボデータ」（理論値）と「フィールドデータ」（実ユーザーの値）の両方を見ることが重要です。Googleがランキングに使うのはフィールドデータです。

各ツールの使い分け早見表

シーン	最適ツール	理由
開発中の改善	Chrome DevTools / Lighthouse	即時に再計測できる
本番リリース直後の確認	PageSpeed Insights	Lab + Field を 1 画面で確認
サイト全体の傾向把握	Search Console	URL グループ別に Pass/Fail を表示
競合との比較	CrUX Dashboard	公開データで他サイトと並べられる
個別ユーザーの再現	Web Vitals Extension	ローカルで実数値を見られる

PageSpeed Insights のレポート上部には「実際のユーザー環境で評価」と「パフォーマンスの問題を診断」の 2 セクションが並びます。前者が Field data、後者が Lab data です。Field data に「データ不足」と表示される場合はトラフィックが少なく、CrUX のサンプルが集まっていない状態です。この場合、Lab data を改善しつつ、トラフィックが増えるのを待ちます。

Search Console の Core Web Vitals レポート

GSCの左メニュー「Experience > Core Web Vitals」から、モバイル / デスクトップそれぞれで「Poor URLs」「Need improvement」「Good URLs」が確認できます。Google は「URL グループ」（似た構造の URL 群）で集計するため、特定テンプレートが原因で全件不良になることがあります。 → 詳しくはGoogle Search Consoleの使い方｜初心者の最初の30分を参照。

フィールドデータと Lab データの違い

項目	Lab データ	フィールドデータ
計測方法	シミュレーション	実ユーザー（CrUX）
安定性	同条件なら毎回同値	日々変動
速度	即時	28 日ローリング
利用可能タイミング	公開前から	公開後一定トラフィック後
ランキング使用	されない	される
利用シーン	改善作業中	評価・順位判断

Lab で 90 点でもフィールドが不良、というのは典型パターンです。原因は「実機が遅い」「3G 回線」「広告 SDK が動的注入」などで、開発機では再現できません。Field のデータを定期的にウォッチする運用が前提です。

モバイルとデスクトップの戦略の違い

Google はモバイルファーストインデックスを完了済みで、モバイル版が評価の主軸です。Core Web Vitals もモバイルが最優先で見られます。

観点	モバイル	デスクトップ
LCP 目標	2.5 秒以下（厳しい）	2.5 秒以下（達成しやすい）
INP 目標	200ms 以下（CPU 弱い）	200ms 以下
CLS 目標	0.1 以下（広告影響大）	0.1 以下
主な悪化要因	通信回線、CPU 性能	サードパーティ JS
重視すべき改善	画像最適化、JS 削減	キャッシュ、CDN

モバイル端末は CPU が弱いため、INP が深刻になりやすい傾向があります。Pixel 5 などのミドルレンジ機を基準にチューニングするのがおすすめです。

業界別の Core Web Vitals 戦略

業界によって課題と対応の優先順位は異なります。

業界	主な悪化要因	優先改善
EC（ショップ）	商品画像、レビュー、レコメンド JS	LCP（画像）、CLS（レビュー枠）
メディア	広告、SNS 埋め込み、動画	CLS（広告）、INP（広告 JS）
SaaS LP	アニメーション、動画、フォーム	INP（フォーム）、LCP（ヒーロー動画）
BtoB コーポレート	高解像度写真、外部スクリプト	LCP（写真）、TTFB
ブログ	大量画像、AdSense	LCP、CLS（AdSense）
動画サイト	動画埋め込み、サムネ	LCP（サムネ）、CLS（プレイヤー）

EC では「商品ページのレビュー枠の高さが動的に変わる」ことで CLS が悪化するパターンが多く、min-height の事前指定が必須です。メディアでは AdSense の自動広告が CLS を破壊することがあるため、手動配置に切り替える運用も検討します。

失敗事例

実際に多く見るアンチパターンを紹介します。

失敗 1: 画像最適化を「圧縮」だけで済ませた

PNG を JPEG に変換して 70% 圧縮しただけで満足し、Retina 用の 2x 画像を全デバイスに配信していたケース。WebP 化と srcset で配信した結果、LCP が 4.2s → 1.8s に短縮しました。

失敗 2: タグマネージャに 30 個以上のタグを詰め込んだ

GTM に広告計測、ヒートマップ、A/B テスト、チャットボット、レコメンド、SNS ピクセルなど 30 件以上を投入。INP が 1,200ms に達し、コンバージョン率が 30% 低下しました。半分を削除し、Partytown で隔離した結果 INP は 280ms まで改善。

CLS が 0.45 を記録し、Search Console で全 URL が「不良」判定。手動配置に変更し、各広告枠に min-height を設定して 0.05 まで改善。

失敗 4: フォント最適化を後回し

3 種類の Web フォントを <link> で同期読み込みし、レンダリングがブロック。LCP が 5s 超。font-display: swap と preload で 2.3s に改善。

失敗 5: SPA のクライアント側ルーティング

React Router で完全 CSR の SPA にしたところ、初期 HTML がほぼ空で LCP が 4 秒以上。Next.js への移行（または SSR / SSG）で 1.5s に短縮。

改善ロードマップ

Core Web Vitals は一度直せば終わりではなく、継続的にモニタリングする必要があります。次のロードマップが目安です。

フェーズ	期間	やること
Phase 1: 計測基盤整備	1 週目	GSC・PSI・CrUX 接続、ベースライン取得
Phase 2: クイックウィン	2〜3 週目	画像 WebP 化、不要 JS 削除、フォント最適化
Phase 3: 構造改善	1〜2 ヶ月目	CDN 導入、SSR 化、サードパーティ整理
Phase 4: 高度最適化	2〜3 ヶ月目	Edge Functions、Partytown、Service Worker
Phase 5: 継続監視	4 ヶ月目以降	RUM 導入、月次レポート、アラート設定

最初の 2 ヶ月で「Good URLs 80% 以上」を目標にすると、現実的なゴール設定になります。

AI / LLMO への影響

LLMO（大規模言語モデル最適化）の観点でも、Core Web Vitals は無視できません。AI クローラー（GPTBot、ClaudeBot、PerplexityBot など）はレンダリングを行わずに HTML を取得するケースが多く、CSR 主体のサイトはコンテンツが拾われない可能性があります。

観点	従来 SEO	LLMO
クローラ種別	Googlebot 等	GPTBot、ClaudeBot、PerplexityBot
レンダリング	第二段階で行う	多くは行わない
重要要素	表示速度、UX	初期 HTML の充実度、構造化
影響 CWV 指標	LCP / INP / CLS	LCP（=初期HTML到達時間）に近い
補助手段	sitemap.xml	JSON-LD / 構造化データ

つまり SSR / SSG で初期 HTML を充実させることは、ユーザー体験 + LLMO の両方に効きます。 → 詳しくはSEO×LLMOハイブリッド戦略｜2026年の最適バランスで全体像を解説しています。

ツール一覧

実務で使うツールをカテゴリ別に整理します。

カテゴリ	ツール名	用途
計測（公式）	PageSpeed Insights	URL 単位の Lab + Field
計測（公式）	Lighthouse CI	CI 統合、回帰検知
計測（公式）	Chrome UX Report	フィールド実測
計測（公式）	Search Console	サイト全体集計
計測（OSS）	web-vitals JS	RUM 計測の基本
計測（OSS）	sitespeed.io	OSS 監視ダッシュボード
RUM SaaS	SpeedCurve	商用 RUM、競合比較
RUM SaaS	Calibre	商用 RUM、CI 連携
RUM SaaS	Datadog RWB	APM と統合
配信最適化	Cloudflare	CDN、画像最適化
配信最適化	Fastly	CDN、Edge Functions
画像最適化	imgix / Cloudinary	URL ベースの動的最適化
サードパーティ隔離	Partytown	重い JS を Web Worker に分離

Core Web Vitals の最適化フロー

LCP（Largest Contentful Paint）改善の手順

計測: PageSpeed Insights で実測値を確認
要因特定: Lighthouse の Performance タブで遅延要因を分解（サーバー応答 / リソースロード / レンダリング）
画像最適化: ヒーロー画像は WebP / AVIF 形式、<img loading="eager">、fetchpriority="high" を設定
フォント最適化: font-display: swap、preload で重要フォントを先読み
CDN導入: Cloudflare / Fastly などで静的資産を配信
再計測: 24時間後に Chrome UX Report で実ユーザーデータを確認

INP（Interaction to Next Paint）改善の手順

計測: web-vitals JS で本番計測
長いタスクの特定: Performance タブで 50ms 超の Main Thread タスクを抽出
JavaScript の分割: code splitting、lazy loading で初期ロードを減量
イベントハンドラの最適化: requestIdleCallback、requestAnimationFrame で重い処理を分散
サードパーティスクリプトの削減: 不要なタグマネージャ・チャットボットを削除

CLS（Cumulative Layout Shift）改善の手順

画像・動画に width/height 必須: アスペクト比保持で予約スペース確保
広告枠の予約: min-height で広告ロード前のサイズを固定
動的に挿入される要素: 既存コンテンツを押し下げない位置に配置
Web フォントの FOIT/FOUT 制御: size-adjust、font-display の調整

実機計測の重要性

PageSpeed Insights の Lab data（実験室）と Field data（実ユーザー）には大きな乖離が出ることがあります。Field data（Chrome UX Report ベース）が Google ランキングシグナルに使われます。

データ種別	使い道
Lab data (Lighthouse)	開発中の改善作業
Field data (CrUX)	ランキング判定の実値

CrUX データが「不良」のページは、Lab で良好でも検索順位に悪影響が出ます。

改善の優先順位

すべて完璧にする必要はありません。優先順位は次が一般的です。

CLSが0.25超 → 即対応（ユーザー離脱が多い）
LCPが4秒超 → 高優先度
INPが500ms超 → 高優先度
その他「要改善」レベル → 余力で対応

加えて、ビジネスインパクトが大きい URL（コンバージョンページ、トップ、主要 LP）から手を付けるのが鉄則です。月間 PV が少ないページを最適化しても全体スコアにはほとんど影響しないためです。

SEOへの影響

Googleは「Core Web Vitalsはランキング要素だが、コンテンツの関連性ほど強くはない」と公式発表しています。ただし、競合と内容が拮抗している場合は決定打になります。

また、Core Web Vitalsが悪いとユーザーの離脱率が上がり、間接的に直帰率やCTRに影響します。 → 詳しくはSEO/LLMOの効果測定｜GSC・GA4・AIメンション計測で計測方法を整理しています。

2026年のトレンド

2026年現在、注目されているのは次の点です。

INPがFIDの代替として完全定着
モバイル中心の評価がさらに強化
AIエージェントによる自動診断ツールの普及

将来的には新指標が追加される可能性もあるため、Google Search Centralブログを定期的にチェックしましょう。

2026年の Core Web Vitals 動向

web.dev の最新ガイドによれば、2024年3月に FID が INP に置き換わって以降、新指標の議論は継続中です。今後追加される可能性がある指標として TTI（Time to Interactive）の再採用 や Soft Navigation 計測 が議論されています。

UX 重視のアップデートは継続するため、「指標を満たす」ではなく「実ユーザー体験を改善する」発想が長期的に正解です。 → 詳しくはE-E-A-T解説｜経験・専門性・権威性・信頼性をどう示すかも合わせて押さえておくと、UX とコンテンツ品質の両輪を理解できます。

よくある質問

Q1. WordPressでCore Web Vitalsを改善するには？

A. 軽量テーマの選択、画像最適化プラグイン（WebP Express等）、キャッシュプラグイン（WP Rocket等）の導入が基本です。加えて、不要なプラグインを削減し、テーマの functions.php で読み込む CSS / JS を整理します。

Q2. ページ速度はランキング1位を取れる要因ですか？

A. 単独では難しいです。コンテンツの質・E-E-A-T・被リンクが土台で、Core Web Vitalsはその上の最適化要素です。ただし「コンテンツ拮抗時の差別化要素」として効きます。

Q3. PageSpeed Insightsとフィールドデータでスコアが違うのはなぜ？

A. ラボは理想環境、フィールドは実ユーザーの環境（端末・回線）で測定するためです。Googleが評価するのはフィールド値です。

Q4. LCPを2.5秒以下にできない場合、SEOに不利ですか？

A. 競合と比較して相対的に評価されるため、競合も遅ければ大きな差にはなりません。ただし改善努力は必要です。

Q5. CLS が突然悪化しました。どこから調査すべきですか？

A. まず Search Console の「対象 URL のサンプル」を確認し、共通テンプレートを特定します。次にその URL を Web Vitals Extension で開き、Layout Shift のリアルタイム検出を行います。広告 / Web フォント / 動的バナーが原因の 80% を占めるため、ここから疑います。

Q6. SPA で Core Web Vitals が悪い場合、SSR にすべき？

A. はい。特に LCP は SSR で劇的に改善します。Next.js / Nuxt / SvelteKit などのメタフレームワークを採用するか、最低でも上位ランディングページだけでも SSG（静的生成）に切り替えるのがおすすめです。 → 詳しくは検索エンジンの仕組み｜クローラーからインデックスまでで SSR と SEO の関係を解説しています。