Core Web Vitals 改善とは？LCP・INP・CLSの手順・失敗例・KPIを徹底解説

Core Web Vitalsとは、GoogleがSEOのランキング要因に組み込んだユーザー体験を数値化した3つの指標（LCP・INP・CLS）のことです。

「PageSpeed InsightsでスコアをあげたのにSearch Consoleで改善が反映されない」「どの指標から手をつければいいかわからない」という声は、SEO担当者から非常によく届きます。Core Web Vitalsはスコアを追うより「実ユーザーのフィールドデータ」を改善することが本質であり、そこを理解せずに施策を重ねてしまうのが最大の落とし穴です。

この記事では、LCP・INP・CLSの定義と「Good」の閾値、PageSpeed Insightsを使った原因特定の手順、原因別の改善策、よくある失敗例、そして実務で使えるチェックリストまでを体系的に解説します。読み終えた時点で、どの指標を・どの順番で・何の施策で改善するかを自分で判断できるようになることを目標にしています。

Core Web Vitalsとは？3指標の定義と「Good」の閾値

Core Web Vitalsは、Googleが2021年6月から正式にSEO順位要因（ページエクスペリエンスシグナル）に組み込んだ3つのパフォーマンス指標です。「実際のユーザーが体感する速度・応答性・視覚的安定性」を計測する点が、従来の技術的な速度指標と異なる最大の特徴です（参照日: 2026年7月28日：Google検索 スターターガイド）。

LCP（Largest Contentful Paint）：表示速度

ページのメインコンテンツ（最も大きな画像やテキストブロック）が画面に描画されるまでの時間です。

• Good：2.5秒以内
• 要改善：2.5〜4.0秒
• Poor：4.0秒超

INP（Interaction to Next Paint）：応答性

2024年3月にFID（First Input Delay）の後継として正式採用された指標です。ページ滞在中のすべてのクリック・タップ・キーボード操作に対する応答時間のうち、最も遅いものを代表値として使います。

• Good：200ms以内
• 要改善：200〜500ms
• Poor：500ms超

CLS（Cumulative Layout Shift）：視覚的安定性

ページ読み込み中に要素が予期せず動く量を計測します。読んでいた文字が突然ずれる、押そうとしたボタンが動くといった体験がCLSのスコアに直結します。

• Good：0.1以下
• 要改善：0.1〜0.25
• Poor：0.25超

Core Web VitalsとPageSpeedスコアの違い：比較表

よく混同されるのが「PageSpeed Insightsのスコア（0〜100点）」と「Core Web Vitalsのフィールドデータ評価」です。両者は別の概念であり、目的も使い方も異なります。

項目	PageSpeed Insightsスコア	Core Web Vitals（フィールドデータ）
計測環境	ラボ環境（仮想マシン）	実ユーザーのブラウザ
SEO順位への影響	直接影響しない	順位要因に含まれる
確認場所	PageSpeed Insights上部の「診断」	Search Console・PageSpeed Insights下部
用途	問題の仮説立案・改善前後の比較	実際のユーザー体験の評価・改善確認
反映速度	即時	28日間の集計後（遅延あり）
データ量	1回の計測	直近28日間の実ユーザーデータ

実務上は「ラボデータで問題を特定・施策を実行 → フィールドデータで結果を確認」という流れが基本です。ラボスコア100点を取っても、実ユーザーデータが改善しなければSEO上の意味は薄いと理解してください。

PageSpeed InsightsとSearch Consoleでの原因特定手順

改善の第一歩は「どの指標が・どのページで・なぜ悪化しているか」を特定することです。以下の順番で確認します。

Step 1：Search ConsoleでサイトレベルのCore Web Vitalsを確認する

1. Search Console（search.google.com/search-console）にログイン
2. 左メニューの「エクスペリエンス」→「Core Web Vitals」をクリック
3. 「モバイル」と「PC」でそれぞれ「Poor URL」「要改善URL」の数を確認
4. 「レポートを開く」でURL一覧を取得し、影響の大きいページを特定する

Step 2：PageSpeed InsightsでページレベルのLCP・INP・CLSを確認する

1. PageSpeed Insights（pagespeed.web.dev）にURLを入力して計測
2. 上部のフィールドデータ（Chrome UXレポート）を最初に確認し、Poor/要改善の指標を把握
3. 「診断」セクションで各指標の原因候補を確認（例：「LCPを遅延させているリソース」「CLSを引き起こす要素」）
4. 「改善の機会」セクションに表示される施策候補のスコア上昇予測を参考に優先度を決める

