コアウェブバイタル（Core Web Vitals）とは？LCP・INP・CLSの基準と改善方法を分かりやすく解説

本記事では、コアウェブバイタル（Core Web Vitals）とは何か、SEOにどのような影響があるのか、Googleサーチコンソールなどでどう計測し、どの順番で改善すべきかまでを、Web担当者・SEO担当者向けに整理します。

最後まで読めば、自社サイトのどのURLを「どの指標から」「どのように開発者へ依頼すべきか」を判断できるでしょう。

「Googleサーチコンソールの『ウェブに関する主な指標』で不良URLが出た」
「PageSpeed InsightsにURLを入れたら、赤い数値ばかりで何から直せばよいのか分からない」

そんなときに見るべきなのが、コアウェブバイタルです。この数値を改善すれば検索順位が必ず上がる、という単純な話ではありません。大切なのは、検索意図を満たすコンテンツを用意した上で「表示の遅さ」「操作の重さ」「画面のズレ」といったストレスを減らすことです。

コアウェブバイタル（Core Web Vitals）とは？Googleが重視するUX指標

コアウェブバイタル（Core Web Vitals）とは、Googleが定めるユーザー体験を測るための重要指標です。SEOの専門用語として扱われがちですが、本質は「訪問者がページを快適に使えるか」を数値で確認する仕組みにあります。

ページの内容がどれだけ良くても、表示に時間がかかる、ボタンを押しても反応しない、読んでいる途中で広告が入って本文がズレる、といった体験が続くとユーザーは離脱します。コアウェブバイタルは、そうした小さなストレスを見つけるための共通言語です。

SEO担当者にとっては、開発者や制作会社へ「なんとなく遅い」ではなく、「モバイルのLCPが4秒超」「商品詳細テンプレートでCLSが悪い」のように具体的に伝えられる点が大きなメリットです。

コアウェブバイタルが注目されるようになった背景

コアウェブバイタルは2021年以降、Google検索におけるページエクスペリエンスの要素として注目されるようになりました。その後も指標は見直されており、2024年には応答性の指標がFIDからINPへ置き換わりました。

現在コアウェブバイタルを確認するなら、LCP・INP・CLSの3指標を前提に考える必要があります。古い記事や資料にFIDが中心で書かれている場合は、情報が更新されているか確認しましょう。

「ウェブバイタル」と「コアウェブバイタル」の違い

「ウェブバイタル（Web Vitals）」は、Googleが提唱するユーザー体験指標の総称です。その中でも、すべてのWebページで特に重視すべき中心的な指標がコアウェブバイタルです。

実務では、ウェブバイタルはユーザー体験を評価するための広い指標群、コアウェブバイタルはその中でもGoogleが特に重要視する中心指標、と分けて考えると理解しやすくなります。FCP、TTFB、TBTなどは原因分析の補助指標として使い、LCP・INP・CLSは改善優先度を決める主指標として見ます。

PageSpeed Insightsを見ると、FCP、Speed Index、TBTなど多くの数値が表示されます。そのため最初は混乱しやすいのですが、SEO担当者がまず押さえるべきは、コアウェブバイタルであるLCP・INP・CLSです。その他の数値は、原因を深掘りするための補助情報として使うと整理しやすくなります。

現在のコアウェブバイタルの3指標はLCP・INP・CLS

現在のコアウェブバイタルは、LCP・INP・CLSの3指標です。各指標の概要は、以下の通りです。

指標	見ている体験	良好の目安	よくある悪化原因
LCP	メインコンテンツが表示される速さ	2.5秒以下	・大きな画像 ・遅いサーバー応答 ・CSS / JavaScriptのブロック
INP	クリックやタップへの反応	200ms以下	・重いJavaScript ・長いタスク ・複雑なDOM
CLS	画面レイアウトの安定性	0.1以下	・画像や広告枠のサイズ未指定 ・Webフォント ・後から挿入される要素

これらの指標はそのまま覚えるより、ユーザーが感じる問題に置き換えて理解すると実務で使いやすくなります。

LCPは「メイン画像や本文がなかなか表示されない」を防ぐための指標、INPは「タップしても反応が遅い」を見つけるための指標、CLSは「広告や画像で本文がズレる」を防ぐための指標です。3つは別々の体験を測っているため、どれかひとつだけ良ければ十分ではありません。

実務で見るときは、まず自社ページのどの表示・操作でストレスが起きているかを確認します。数値は原因探しの入口であり、ユーザーの体感や実機での動きとセットで見ることが大切です。

FIDからINPへ変わった背景

以前のコアウェブバイタルでは、応答性の指標としてFID（First Input Delay）が使われていました。しかし現在は、INPが応答性の主要指標です。Googleは2024年3月に、INPをCore Web Vitalsの安定指標として扱い、FIDを置き換えました。

FIDは、ユーザーが最初に行った操作の入力遅延だけを測る指標でした。一方、INPはページ滞在中に発生する複数のクリック、タップ、キー入力などを見て、全体として反応が遅くないかを評価します。つまり、実際の操作体験により近い指標になったと考えると分かりやすいでしょう。

