検索ブランド相談室 | 検索と評判の専門メディア
無料相談

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

部署：マーケティング担当者レベル：実践SEO 公開日 2026.08.23　更新日 2026.10.17

監修: 菊地 将（リブランディング株式会社）

不良URLの一覧を前にすると、警告を上から順に消したくなります。しかし、担当者の端末では再現しない問題や、実際の利用者には影響していない警告に時間を使うと、重要ページの改善につながらないおそれがあります。

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

Core Web Vitals改善の進め方と「良好」の基準

Core Web Vitalsは、個別の警告を手当たり次第に消すのではなく、次の順番で改善します。順番を決めておくと、原因を取り違えたまま修正することも、効果を誤って判断することも防ぎやすくなります。

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

最初の3つで問題の場所と原因を絞り、4つ目で着手順を決め、最後の1つで効果を確かめます。

この流れで「問題がある」と判断する基準が、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だけを目的に点数を追うのではなく、主要コンテンツを速く見せ、操作へすぐ反応し、誤タップを生む表示ずれをなくす取り組みとして扱いましょう。

関連する論点として、「INDEX削除（インデックス削除）とは？検索結果から消える仕組みと対処法」もあわせて確認してください。

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

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

n 0017 article visual 2

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

次の表は、目的ごとに使うツールと、そのデータで判断できることを並べたものです。

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

上の2行は「どこが悪いか」を見るもの、中の2行は「なぜ悪いか」を探るもの、最後の行は悪化が続いていないかを見張るものです。この自社RUM（Real User Monitoring）は、自社のページで実際の利用者の体験を計測する仕組みです。

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

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

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

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

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

n 0017 article visual 3

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

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

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

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

問題のURL群が分かったら、調べる対象を絞ります。トップページ、サービス、商品、カテゴリ、記事、問い合わせなど、構造が異なるテンプレートから代表URLを選びます。流入、問い合わせ、売上などの事業成果が大きいページは、含めてください。

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

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

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

実利用データで見えた問題を、手元で再現できるかを確かめます。Chrome DevToolsで端末性能とネットワークを抑制し、シークレットウィンドウなど拡張機能の影響が少ない条件で測りましょう。1回の数値で判断せず、同条件で複数回測り、中央値とばらつきを見ます。

5. LCP・INP・CLSを内訳へ分解する

再現できたら、指標ごとに時間の使われ方を分けます。見る内訳は指標によって異なります。

  • LCP：TTFB（HTMLの最初の応答が届くまでの時間）、リソース読み込み遅延、リソース読み込み時間、要素描画遅延の4つに分ける
  • INP：入力遅延、イベント処理、表示遅延の3つに分ける
  • CLS：発生時刻、動いた要素、直前に追加・変更された要素を確認する

LCPとINPの内訳ごとの原因と対策は、後続の2つの節で詳しく扱います。

n 0017 article visual 4

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

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

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

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

最後に、修正の依頼内容を具体的に書き残します。「画像を圧縮する」ではなく、「記事テンプレートのLCP画像を初期HTMLから発見可能にし、遅延読み込みを外す。ラボ条件のLCP中央値を3.4秒から2.5秒以下へ短縮する」のように、対象、原因、変更、判定値を明記します。合格条件が数値で決まっていれば、修正後に効果を判断できます。

LCPが遅いときは、4つの時間へ分けて原因を探す

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

次の表は、4つの内訳ごとに、確認する現象、主な原因、優先する対策を対応させたものです。

内訳確認する現象主な原因優先対策
TTFBHTMLの最初の応答が遅い多段リダイレクト、サーバー処理、キャッシュ不足、距離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要素の種類に応じて最初の確認先を決めます。LCP要素が画像なら、初期HTMLにsrcまたはsrcsetが存在するか、loading="lazy"が付いていないかを最初に確認します。CSS背景画像など初期HTMLから発見できない場合はpreloadを検討します。ただし、無差別なpreloadは帯域を奪うため、最初の画面でLCPとなる資源に限定してください。

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

INPが遅いときは、入力遅延・イベント処理・表示遅延の3区間へ分けて原因を探す

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

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を表示したまま代表操作を一通り実行すると、発生条件を絞り込めます。

改善の優先順位は、指標の悪さに事業影響などを加えた5つの評価軸で決める

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

冒頭で示した着手順の考え方は、実務では次の5項目を各1〜5点で採点すると扱いやすくなり、部署間で着手理由も共有しやすくなります。冒頭の式の「実装負荷」は、表では「実装容易性」と「変更リスク」の2項目に分けて点数にします。

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

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

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

実務上は、次の順番が候補になります。上にあるものほど優先度が高い目安です。

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

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

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

n 0017 article visual 6

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

検証時の確認事項は、次の5つです。

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

Search Consoleを最後に置くのは、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と共通テンプレートを特定することです。自社だけで再現・切り分けが難しい場合は、フィールドデータの設計、第三者タグ、フロントエンド、配信基盤を横断して診断できる体制を整えることが次の行動です。

参考文献・データ元

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

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

関連記事

関連テーマ

AIO MEO 口コミ・風評対策 採用改善 オウンドメディア集客

関連記事