Step 3：Chrome DevToolsで詳細な原因を特定する

• F12でDevToolsを開き、「Lighthouse」タブで再計測（モバイル設定を推奨）
• 「Performance」タブで「Main Thread」の処理時間を確認（INP改善に有効）
• 「Rendering」パネルで「Layout Shift Regions」を有効にするとCLS発生箇所が可視化される

LCP改善の手順：画像・サーバー・レンダーブロッキング別の対策

LCPが遅い原因は「何がLCP要素か」によって異なります。まずPageSpeed Insightsの「LCP要素」に表示されているHTMLタグを確認してください。

LCP要素が画像の場合

• 画像をWebP・AVIF形式に変換してファイルサイズを削減する
• fetchpriority="high"属性を付与して優先読み込みを指示する
• loading="eager"を明示し、lazy loadingを除外する
• <link rel="preload" as="image">をHTMLのheadに追加する
• srcsetとsizesを使ってデバイスに合ったサイズを配信する

LCP要素がテキストブロックの場合

• Webフォントの読み込みが遅延していないか確認する
• font-display: swapを設定してフォント読み込み中もテキストを表示する
• <link rel="preload" as="font">で必要なフォントファイルを事前読み込みする

TTFB（サーバー応答時間）が長い場合

LCP要素が画像でもテキストでも、サーバーの初期応答が遅いとLCPは改善しません。

• CDN（コンテンツデリバリーネットワーク）の導入・設定を見直す
• サーバーサイドキャッシュを有効にする（WordPressならW3 Total Cacheなど）
• 共有ホスティングから専用・VPSへの移行を検討する

レンダーブロッキングリソースがある場合

• headタグ内のCSSとJSのうち、初期描画に不要なものをdeferまたはasyncで後回しにする
• クリティカルCSSをインライン化して最初のレンダリングを早める

INP・CLS改善の手順と原因別の対策

INP改善：JavaScriptの処理量削減が基本

INPが悪い原因のほとんどはJavaScriptのメインスレッド占有です。以下の順番で対処します。

1. Chrome DevToolsのPerformanceタブで「Long Tasks」（50ms以上の処理）を特定する
2. 不要なサードパーティスクリプト（トラッキング・チャットウィジェット・広告タグ）を棚卸しして削除または遅延読み込みにする
3. JavaScriptバンドルサイズを削減する（tree shaking・コード分割を適用）
4. イベントリスナーの処理を軽量化し、重い計算はWeb Workerへ移行する
5. React・Vue・Angularなどのフレームワークを使っている場合は、不要な再レンダリングを防ぐ最適化を行う

CLS改善：レイアウトシフト原因別の対策

原因	対策
画像にサイズ指定がない	width・height属性を全画像に設定する
Webフォントの切り替え	font-display: swapとサイズ調整CSSを使う
広告・バナーの遅延挿入	表示エリアをmin-heightで事前確保する
A/Bテストツールの動的DOM変更	ファーストビュー外での適用に変更するか、ツールを再設計する
iframeの遅延読み込み	aspect-ratio CSSでコンテナのサイズを事前に確保する
サードパーティウィジェット	読み込み完了前にスペースを確保するCSSを追加する

なお、SEOの観点からは、E-E-A-Tを高める施策とCore Web Vitalsの改善を並行して進めることで、技術面と内容面の両軸からSearch Consoleのパフォーマンスを底上げできます。

管理画面で確認するCore Web Vitalsモニタリングの手順

改善施策を打った後は、定期的なモニタリングが不可欠です。確認すべき画面と項目を順番に示します。

Google Search Console：Core Web Vitalsレポート

1. 「エクスペリエンス」→「Core Web Vitals」を開く
2. 「モバイル」と「PC」をそれぞれ確認（モバイルを優先）
3. 「Poor URL数」と「Good URL数」の推移グラフを確認
4. 「レポートを開く」でURLグループ別に「LCP」「INP」「CLS」のいずれが問題かを特定
5. 影響URLをクリックして「同じURLグループの例」でサンプルページを取得

PageSpeed Insights：施策前後の比較

• 施策実施前のスコアとフィールドデータをスクリーンショット等で記録しておく
• 施策後に同じURLで再計測し、ラボデータの変化を確認
• フィールドデータの変化はSearch Console反映まで最低28日かかるため、ラボデータを中間確認の代替として使う