FIDは初回操作だけを見ていたのに対し、INPはページ滞在中の複数の操作をより広く評価します。メニュー開閉、フォーム入力、検索窓、カート追加など、ユーザーが実際に触る場面の重さが見えやすくなった点が大きな違いです。

古いSEO記事や制作会社の提案資料では、今でもFID中心の説明が残っていることがあります。2026年現在、コアウェブバイタルを改善するなら、応答性はINPを前提に確認しましょう。

コアウェブバイタルがSEOに与える影響

コアウェブバイタルは、Google検索におけるページエクスペリエンスの一部として扱われます。ここで大切なのは、数値改善だけで検索順位が必ず上がるわけではないという点です。

SEOで考えるなら、コアウェブバイタルは「コンテンツ品質を補強するUX改善」と見るのが現実的です。同じように有益な記事が並んだとき、読み込みが速く、操作しやすく、ストレスなく読めるページのほうが、ユーザーに選ばれやすくなります。

検索順位に重要な要因だが、コンテンツ品質が前提

コアウェブバイタルは検索順位に関係する要素ですが、検索順位を決める唯一の要因ではありません。検索結果でもっとも重要なのは、ユーザーの検索意図に対して、分かりやすく信頼できる回答を提供できているかです。

そのため、「LCPを2.5秒以下にしたから必ず1位になる」といった説明は不正確です。正しくは、コンテンツの関連性や専門性が十分にある上で、ページ体験を改善することでSEO上の取りこぼしを減らせると考えるべきです。

そのため、コアウェブバイタルに関する数値が悪いからといって必ず順位が下がるとは言えません。検索順位は検索意図との一致、コンテンツ品質、専門性、内部リンク、外部評価など多くの要素で決まります。コアウェブバイタルは、その中でユーザー体験を評価する重要な要素のひとつです。

ただし、数値が悪いページは、表示待ちや操作遅延によってユーザーが離脱しやすくなる可能性があります。順位だけを目的にするのではなく、読まれやすく、使いやすく、CVにつながりやすいページへ改善するための指標として扱いましょう。

実務では、検索流入の多いページやCVに近いページを確認し、コンテンツ改善とコアウェブバイタル改善をセットで進めると効果を見やすくなります。記事の品質だけを直しても読み込みが遅ければ離脱されますし、速度だけを直しても内容が薄ければ上位表示は期待できません。

影響が出やすいサイト・ページ

コアウェブバイタル改善の優先度が高いのは、ユーザー体験の悪化が成果に直結しやすいページです。とくに以下のぺージは早めに確認しましょう。

改善の影響が出やすいのは、以下のようなぺージです。

記事ならLCPとINP、商品詳細や広告が多いページならLCPとCLS、フォームやLPならINPとCLSを優先して見ます。

サーチコンソールで不良URLが出ている場合、全ページを一度に直す必要はありません。まずは流入・売上・問い合わせへの影響が大きいURLから着手するほうが、社内でも改善効果を説明しやすくなります。

UX・CVR改善にもつながる理由

コアウェブバイタルの改善は、SEOだけでなくUXとCVR改善にも関係します。

表示待ちが長いページでは、ユーザーは本文を読む前に戻ってしまいます。ボタンを押しても反応が遅ければ、フォーム入力や購入手続きの途中で不安になるでしょう。広告やバナーで画面がズレれば、誤タップや読みづらさにつながります。

例えばECサイトでは、商品画像がなかなか表示されないだけで比較検討から外れることがあります。BtoBサイトでは、資料請求フォームの反応が遅いだけで「この会社は大丈夫？」と感じられてしまうかもしれません。

コアウェブバイタルは、こうした目に見えにくい機会損失を見つけるための指標でもあります。

コアウェブバイタル3指標の基準値

コアウェブバイタルには、Googleが示す「良好」「改善が必要」「不良」の基準があります。サーチコンソールやPageSpeed Insightsで表示される判定も、下表の基準で確認します。

指標	良好	改善が必要	不良
LCP	2.5秒以下	2.5秒超〜4秒以下	4秒超
INP	200ms以下	200ms超〜500ms以下	500ms超
CLS	0.1以下	0.1超〜0.25以下	0.25超

上表は、SEO担当者やWeb担当者が制作会社へ依頼するときの共通認識として使用できます。依頼の際には単に「PageSpeedの点数を上げたい」と伝えるより、「モバイルのLCPが4秒超なので、ファーストビュー画像とサーバー応答を確認してほしい」と伝えるほうが、改善作業に移りやすくなります。

LCP｜最大コンテンツの表示速度

LCP（Largest Contentful Paint）は、ページの読み込み開始から、画面内で最も大きな画像やテキストブロックが表示されるまでの時間を測る指標です。Googleの基準では、LCPは2.5秒以下が良好、2.5秒超〜4秒以下が改善が必要、4秒超が不良とされています。

LCP要素になりやすいのは、トップページのメインビジュアル、記事ページのファーストビュー画像、LPの大きな見出しやキービジュアルです。悪化原因としては、画像サイズが大きすぎる、サーバー応答が遅い、CSSやJavaScriptが表示を妨げている、といったケースがよくあります。

