Core Web Vitals改善ガイド｜LCP・INP・CLSの原因特定と優先順位付け

Search Consoleで「不良URL」が増えても、PageSpeed Insightsの提案を上から実施するだけでは、重要ページの改善につながるとは限りません。Core Web Vitals改善では、まず実際の利用者データで問題のある指標・端末・URL群を特定し、次にLCP・INP・CLSを内訳へ分解して原因を確認します。そのうえで「事業影響×対象URL数×改善余地÷実装負荷」で着手順を決めることが重要です。本記事では、企業のWeb・SEO・開発担当者が、測定から原因の切り分け、修正、公開後の検証までを一つの手順で進められるように整理します。

Core Web Vitals改善で最初に確認すべき結論

Core Web Vitalsは、個別の警告を手当たり次第に消すのではなく、次の順番で改善します。

Core Web Vitals改善で最初に確認すべき結論に関連して次に確認したい論点は、「重要専門用語特集！INDEX削除ってなんだ？」で詳しく解説しています。

実際の利用者データ（フィールドデータ）で、問題の指標・端末・URL群を特定する
PageSpeed InsightsやChrome DevToolsの検証データ（ラボデータ）で原因を再現する
LCP・INP・CLSを内訳へ分け、最も長い遅延や大きなずれを特定する
事業上重要なページテンプレートと、多数のURLへ共通する原因を優先する
修正前後を同じ条件で比較し、実際の利用者データで効果を確定する

Googleが示す「良好」の目安は、モバイルとパソコンを分け、ページ訪問の75パーセンタイル（遅い側から25%に当たる地点）でLCPが2.5秒以下、INPが200ミリ秒以下、CLSが0.1以下です。3指標すべてが基準内に入って初めて、そのURL群を良好と判断できます。

指標	測る体験	良好	改善が必要	不良
LCP	主な内容が表示される速さ	2.5秒以下	2.5秒超〜4.0秒以下	4.0秒超
INP	クリックや入力への応答	200ms以下	200ms超〜500ms以下	500ms超
CLS	表示中の予期しないずれ	0.1以下	0.1超〜0.25以下	0.25超

Core Web VitalsはGoogle検索のページエクスペリエンスを構成する要素ですが、良質なコンテンツとの関連性を置き換えるものではありません。SEOだけを目的に点数を追うのではなく、主要コンテンツを速く見せ、操作へすぐ反応し、誤タップを生む表示ずれをなくす取り組みとして扱うべきです。

診断ではフィールドデータとラボデータを使い分ける

最初の判定にはフィールドデータ、原因の再現と修正確認にはラボデータを使います。この順番を逆にすると、担当者の高速な端末では再現しない問題や、実際には利用者へ影響していない警告を優先するおそれがあります。

診断ではフィールドデータとラボデータを使い分けるの全体像や前提から確認したい場合は、「テクニカルSEOとは？クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チ」を参照してください。

フィールドデータで問題範囲を定め、ラボデータで原因を再現・切り分けます。

目的	主なツール	データの特徴	判断できること
サイト全体の問題把握	Search Console	Chrome利用者の集計データ	問題の指標、モバイル／パソコン、類似URL群
URLの実態確認	PageSpeed Insights上部	CrUXの実利用データ	URL単位またはオリジン単位の75パーセンタイル
原因の再現	PageSpeed Insights下部、Lighthouse	制御条件下の1回の検証	LCP要素、ブロック時間、レイアウトシフト候補
詳細な切り分け	Chrome DevTools Performance	操作・通信・描画の記録	長いタスク、通信順序、LCP内訳、ずれの発生時点
継続監視	自社RUM	自社ページの実利用データ	ページ種別、端末、国、操作別の悪化原因

CrUXはChrome User Experience Reportの略で、実際のChrome利用者から匿名で集計されたデータです。PageSpeed InsightsにURL単位のデータがない場合、サイト全体を表すオリジン単位のデータへ切り替わることがあります。画面上の対象が「このURL」か「オリジン」かを必ず確認してください。

また、Lighthouseは利用者の操作がない検証のため、INPを直接測定できません。開発中はTotal Blocking Time（TBT、メイン処理が長く塞がれた時間）を代理の診断材料にし、公開後はフィールドデータのINPで確認します。