初期設定で間違えやすい項目

• Search Consoleのプロパティが「ドメインプロパティ」か「URLプレフィックスプロパティ」かによって表示URLが異なるため、実際のトラフィックURLと一致しているか確認する
• 「インデックス未登録のURL」はCore Web Vitalsレポートに表示されないため、インデックス状況も同時に確認する

変更後に見るべきKPI

• Good URL比率（全URLのうち「Good」が占める割合）
• Poor URL数の絶対数の減少
• Search Consoleの「インプレッション数」と「平均掲載順位」の変化（Core Web Vitals改善後1〜3ヶ月でトレンド変化を確認）

Core Web Vitals改善でよくある失敗例と対策

実務の相談で頻繁に登場する失敗パターンを整理します。

失敗例1：ラボスコアを上げることが目的化する

PageSpeed Insightsのスコア（0〜100点）を100点にすることに注力し、フィールドデータが改善しないまま施策を終了するケースです。ラボデータはあくまでも仮説検証ツールです。Search ConsoleのCore Web VitalsレポートのGood URL比率が改善しているかを最終的な判断基準にしてください。

失敗例2：全ページに同じ施策を適用する

サイト全体でCLSが悪いからといって、一律に全ページのCSSを変更したところ、別のページで表示崩れが発生するケースです。Search ConsoleのCore Web Vitalsレポートは「URLグループ」単位で問題を特定できるため、影響が大きいページを絞り込んでから施策を適用することを推奨します。

失敗例3：改善後の確認を28日待たずに別の施策を重ねる

施策を複数並行して実施すると、どの施策が効いたか（または悪化させたか）の切り分けができなくなります。施策は1つずつ実施し、最低28日間の計測期間を設けてから次に進む習慣が重要です。

失敗例4：モバイルを後回しにする

Googleのランキングはモバイルファーストインデックスが基本であり、Core Web VitalsもモバイルのフィールドデータがSEOに影響します。PCのスコアだけを改善しても効果が出にくいため、モバイルを優先して診断・改善してください。

失敗例5：サードパーティスクリプトを見落とす

GTM経由で配信されるスクリプトの影響を把握せずに施策を進め、CLSやINPが改善しないケースは非常に多いです。PageSpeed Insightsの「サードパーティコードの影響を制限する」セクションにサードパーティが表示されている場合は、必ず棚卸しを行ってください。

Webパフォーマンスの改善はSEOだけでなくランディングページのCVR改善にも直結します。表示速度が1秒改善するだけでコンバージョン率が変化するケースは多く、技術施策とビジネス指標をセットで評価することが重要です。

実務チェックリストと改善後のKPI設定

Core Web Vitals改善 実務チェックリスト

• ☐ Search ConsoleのCore Web VitalsレポートでPoor URLを特定したか
• ☐ モバイルと PCそれぞれのフィールドデータを確認したか
• ☐ PageSpeed InsightsでLCP要素・INP原因・CLS要素を特定したか
• ☐ LCP要素の画像にfetchpriority="high"を設定し、不要なlazy loadingを除外したか
• ☐ 全画像にwidth・height属性を付与したか（CLS対策）
• ☐ Webフォントにfont-display: swapを設定したか
• ☐ 不要なサードパーティスクリプトを棚卸しして削除・遅延化したか
• ☐ CDNまたはサーバーキャッシュを設定してTTFBを短縮したか
• ☐ レンダーブロッキングなCSSとJSをdefer/asyncまたはインライン化で対処したか
• ☐ 施策実施前のラボデータとフィールドデータを記録したか
• ☐ 施策後28日間のSearch Console推移を追う計画を立てたか
• ☐ 改善後のGood URL比率・インプレッション・平均順位の変化を計測しているか

改善指標とKPIの見方

KPI	確認場所	目標の考え方
Good URL比率（LCP）	Search Console → Core Web Vitals	サイト全体の75%以上をGoodにすることを目標とする
Good URL比率（INP・CLS）	同上	同様に75%以上が目安（Googleはp75での評価）
平均掲載順位	Search Console → 検索パフォーマンス	改善1〜3ヶ月後に対象ページの順位変化を確認
クリック率（CTR）	Search Console → 検索パフォーマンス	順位改善後にCTRが追随しているか確認
直帰率・滞在時間	GA4 → エンゲージメント	ページ速度改善後にユーザー行動指標が改善しているか確認