SEO担当者が最初に行うべきことは、「LCPが悪い」とだけ伝えるのではなく、PageSpeed Insightsでどの要素がLCPになっているかを確認し、スクリーンショット付きで共有することです。

INP｜操作に対する応答性

INP（Interaction to Next Paint）は、クリック、タップ、キー入力などの操作が、次の画面更新として反映されるまでの遅さを測る指標です。良好は200ms以下、改善が必要は200ms超〜500ms以下、不良は500ms超です。

INPが悪いページでは、ボタンを押しても一瞬固まる、メニューの開閉が遅い、フォーム入力が引っかかるといった体験が起こりやすくなります。原因としては、以下のようなものが考えられます。重いJavaScript、長いタスク、マーケティングタグやチャットツールの過剰読み込み、複雑なDOM構造などが考えられます。

非エンジニアが確認する場合は、スマートフォンで実際にページを触ってみることも重要です。ツール上の数値だけでなく、ユーザーがよく押すボタンやフォームで「待たされる感覚」がないかを見ておきましょう。

CLS｜意図しないレイアウトのズレ

CLS（Cumulative Layout Shift）は、ユーザーが予期しないレイアウトのズレを数値化する指標です。良好は0.1以下、改善が必要は0.1超〜0.25以下、不良は0.25超です。

CLSが悪いページでは、本文を読んでいる途中で広告が読み込まれて文章が下にズレる、押そうとしたボタンの位置が変わって別のリンクをタップしてしまう、といった問題が起きます。画像や動画のサイズ未指定、広告枠の後読み込み、Webフォントの読み込み、Cookieバナーやポップアップの表示が主な原因です。

CLSはSEOのためだけでなく、ユーザーの信頼感にも関わります。とくに購入ボタン、フォーム送信ボタン、電話CTAの周辺でズレが起きると、CVRに悪影響が出やすいため注意が必要です。

75パーセンタイルとモバイル・PC別評価

コアウェブバイタルは、1回だけPageSpeed Insightsを実行したときの最速値で判断するものではありません。Googleは実際のユーザー体験を反映するため、モバイルとデスクトップそれぞれで75パーセンタイルを基準に評価することを推奨しています。

75パーセンタイルとは、簡単に言えば「全体の75％のユーザーがその値以下で体験できているか」を見る考え方です。平均値だけを見ると、一部の遅いユーザー体験が埋もれてしまうことがあります。そこで、より現実に近い評価として75パーセンタイルが使われます。

また、PCでは良好でもモバイルでは不良になることがあります。スマートフォンは通信環境や端末性能の影響を受けやすいため、検索流入の多くがモバイルなら、PCの結果よりもモバイルの結果を優先して確認しましょう。

良好・改善が必要・不良の見方

サーチコンソールやPageSpeed Insightsでは、コアウェブバイタルの状態が「良好」「改善が必要」「不良」の3段階で表示されます。赤い表示を見ると焦りがちですが、まずは判定の意味を冷静に分けて考えることが大切です。

「良好」は基準を満たしている状態なので、無理に大きな改修を入れるより維持・監視を優先します。「改善が必要」は、流入やCVへの影響が大きいページから確認する状態です。「不良」は、URL、端末、悪い指標、原因候補を特定して、早めに開発者へ相談すべき状態です。

重要なのは、スコアの色だけで判断しないことです。不良URLが大量にある場合でも、同じテンプレートが原因なら、テンプレート修正でまとめて改善できることがあります。逆に、1URLだけでもCVに近いページなら優先度は高くなります。

FCP・TBTなど関連指標との違い

PageSpeed Insightsには、FCP・TBT・Speed Indexなどの指標も表示されます。これらはコアウェブバイタルそのものではありませんが、原因を探るための補助指標として役立ちます。

FCPは最初のコンテンツが表示されるまでの時間、TBTはメインスレッドが長くブロックされた時間、Speed Indexは視覚的な表示速度、TTFBはサーバーから最初の応答が返るまでの時間を見る指標です。これらはコアウェブバイタルそのものではありませんが、LCP・INP・CLSが悪い原因を探るときの補助情報として役立ちます。

とくにLighthouseでは、INPではなくTBTが表示される場合があります。これはINPが実ユーザーの操作をもとに評価されるフィールド指標であるためです。TBTは、開発・検証環境でJavaScriptの重さを見つけるためのヒントとして使いましょう。

合格判定は3指標すべて「良好」が基本

コアウェブバイタルは、LCP・INP・CLSの3指標すべてが良好であることを目指します。平均点で考えるのではなく、一番弱い指標を見つけて直すことが重要です。

例えばLCPとCLSが良好でもINPが不良であれば、ユーザーはボタン操作やフォーム入力でストレスを感じている可能性があります。逆にINPが良好でもCLSが悪ければ、読んでいる途中で画面がズレて誤タップが起きるかもしれません。