Core Web Vitalsの原因を特定する7ステップ

原因特定は、サイト全体からURL群、個別ページ、指標の内訳へと段階的に絞ります。企業サイトでは1ページだけを直すより、同じテンプレートを使うURL群の共通原因を修正する方が、効果を広げやすくなります。

サイト全体から代表URL、指標の内訳、共通原因へ段階的に絞り込みます。

1. Search Consoleで問題の指標・端末・URL群を確認する

「ウェブに関する主な指標」レポートで、モバイルとパソコンを分けて確認します。不良URL数だけでなく、LCP・INP・CLSのどれが基準外か、どのURLが同じ問題グループに属するかを記録してください。

2. 代表URLをページテンプレートごとに選ぶ

トップページ、サービス、商品、カテゴリ、記事、問い合わせなど、構造が異なるテンプレートから代表URLを選びます。流入、問い合わせ、売上などの事業成果が大きいページを含めます。

3. PageSpeed Insightsでフィールドデータを確認する

問題の指標、75パーセンタイル値、対象がURLかオリジンかを記録します。モバイルだけが悪い場合は、低速回線、端末性能、レスポンシブ画像、モバイル専用部品などの条件を疑います。

4. ラボ環境で問題を再現する

Chrome DevToolsで端末性能とネットワークを抑制し、シークレットウィンドウなど拡張機能の影響が少ない条件で測ります。1回の数値で判断せず、同条件で複数回測り、中央値とばらつきを見ます。

5. 指標を内訳へ分解する

LCPならTTFB、リソース読み込み遅延、リソース読み込み時間、要素描画遅延に分けます。INPなら入力遅延、イベント処理時間、表示遅延に分けます。CLSは発生時刻、動いた要素、直前に追加・変更された要素を確認します。

LCP・INP・CLSを内訳へ分け、影響の大きい原因から修正します。

6. 共通原因とページ固有原因を分ける

共通ヘッダー、タグ管理、Cookie同意、Webフォント、CMSテンプレートなどは全体原因になりやすく、ヒーロー画像や商品ウィジェットはページ固有原因になりやすい要素です。同じテンプレートの複数URLで再現するかを確認します。

7. 修正仮説と合格条件をチケットへ記録する

「画像を圧縮する」ではなく、「記事テンプレートのLCP画像を初期HTMLから発見可能にし、遅延読み込みを外す。ラボ条件のLCP中央値を3.4秒から2.5秒以下へ短縮する」のように、対象、原因、変更、判定値を明記します。

LCPが遅い原因は4つの時間へ分けて診断する

LCPは「画像が重い」と決めつけず、合計時間を4つへ分解します。画像を圧縮しても、JavaScriptが画像の表示を待たせていれば、短縮分が要素描画遅延へ移るだけで、LCP全体が改善しない場合があります。

内訳	確認する現象	主な原因	優先対策
TTFB	HTMLの最初の応答が遅い	多段リダイレクト、サーバー処理、キャッシュ不足、距離	CDN、HTMLキャッシュ、DB・バックエンド改善、リダイレクト削減
リソース読み込み遅延	HTML到着後もLCP画像の取得が始まらない	CSS背景、JavaScript挿入、遅延読み込み、優先度不足	初期HTMLのimgで指定、preload、fetchpriority=”high”、lazy-load解除
リソース読み込み時間	LCP画像やフォントの転送が長い	大きすぎる画像、形式・寸法の不適合、低速配信	AVIF／WebP、srcsetとsizes、圧縮、CDN、キャッシュ
要素描画遅延	取得後も画面に表示されない	レンダリングを妨げるCSS・JavaScript、クライアント描画、非表示処理	重要CSSの優先、不要JSの遅延、サーバー側HTML、表示待ち処理の削減

LCP要素が画像なら、初期HTMLにsrcまたはsrcsetが存在するか、loading=”lazy”が付いていないかを最初に確認します。CSS背景画像など初期HTMLから発見できない場合はpreloadを検討します。ただし、無差別なpreloadは帯域を奪うため、最初の画面でLCPとなる資源に限定してください。

LCP要素がテキストなら、フォントと表示を妨げるCSSを確認します。サーバー応答が遅いページでは、フロントエンドの微調整よりTTFBの改善が先です。

INPが遅い原因は操作前・処理中・描画前へ分けて診断する