GoogleのHelpful Contentガイドラインでも強調されているように、ページ体験はコンテンツの質と組み合わせて評価されます（参照日: 2026年7月28日：役立つコンテンツの作成）。Core Web Vitalsの改善だけに集中せず、トピッククラスター構造による内部リンク設計と並行して進めることでSEO効果が高まります。

また、ページのパフォーマンス計測に加えて、ウェブサイト全体の検索戦略を整理したい場合はThink with Googleのリソースも参考になります（参照日: 2026年7月28日）。

なお、SNS流入との掛け合わせで成果を見たい場合、例えばInstagramリールのアナリティクス活用のように流入元ごとにユーザー行動を分析することで、ページ改善の効果をより正確に評価できます。

実務ケース別の設計例

ECサイトのLCP改善：商品画像の遅延読み込みが逆効果になったケース

前提条件：商品一覧ページが多数あるECサイト。モバイルのPageSpeed InsightsスコアはLCPが4.2秒（要改善）でフィールドデータでも「Poor URL」が多数。

よくある相談パターン：「画像にloading='lazy'を全部つけたがLCPが悪化した」というご相談です。LCP要素（ファーストビューの主画像）に対してlazy loadingを適用すると、ブラウザがその画像の読み込みを後回しにするためLCPが悪化します。LCP要素にはfetchpriority="high"とloading="eager"を明示し、スクロールしなければ見えない画像だけにlazy loadingを使うのが正しい設計です。

推奨する設計：ファーストビューの商品メイン画像をWebP形式・適切なサイズにリサイズしたうえでfetchpriority="high"を付与。2枚目以降にlazy loadingを設定。さらにLinkヘッダーでプリロードを宣言する。

見るべきKPI：Google Search ConsoleのCore Web Vitalsレポートで「LCP：Good URL」の割合（改善前後28日比較）。PageSpeed InsightsのLCP要素の変化。

失敗しやすい点：スコアがすぐに上がらないことを懸念して別の施策を重ねがちですが、Search Consoleへの反映は数週間かかります。「ラボデータが改善したこと」を確認してから28日間待つ姿勢が重要です。

コーポレートサイトのCLS改善：広告タグとA/Bテストツールが原因のレイアウトシフト

前提条件：コーポレートサイトのTOPページ。CLSが0.25（Poor）。開発チームは「画像にwidth/heightは全部ある」と言うが改善しない状況。

よくある相談パターン：「構造上CLSの原因が見つからない」というご相談。この場合、サードパーティスクリプトが疑われます。Google Tag Manager経由で配信されるA/Bテストツール・チャットウィジェット・広告タグがDOM要素を後から挿入することで、既存コンテンツが押し下げられCLSが発生します。

推奨する設計：Chrome DevToolsのPerformanceパネルでレイアウトシフトが発生したタイミングとスクリプトのロードタイミングを照合する。原因スクリプトを特定したら、該当ウィジェットの表示領域をCSSで事前確保（min-heightを設定）するか、スクリプトの読み込み順を変更して回避する。

見るべきKPI：PageSpeed Insightsの「CLSの問題のある要素」表示と、Search ConsoleのCLS URLレポートの推移。

失敗しやすい点：GTMタグを整理せず「とりあえずCSSで余白を確保」しても、スクリプトの挙動が変わると再発します。根本原因の特定と不要タグの棚卸しをセットで行うことが重要です。

ブログメディアのINP改善：コメント欄とソーシャル埋め込みによる応答遅延

前提条件：記事数1,000本超のオウンドメディア。モバイルのINPが380ms（Poor）。ページ下部にコメントフォームとSNS埋め込みウィジェットがある。

よくある相談パターン：「ページを軽くしたつもりなのにINPが改善しない」というケースです。INPはページ全体の応答遅延を計測するため、ページ下部に重いJavaScriptが存在するだけで悪化します。

推奨する設計：SNS埋め込みウィジェット（X・Instagramの埋め込みなど）をIntersection Observerを使った遅延読み込みに変更する。コメントフォームは初期DOMから外し、ユーザーがスクロールしたタイミングで動的に挿入する。メインスレッドを占有する処理をWeb Workerへ移行できるか検討する。

見るべきKPI：Chrome UXレポート（CrUX）のINP分布と、Search ConsoleのINP URLレポート。改善後はユーザーインタラクションの種類別（クリック・キーボード・タップ）に遅延がないかRUM（リアルユーザーモニタリング）ツールで確認するのが理想です。