制作会社へ依頼する際は「全体スコアを上げてください」ではなく、「モバイルのINPが不良なので、長いJavaScript処理とイベント処理を確認してください」というように、弱点を具体化して伝えると改善が進みやすくなります。

コアウェブバイタルを計測できる主なツール

コアウェブバイタルの計測には、目的に応じて複数のツールを使い分けましょう。

サイト全体の傾向を見るならGoogleサーチコンソール、個別URLを深掘りするならPageSpeed Insights、開発中の原因調査にはLighthouseやChrome DevToolsが向いています。

ツール名	主な用途	向いている人
Googleサーチコンソール	サイト全体の不良URLやURLグループを見る	サイト運営者、マーケター
PageSpeed Insights	個別URLのフィールドデータと診断を見る	SEO担当者、Web担当者
Lighthouse	開発・検証環境で改善候補を確認する	制作会社、開発者
Chrome DevTools	LCP要素、長いタスク、レイアウトシフトを詳しく調べる	開発者
Web Vitals拡張機能	表示中ページの簡易確認を行う	担当者、開発者

最初からすべてを使いこなす必要はありません。まずサーチコンソールで問題のあるURLグループを見つけ、PageSpeed Insightsで代表URLを分析し、必要に応じて開発者がDevToolsで深掘りする流れが現実的です。

Googleサーチコンソール

Googleサーチコンソールは、自社サイトの実ユーザーデータをもとに、コアウェブバイタルの問題をモバイル・PC別、ステータス別、URLグループ別に確認できるツールです。所有権を確認済みのサイトで利用できます。

サーチコンソールの強みは、サイト全体の傾向を見られることです。たとえば「記事ページのテンプレート全体でLCPが悪い」「商品詳細ページの一部でCLSが悪い」といった形で、同じ構造を持つURLをまとめて把握できます。

注意点として、サーチコンソールは代表URLを表示することがあります。表示されたURLだけを直すのではなく、同じURLグループに含まれるページ群を確認し、テンプレート単位で原因を探ることが大切です。

PageSpeed Insights

PageSpeed Insightsは、URLを入力するだけで、そのページのコアウェブバイタルや改善候補を確認できる無料ツールです。実際のChromeユーザーのデータであるフィールドデータと、Lighthouseによるラボ診断の両方を確認できます。

個別ページのLCP・INP・CLSを見たいとき、モバイルとPCでどれくらい差があるかを確認したいとき、競合ページと比較したいときに向いています。ただし、十分なアクセスデータがないURLでは、ページ単位のフィールドデータが表示されない場合があります。その場合は、オリジン単位のデータやラボ診断を参考にします。

SEO担当者は、PageSpeed Insightsの結果画面をそのまま開発者へ送るだけでなく、「どの指標が悪いのか」「対象はモバイルかPCか」「改善できる項目に何が出ているか」をメモして共有すると、話が早くなります。

Lighthouse・Chrome DevTools・Web Vitals拡張機能

LighthouseやChrome DevToolsは、開発・検証時に原因を深掘りするためのツールです。Lighthouseはラボ環境でページを読み込み、パフォーマンス上の改善候補を提示します。DevToolsでは、LCP要素、メインスレッドの長い処理、レイアウトシフトの発生箇所などを詳しく確認できます。

ただし、ラボデータは実ユーザーの環境を完全に再現するものではありません。通信環境、端末性能、キャッシュ状態、地域、ユーザー行動によって、実際のコアウェブバイタルとは差が出ることがあります。

ウェブバイタル拡張機能は、表示中ページの状態を簡単に確認したいときに便利です。本格的な改善判断はサーチコンソールやPageSpeed Insightsで行い、拡張機能は簡易チェックとして使うとよいでしょう。

PageSpeed Insightsで確認する手順

PageSpeed Insightsは、初心者でも使いやすいコアウェブバイタル計測ツールです。ただし、表示される情報が多いため、最初は「スコア」だけを見てしまいがちです。大切なのは、フィールドデータ、ラボデータ、改善できる項目を分けて読むことです。

赤い点数だけを見て「とにかく100点にしてください」と依頼すると、工数の割に成果が見えにくくなります。まずは実ユーザーの評価を確認し、悪い指標と原因候補を切り分けましょう。

1. URL入力後にフィールドデータを見る

まず、PageSpeed Insightsに対象URLを入力します。結果が表示されたら、最初に見るべきは「実際のユーザーの環境で評価する」欄です。ここにLCP・INP・CLSの値と、コアウェブバイタルに合格しているかどうかが表示されます。

このとき、ページ単位のデータなのか、オリジン単位のデータなのかも確認します。URL単位のデータが十分にない場合、サイト全体に近い単位で表示されることがあるためです。

確認項目	記録例
対象URL	https://example.com/service/
端末	モバイルで不良、PCは良好
悪い指標	LCP 4.2秒、CLS 0.18
Core Web Vitals評価	合格 / 不合格
LCP要素・遅い操作・ズレる箇所	FV画像、フォーム送信ボタン、広告枠など
改善できる項目の上位3つ	画像最適化、不要なJavaScript削減、サーバー応答時間など
ｂ	2026年5月22日 10:00