INPは、ページ滞在中に行われたクリック、タップ、キーボード入力などの応答性を示します。遅い操作を特定し、入力遅延、イベント処理、次の画面表示までの3区間のどこで時間を使ったかを確認します。

遅延区間	主な原因	診断方法	主な対策
入力遅延	別の長いJavaScript処理がメインスレッドを占有	Performance記録で操作前の長いタスクを確認	不要JS削除、コード分割、第三者タグの遅延、長いタスクの分割
イベント処理	クリック処理内の計算・DOM更新が重い	イベントコールバックの実行時間を確認	必須処理だけ先に実行、残りを次タスクへ回す、処理量削減
表示遅延	大きなDOM、強制的なレイアウト再計算、複雑な描画	Recalculate Style、Layout、Paintを確認	DOM縮小、読み書きの整理、画面外要素の描画抑制

優先して調べる操作は、メニュー開閉、検索候補、フォーム入力、タブ切り替え、絞り込み、カート追加など、利用頻度または事業価値が高いものです。分析・広告・チャット・A/Bテストなど第三者スクリプトは、主処理とメインスレッドを奪い合うため、用途、所有者、読み込み時期、削除可否を一覧化します。

長い処理を分割する際は、画面の見た目を変える必須処理を先に終え、分析送信や補助計算などを後続タスクへ回します。単にasyncやdeferを付けるだけでは、実行時の長い処理は残るため、Performance記録で再確認が必要です。

CLSが大きい原因は「動いた要素」ではなく「動かした要素」を探す

CLSの診断では、紫色などで示された移動要素そのものが原因とは限りません。その上に画像、広告、バナーなどが後から挿入され、結果として下の文章が動いている場合があります。発生直前のDOM変更と、あらかじめ場所が確保されていたかを確認します。

主な対策は次のとおりです。

画像と動画にwidth、heightまたはCSSのaspect-ratioを指定する
広告、埋め込み、iframe、レコメンド枠に最小高または固定比率の枠を確保する
Cookie通知やキャンペーン帯を後から本文上部へ挿入しない
Webフォントと代替フォントの字幅・高さを近づけ、必要なフォントだけを早く取得する
アニメーションは周囲のレイアウトを再計算しにくいtransformを優先する

Lighthouseが示す読み込み時のCLSと、フィールドデータのCLSに大きな差がある場合は、スクロール後の遅延コンテンツ、メニュー操作、SPAの画面遷移など、読み込み後のずれを疑います。DevToolsのLive metricsを表示したまま代表操作を一通り実行すると、発生条件を絞り込めます。

改善の優先順位は「指標の赤さ」だけで決めない

優先順位は、基準超過の大きさに加えて、事業影響、対象URL数、共通部品かどうか、実装負荷、変更リスクで決めます。小さな数値改善でも重要な申込ページへ広く効く修正は、非常に悪い低流入ページより先になる場合があります。

次の5項目を各1〜5点で採点すると、部署間で着手理由を共有しやすくなります。

評価軸	1点	3点	5点
事業影響	低流入・補助ページ	中程度の流入や回遊	売上・問い合わせ・主要流入へ直結
影響URL数	単一URL	一部カテゴリ	共通テンプレートで多数URL
基準超過・改善余地	良好に近い	改善が必要	不良で差が大きい
実装容易性	大改修・外部依存	複数部署調整	小変更で検証可能
変更リスク	売上機能へ高リスク	ロールバック可能	表示・機能への影響が小さい

改善候補を5つの評価軸で採点し、修正の優先順位へ変換します。

簡易的には「事業影響＋影響URL数＋改善余地＋実装容易性＋低リスク性」の合計で並べます。同点なら、複数指標へ効く共通原因を優先します。例えば、重い第三者スクリプトの整理はLCPとINP、画像寸法とLCP画像の読み込み設計はLCPとCLSへ同時に効く可能性があります。

実務上は、次の順番が候補になります。

重要テンプレート全体に効く、低リスクな共通修正
「不良」から「改善が必要」または「良好」へ移せる大きな原因
LCPとINPなど複数指標を悪化させる第三者処理や描画設計
重要ページ固有の大きな原因
低流入ページの軽微な超過や、効果が読めない大改修