失敗しやすい点：「ラボデータでINPが計測されない」ことがあります。INPは実際のユーザー操作を必要とするため、自動計測ツールでは再現しにくい場合があります。手動でページを操作しながらDevToolsのINP計測を行い、原因を特定してください。

よくある質問

Core Web Vitalsとは何ですか？

Core Web Vitalsとは、Googleがユーザー体験を数値化してSEO順位要因に組み込んだ3つの指標（LCP・INP・CLS）のことです。LCPはページの主要コンテンツの表示速度、INPはユーザー操作への応答速度、CLSはレイアウトの視覚的安定性を計測します。2021年6月からランキングシグナルに正式採用されています。

Core Web VitalsとPageSpeed Insightsのスコアは何が違いますか？

PageSpeed Insightsのスコア（0〜100点）はラボ環境での計測値であり、SEO順位には直接影響しません。Core Web Vitalsは実ユーザーのブラウザで計測したフィールドデータをSearch Consoleが集計したものが順位要因になります。施策の効果確認はSearch ConsoleのCore Web Vitalsレポートで行ってください。

LCPを改善するには何から始めればいいですか？

まずPageSpeed InsightsでLCP要素（最大の画像またはテキストブロック）が何かを確認することから始めてください。LCP要素が画像であれば、WebP変換・fetchpriority="high"の付与・不要なlazy loadingの除外が優先施策です。TTFB（サーバー応答時間）が長い場合はCDNやキャッシュの設定見直しも必要です。

CLSが悪化する原因はどんなものがありますか？

主な原因は、画像へのwidth・height属性の未設定、Webフォントの表示切り替え、広告・バナーの遅延挿入、A/BテストツールやSNSウィジェットなどのサードパーティスクリプトによる動的DOM追加です。「画像は全部設定した」という場合はGTM経由のサードパーティスクリプトをChrome DevToolsで調査することを推奨します。

INPとFIDの違いは何ですか？

FID（First Input Delay）はページ読み込み後の最初のユーザー操作への応答遅延だけを計測していましたが、INP（Interaction to Next Paint）はページ滞在中のすべてのインタラクション（クリック・タップ・キーボード）を対象に計測します。2024年3月にFIDがINPに置き換えられたため、現在の計測・改善対象はINPです。

Core Web Vitalsの改善後、Search Consoleに反映されるまでどれくらいかかりますか？

Search ConsoleのCore Web Vitalsレポートは過去28日間のデータを集計しているため、施策実施後の変化が反映されるまで最低28日かかります。それ以前はPageSpeed InsightsのラボデータとフィールドデータのAPI取得で中間確認を行うのが実務上の一般的な対応です。

Core Web Vitalsが悪くても検索順位は下がりませんか？

Core Web VitalsはSEO順位の一つの要因ですが、唯一の決定因子ではありません。Googleはコンテンツの質・E-E-A-T・関連性を最優先しており、Core Web Vitalsは同程度のコンテンツ品質が競合するときに差別化要因になるとされています。ただし、指標がPoor（最低ランク）のページは不利になる可能性があるため、最低限「要改善」以上を目指すことを推奨します。

Core Web Vitalsの改善は外注できますか？どんなことを依頼できますか？

可能です。一般的には、診断（PageSpeed Insights・Search Consoleの分析）、原因特定、HTML/CSS/JavaScript改善、CDN・サーバー設定の最適化、施策後のKPIモニタリングまでを一括で依頼できます。特にサードパーティスクリプトの棚卸しや、フレームワーク（React・Vueなど）の最適化は専門知識が必要なため、外注が効率的なケースが多いです。

まとめ

Core Web Vitalsの改善は「PageSpeed InsightsのスコアをあげるためのSEOテクニック」ではなく、「実ユーザーの体験を数値で管理するための継続的な実務プロセス」です。

LCP・INP・CLSの3指標はそれぞれ異なる原因で悪化するため、まずSearch ConsoleとPageSpeed Insightsで原因を特定し、優先度の高いページと指標から施策を1つずつ実施することが最短の改善ルートです。

施策後は最低28日間のフィールドデータ推移をSearch Consoleで確認し、Good URL比率が向上しているかを追い続けてください。技術的な改善とコンテンツの質・内部リンク設計を組み合わせることで、検索順位と問い合わせへの動線がより強固になります。