この表の項目をメモしておくだけでも、開発者との会話はかなりスムーズになります。とくに「モバイルかPCか」「URL単位かオリジン単位か」「LCP要素は何か」は、改善方針を決める上で重要です。

改善できる項目を上からすべて依頼するのではなく、悪い指標に直結しそうな項目だけ優先して相談しましょう。

2. ラボデータ・診断・改善できる項目を読む

次に、Lighthouseによるラボデータと「改善できる項目」を確認します。ラボデータは、一定の条件で疑似的にページを読み込んだ診断結果です。実ユーザー評価そのものではありませんが、原因を探るヒントとして役立ちます。

「改善できる項目」には、画像サイズの最適化、不要なJavaScriptの削減、レンダリングを妨げるリソースの除去、サーバー応答時間の短縮などが表示されます。ここで重要なのは、出てきた項目をすべて直そうとしないことです。

まずは、悪いコアウェブバイタル指標に関係しやすい項目から見ます。LCPが悪ければ画像、サーバー応答、CSS・JavaScriptのブロックを確認しましょう。INPが悪ければJavaScript、長いタスク、第三者タグ、DOM更新を確認します。CLSが悪ければ画像サイズ、広告枠、Webフォント、後から挿入される要素を疑いましょう。

依頼時は、「改善できる項目に○○が出ています」だけでなく、「この項目がLCP/INP/CLSのどれに関係しそうか」まで添えると、開発者側で優先順位をつけやすくなります。例えば、LCP不良なら「ファーストビュー画像の最適化と優先読み込み」、INP不良なら「不要JSと長いタスクの確認」、CLS不良なら「画像・広告枠のサイズ指定」を最初に見てもらう形です。

3. 競合ページや主流入デバイスを確認する

PageSpeed Insightsは、公開URLであれば競合ページも確認できます。検索上位の競合記事やLPを入力し、自社ページと比べてどの指標に差があるのかを見ると、改善優先度を説明しやすくなります。

ただし、比較するときは主流入デバイスを合わせましょう。自社サイトの検索流入がモバイル中心なら、PCの数値が良くても安心できません。逆にBtoBサイトでPC流入が多い場合は、PCの操作性や表示速度も丁寧に見る必要があります。

競合比較は、相手の点数をそのまま追いかけるためではありません。自社が明らかに遅い箇所を見つけ、ユーザーが検索結果から戻ってしまう理由を減らすために使います。

競合比較では検索上位3〜5ページを確認し、自社ページだけ極端に悪い指標がないかを見ます。全競合より100点に近づける必要はありませんが、同じ検索意図の記事で自社だけLCPが4秒超、CLSが不良という状態なら、ユーザーが検索結果へ戻る理由になり得ます。

Googleサーチコンソールで改善対象URLを見つける手順

サーチコンソールは、サイト全体から改善対象URLを見つけるために使います。PageSpeed Insightsが「個別URLの精密検査」だとすれば、サーチコンソールは「サイト全体の健康診断」です。

理想的な流れは、サーチコンソールで不良または改善が必要なURLグループを見つけ、代表URLをPageSpeed Insightsで深掘りし、原因を開発者へ共有することです。

実務では、まずモバイルの「不良」を確認し、次に「改善が必要」、最後にPC側を見る順番が分かりやすくなります。あわせて悪い指標、URLグループ、対象URL数、悪化した日付、直前のサイト変更をメモしておくと、原因の切り分けが早くなります。

1. 「ウェブに関する主な指標」を開く

サーチコンソールの左メニューから、エクスペリエンス配下の「ウェブに関する主な指標」を開きます。ここではモバイルとPCそれぞれの良好、改善が必要、不良の件数推移を確認できます。

まず見るべきは、急な悪化が起きていないかです。サイトリニューアル、テーマ変更、広告タグ追加、画像差し替え、CMS改修の直後に件数が悪化していれば、その変更が原因になっている可能性があります。

また、モバイルとPCは分けて見ます。モバイルだけ不良が増えている場合、画像サイズ、JavaScript、広告表示、モバイル用レイアウトなどに問題があることが多いです。

2. 「URLグループ」と「不良・改善が必要」をチェックする

サーチコンソールでは、似たページがURLグループとしてまとめられます。例えば記事ページ、商品詳細ページ、カテゴリページなど、同じテンプレートのページが一括で評価されることがあります。

そのため、例示URLだけを見て判断しないことが重要です。代表URLをPageSpeed Insightsで確認しつつ、同じテンプレートを使っているページにも同じ問題がないかを確認します。

不良ステータスは、LCP・INP・CLSのうち悪い指標に引っ張られます。まず見る部分は、「どの指標が原因か」を確認し、次に「その指標が悪いURLグループはどれか」です。この順番にすると、改善作業をページ単位ではなくテンプレート単位で進めやすくなります。

開発者へ渡すときは、「代表URL」だけでなく「同じテンプレートのURLグループで起きている問題」として伝えるのがポイントです。たとえば、「 /column/ 配下」の記事ページ全体でLCPが悪いなら、1記事だけの画像ではなく記事テンプレートのファーストビュー設計やアイキャッチ画像の読み込み仕様に原因がある可能性があります。