修正後はラボ・RUM・Search Consoleの3段階で検証する

実装直後の合否をSearch Consoleだけで判断してはいけません。ラボで回帰を防ぎ、自社RUMで実利用への効果を早期確認し、最後にCrUXを基にするSearch Consoleで傾向を確定します。

実装直後のラボ確認、公開後のRUM、Search Consoleの順で効果を検証します。

検証時は、次を揃えます。

修正前後で同じURL、端末、回線、ログイン状態、Cookie状態を使う
単発値ではなく複数回の中央値とばらつきを比べる
対象指標だけでなく、別指標の悪化や機能不具合も確認する
RUMではページテンプレート、端末、国、接続条件、リリース版で分ける
Search Consoleでは該当問題の「修正を検証」を開始し、URL群の推移を確認する

CrUXは直近28日間のデータを集計するため、公開直後に数値が全面的に切り替わるわけではありません。改善リリース日を記録し、その前後を自社RUMで比較できるようにすると、Search Consoleの反映待ちでも次の判断ができます。

企業で運用するCore Web Vitalsチェックリスト

Core Web Vitalsは一度直して終わりではありません。CMS改修、タグ追加、広告、フォント、キャンペーン部品によって再び悪化するため、リリース工程へ性能基準を組み込みます。

☐ Search Consoleでモバイル／パソコン別に問題URL群を確認した
☐ 重要なページテンプレートごとに代表URLを選んだ
☐ PageSpeed Insightsのデータ対象がURLかオリジンか確認した
☐ LCPを4つ、INPを3つの内訳へ分解した
☐ CLSで「動かした要素」まで特定した
☐ 共通原因とページ固有原因を分けた
☐ 事業影響、URL数、改善余地、負荷、リスクで優先順位を付けた
☐ チケットに修正仮説と数値の合格条件を記載した
☐ 実装前後を同条件のラボデータで比較した
☐ 公開後にRUMとSearch Consoleで効果を確認した
☐ 新規タグやテンプレート変更時の性能確認をリリース条件へ入れた

まとめ

Core Web Vitals改善の要点は、LCP・INP・CLSの一般的な対策を並べることではなく、自社サイトの実データから原因と着手順を決めることです。Search ConsoleとPageSpeed Insightsのフィールドデータで問題範囲を定め、DevToolsでLCPの4区間、INPの3区間、CLSの発生要因を切り分けます。その後、事業影響と対象URL数が大きく、改善余地があり、低負荷・低リスクの共通修正から実装してください。

まずはSearch Consoleから、不良または改善が必要なURL群を一つ選び、代表URLと共通テンプレートを特定します。自社だけで再現・切り分けが難しい場合は、フィールドデータの設計、第三者タグ、フロントエンド、配信基盤を横断して診断できる体制を整えることが次の行動です。

参考文献・データ元

この記事で参照した情報を確認できます。

「Core Web Vitals と Google 検索の検索結果について」Google Search Central、最終更新2025年12月18日。指標の意味、推奨値、検索との関係に使用。https://developers.google.com/search/docs/appearance/core-web-vitals?hl=ja
「Web Vitals」web.dev、最終更新2024年10月31日。75パーセンタイル、フィールド／ラボ測定、RUM、LighthouseとINPの関係に使用。https://web.dev/articles/vitals
「Optimize Largest Contentful Paint」web.dev、最終更新2025年3月31日。LCPの4区間、診断方法、資源発見と読み込み優先度に使用。https://web.dev/articles/optimize-lcp
「Optimize Interaction to Next Paint」web.dev。INPの3区間、長いタスク、イベント処理、DOM・描画の改善に使用。https://web.dev/articles/optimize-inp
「Optimize Cumulative Layout Shift」web.dev。CLSの原因、読み込み後のずれ、画像寸法と領域確保に使用。https://web.dev/articles/optimize-cls
「Core Web Vitals レポート」Google Search Console ヘルプ。URLグループ、28日間の利用データ、修正検証に使用。https://support.google.com/webmasters/answer/9205520?hl=ja

‹ 親記事: テクニカルSEOとは？クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト

Core Web Vitals改善ガイド｜LCP・INP・CLSの原因特定と優先順位付け

Core Web Vitals改善で最初に確認すべき結論

診断ではフィールドデータとラボデータを使い分ける