以下のように開発者などに伝えると、分かりやすいでしょう。

LCPを改善する方法

LCP改善は、ファーストビューの主要コンテンツを早く表示するための施策です。とくにメインビジュアル画像、記事上部の大きな画像、ファーストビュー内のテキストブロックがLCP要素になることが多いため、まずは何が遅れているのかを特定します。

原因候補	確認内容	依頼例
画像が重い	ファーストビュー画像の容量・形式・表示サイズ	WebP/AVIF化と適切な圧縮を確認してほしい
読み込み開始が遅い	重要画像がlazy loadになっていないか	FV画像を優先読み込みにできるか確認してほしい
サーバー応答が遅い	TTFB、キャッシュ、CDN	キャッシュ設定とCDN利用を検討してほしい
表示がブロックされる	CSS・JSの読み込み順	不要JS削減とレンダリングブロック対策を確認してほしい

LCP要素を特定する

LCP改善で最初に行うべきことは、LCP要素を特定することです。PageSpeed InsightsやChrome DevToolsでは、どの画像やテキストがLCPとして評価されているかを確認できます。

よくある失敗は、「たぶんメイン画像が原因だろう」と決めつけて画像だけを圧縮することです。実際には、見出しテキストがLCPになっていたり、背景画像がCSS経由で読み込まれて発見が遅れていたり、サーバー応答そのものが遅かったりすることもあります。

開発者へ依頼するときは、「対象URL」「モバイル/PC」「LCP値」「LCP要素のスクリーンショット」をセットで渡しましょう。原因特定が早くなり、改善後の比較もしやすくなります。

画像の圧縮・WebP化・サイズ最適化を反映する

大きすぎる画像は、LCP悪化の代表的な原因です。ファーストビューに2,000px以上の画像をそのまま表示していたり、スマートフォンでもPC用の大きな画像を読み込んでいたりすると、表示が遅くなります。

改善策としては、WebPやAVIFなどの軽量形式への変換、適切な圧縮、表示サイズに合わせたリサイズ、srcsetによるレスポンシブ画像の出し分けが考えられます。

ただし、画質を落としすぎるとブランドイメージやCVRに悪影響が出ることもあります。依頼時は「画質を保ったまま、ファーストビュー画像をWebP化・圧縮し、スマホ表示に適したサイズへ最適化してください」のように伝えると、デザイン面とのバランスを取りやすくなります。

ファーストビュー画像を優先読み込みにする

ファーストビューの重要画像は、遅延読み込みの対象にしないことが基本です。ページ上部に表示されるLCP画像にloading=”lazy”が設定されていると、ブラウザが画像の読み込み開始を遅らせ、LCPが悪化することがあります。

また、LCP画像はHTMLから早く発見できる形にすることが重要です。JavaScript実行後でないと画像URLが分からない実装や、CSSの背景画像としてのみ指定されている実装では、ブラウザが画像を見つけるタイミングが遅れる場合があります。

開発者には、「ファーストビュー画像がHTMLから早く検出できるか」「必要に応じてpreloadやfetchpriorityを使えるか」「LCP画像がlazy loadになっていないか」を確認してもらいましょう。実装可否はサイト構成によって異なるため、断定ではなく確認依頼として伝えるのが安全です。

サーバー応答・CSS/JSのブロックを減らす

LCPは画像だけでなく、サーバー応答やCSS・JavaScriptの影響も受けます。サーバーから最初のHTMLが返るまでの時間が長いと、その後の画像やCSSの読み込みも遅れます。

サーバー応答を改善する場合は、CDN、キャッシュ設定、不要なCSS・JavaScriptの削減、重要CSSの最適化を順番に検討します。全国や海外からアクセスがあるサイトはCDN、記事メディアやCMSサイトはキャッシュ設定、テーマ変更やタグ追加後に悪化したサイトは不要CSS・JavaScriptの見直しから確認すると進めやすいです。

SEO担当者は、サーバーやコードを直接直せなくても問題ありません。PageSpeed Insightsで「サーバーの初期応答時間を短縮」「レンダリングを妨げるリソースの除外」などが出ている場合、その項目名と対象URLを添えて開発者へ相談しましょう。

INPを改善する方法

INP改善は、ユーザー操作への反応を軽くする施策です。クリック、タップ、フォーム入力、メニュー開閉など、実際にユーザーが触る場面で画面が固まらないようにすることが目的です。

INPが悪いページでは、JavaScriptがメインスレッドを長く占有していたり、操作のたびに大きなDOM更新が走っていたり、マーケティングタグやチャットツールが多すぎたりすることがあります。

重いJavaScriptと長いタスクを分割する

INP悪化の代表的な原因は、重いJavaScriptです。ブラウザはJavaScriptの実行、レイアウト計算、描画などを処理しています。長い処理が続くと、ユーザーがタップしても反応できず、操作が遅れて見えます。

改善策としては、不要なJavaScriptの削除、コード分割、初期表示に不要な処理の遅延読み込み、長いタスクの分割が挙げられます。とくにタグマネージャー経由で追加した広告タグ、解析タグ、ヒートマップ、チャットツールは、積み重なると操作性に影響することがあります。

マーケター側でできることは、使っていないタグを棚卸しすることです。「何となく残っている古いタグ」「一時的なキャンペーン用タグ」「使っていない外部ツール」があれば、削除候補として開発者や広告担当者と確認しましょう。

入力イベントの処理を軽くする

INPは、ユーザーの操作に対する反応を見ます。そのためボタンやフォーム、メニュー、検索窓、絞り込み機能など、操作が発生する箇所の処理を軽くすることが重要です。

例えば、ボタンをクリックした直後に大量のデータ取得や複雑な計算を行うと、画面の更新が遅れます。フォーム入力のたびに重いバリデーションを走らせる、検索窓に1文字入力するたびに大量のDOM更新を行う、といった実装もINP悪化につながります。

開発者へは、「ユーザー操作直後に重い処理を同期的に実行していないか」「優先度の低い処理を後回しにできないか」「入力イベントの処理を軽量化できないか」を確認してもらいましょう。SEO担当者は、ユーザーがよく使う操作箇所を実際に触って、遅さを感じる場面を動画やスクリーンショットで共有すると役立ちます。

DOMサイズ・レンダリング負荷を下げる

DOMとは、ブラウザがHTMLを構造として扱うための仕組みです。簡単に言えば、ページ上の要素がどのように配置されているかを表す設計図のようなものです。DOMが大きく複雑になると、操作後の再計算や描画に時間がかかり、INPが悪化しやすくなります。

例えば、商品一覧に大量の商品カードを一度に表示する、アコーディオン内に多くの要素を隠している、非表示エリアまで最初からすべて描画している、といったページでは注意が必要です。

改善策としては不要な要素の削減、画面外コンテンツの遅延描画、リスト表示のページネーション、複雑なレイアウトの見直しなどがあります。デザイン面の調整も関わるため、開発者だけでなく、デザイナーやマーケターも含めて「本当に初期表示で必要な要素か」を見直すと効果的です。

CLSを改善する方法

CLS改善は、ページ読み込み中や操作中の意図しないズレを防ぐ施策です。ユーザーが読んでいる本文が突然下に動いたり、押そうとしたボタンの位置が変わったりすると、ストレスだけでなく誤タップにもつながります。

CLSの原因は、画像、動画、広告、Webフォント、動的コンテンツ、Cookieバナーなどさまざまです。大切なのは、後から表示される要素があるなら、あらかじめそのスペースを確保しておくことです。

画像・動画・広告枠にサイズを指定する

画像や動画の幅・高さが指定されていないと、読み込みが完了したタイミングで必要なスペースが確定し、周囲のコンテンツが押し下げられることがあります。これがCLS悪化の典型例です。

改善するには、画像や動画に幅・高さ、またはアスペクト比を指定し、読み込み前から表示領域を予約しておきます。レスポンシブデザインでも、比率が崩れないようにCSSで調整する必要があります。

広告枠も同じです。広告はネットワーク状況や配信条件によって遅れて表示されるため、表示される前提で枠を確保しておきます。広告が配信されなかった場合に大きな空白が残る問題もあるため、最小高さや代替表示の設計まで含めて確認しましょう。

Webフォントや動的コンテンツによるズレを防ぐ

Webフォントの読み込みによって文字の太さや幅が変わると、本文や見出しの位置がズレることがあります。フォントの表示方法を調整するfont-display、代替フォントの指定、読み込み順の見直しなどが対策になります。

また、おすすめ記事、レビュー、在庫表示、関連記事、ランキング枠など、後から挿入される動的コンテンツにも注意が必要です。これらが本文の上部に後から入ると、ユーザーが読んでいる箇所が押し下げられます。

対策としては、プレースホルダーを用意する、表示位置を固定する、本文の途中ではなく下部に配置する、読み込み中の枠をあらかじめ確保するといった方法があります。マーケティング施策で追加した要素ほど、表示タイミングとレイアウトへの影響を確認しましょう。

Cookieバナー・ポップアップの表示位置に注意する

Cookie同意バナー、追従CTA、アプリ誘導、キャンペーンポップアップは、CVR改善のために導入されることが多い要素です。しかし、本文を押し下げる形で表示されるとCLSを悪化させる可能性があります。

とくにスマートフォンでは画面が狭いため、バナーやポップアップの表示位置、サイズ、タイミングによっては、本文の可読性やボタン操作を妨げます。SEOのために数値を良くするというより、ユーザーの行動を邪魔しない設計にすることが大切です。

実務では追従CTAやバナーを追加するたびに、スマートフォンの初回表示、スクロール時、フォーム入力時の挙動を確認しましょう。CVを増やすための導線が、逆に離脱や誤操作を生んでいないかを見る必要があります。

変更前後を実機で確認する

CLSはツールだけでなく、実機確認も重要です。PageSpeed Insightsで改善しているように見えても、実際のスマートフォンで広告やバナーの読み込みタイミングが違えば、ズレが起きることがあります。

確認するときは、初回表示、スクロール、広告読み込み、メニュー開閉、フォーム入力、戻る操作など、実際のユーザー行動に近い動きを試します。可能であれば、iPhoneとAndroid、ChromeとSafariなど複数環境で確認しましょう。

改善前後の画面録画を残しておくと、社内説明にも役立ちます。「CLSが0.25から0.08になりました」だけでなく、「本文が押し下げられなくなり、CTAの誤タップが減る状態になりました」と説明できると、施策の価値が伝わりやすくなります。

改善の優先順位と開発者への依頼方法

コアウェブバイタル改善では、施策を思いつくまま並べるのではなく、どこから着手するかを決めることが重要です。優先すべきはモバイル流入が多いページ、検索流入が多いページ、CVに近いページ、サーチコンソールで不良判定になっているURLグループです。

開発者へ依頼するときは指標名だけでなく、URL、端末、現象、ツール結果、推定原因をセットで共有します。これにより、調査工数を減らし、改善後の効果確認もしやすくなります。

まずモバイル・流入上位・不良URLから着手する

すべてのページを一気に直そうとすると、工数が膨らみ、成果が見えにくくなります。まずは影響度と実装工数で優先順位をつけましょう。

優先度	対象	理由	判断軸
高	モバイル流入が多く不良判定のページ	SEO・UXへの影響が大きい	流入数、LCP/INP/CLSの悪化度
高	CVに近いLP・フォーム・商品ページ	売上や問い合わせに直結する	CVR、離脱率、フォーム完了率
中	URLグループ単位で悪化しているテンプレート	まとめて改善できる可能性がある	対象URL数、テンプレート共通性
低	流入が少ない単発ページ	影響が限定的	工数と成果のバランス

この表を使えば、社内で「なぜこのページから直すのか」を説明しやすくなります。SEO施策としてだけでなく、事業成果に近いページから改善する意識を持ちましょう。

SEO担当者から開発者へ必要な情報を共有する

開発者や制作会社へ依頼するときは、抽象的に「表示速度を改善してください」と伝えるより、必要情報を整理して渡すほうが確実です。

共有項目	例
対象URL	https://example.com/service/
悪い指標	モバイルLCPが4.2秒、不良判定
ツール結果	サーチコンソールやPageSpeed InsightsのURLグループ
発生端末	モバイルで悪化、PCは良好
推定原因	LCP要素がファーストビュー画像。画像容量が大きい可能性
希望対応	画像圧縮、WebP化、優先読み込み設定の確認
希望期限	次回リリースまでに検証可否を確認

依頼文は、悪い指標ごとに分けると伝わりやすくなります。以下のように、対象URL、端末、悪い指標、原因候補、希望する確認内容を1セットで渡しましょう。

このように、指標、URL、原因候補、希望対応をまとめることで、開発者は調査の入口をつかみやすくなります。

改善後はデータ反映を待って効果を見る

コアウェブバイタルの改善は、反映タイミングに注意が必要です。PageSpeed Insightsのラボ診断はすぐに確認できますが、サーチコンソールやCrUX系のフィールドデータは、実際のユーザーデータが蓄積されてから反映されます。

そのため、改善直後はまずラボデータや実機確認で問題が解消しているかを見ます。その後、一定期間を置いてサーチコンソールのURLグループやPageSpeed Insightsのフィールドデータを確認します。

成果を見るときは、コアウェブバイタルの数値だけでなく、検索順位、クリック率、直帰・離脱、CVR、フォーム完了率も併せて確認しましょう。ユーザー体験の改善が、実際の事業成果にどうつながったかを見られるようになります。

コアウェブバイタルに関するよくある質問

コアウェブバイタルに関するよくある質問をまとめました。

コアウェブバイタルはいつから重要になった？

コアウェブバイタルは2021年以降、Google検索におけるページエクスペリエンスの要素として注目されるようになりました。その後も指標は見直されており、2024年には応答性の指標がFIDからINPへ置き換わりました。

詳しくは、記事内の「コアウェブバイタルが注目されるようになった背景」で解説しています。

コアウェブバイタルに関する数値が悪いと、順位は必ず下がる？

必ず順位が下がるとは言えません。検索順位は、検索意図との一致、コンテンツ品質、専門性、内部リンク、外部評価など多くの要素で決まります。コアウェブバイタルは、その中でユーザー体験を評価する重要な要素のひとつです。

詳しくは、記事内の「検索順位に重要な要因だが、コンテンツ品質が前提」をご覧ください。

まとめ｜コアウェブバイタルは、SEOとUXを同時に改善する指標

コアウェブバイタルは、LCP・INP・CLSによってユーザー体験を測る指標です。LCPはメインコンテンツの表示速度、INPは操作への反応、CLSはレイアウトの安定性を見ます。Google検索のページエクスペリエンスにも関係しますが、数値を直せば必ず順位が上がるというものではありません。大切なのは、ユーザーがストレスなく読み、操作し、問い合わせや購入に進める状態を作ることです。