コアウェブバイタルとは?その重要性と改善方法

コアウェブバイタルとは、ページの読み込み速度・操作への反応・表示の安定性を、実際のユーザー体験に近い形で測る重要指標です。

2026年時点で押さえるべき中核指標は、LCP・INP・CLSの3つです。SEO担当者やWeb担当者にとっては、単なる表示速度の話ではなく、「ユーザーが読める・押せる・ずれない」ページを作れているかを確認する基準として理解するのが実務では分かりやすいです。

この記事では、コアウェブバイタルの意味、SEOとの関係、測定ツール、指標別の改善方法まで、実務で優先順位を付けやすい形で整理していきます。コアウェブバイタルを正しく見直したい方は、ぜひこのまま読み進めてください。

この記事の監修者
株式会社EXIDEA 代表取締役社長
小川 卓真
SEO歴20年。2006年にSEOツールの開発企業を共同創業して以来、SEOを軸にデジタルマーケティングに従事。2013年に「株式会社EXIDEA」を設立。現在はEXIDEAの代表取締役社長として、Webメディア事業、マーケティングDX事業、オールインワンSEOツール「EmmaTools」の事業に携わる。
執筆者の詳しいプロフィールはこちら
EmmaBlog執筆者

コアウェブバイタルとは何か

コアウェブバイタルは、Googleがページ体験を評価するうえで重視している指標群のうち、特に重要な3項目です。単に「速いサイト」を目指すものではなく、ユーザーが主要コンテンツを早く見られるか、操作にすぐ反応するか、読んでいる途中でレイアウトがずれないかを測ります。

2026年時点の3指標は以下です。

コアウェブバイタルの3指標
  • LCP(Largest Contentful Paint):主要コンテンツが表示されるまでの速さ
  • INP(Interaction to Next Paint):操作に対する反応の良さ
  • CLS(Cumulative Layout Shift):表示の安定性

以前はFIDが使われていましたが、現在はINPが正式な指標です。古い解説記事のままFIDを中心に見ていると、改善の優先順位を誤りやすいため注意しましょう。

また、コアウェブバイタルだけで検索順位が決まるわけではありません。とはいえ、同程度の内容品質のページが並ぶ場面では、体験の差が結果に影響しやすくなります。特にモバイルでは、最初の表示と操作感の差が離脱率に直結しやすいです。

2026年時点で押さえる3つの指標

結論から言うと、LCPは「見えるまでの速さ」、INPは「押した後の反応」、CLSは「ずれないこと」です。名前だけ覚えるより、ユーザーがどの瞬間で不快になるかに置き換えると理解しやすくなります。

LCP:主要コンテンツが表示されるまでの時間

LCPは、ページ内で最も大きい主要要素が表示されるまでの時間です。記事ページならアイキャッチ画像や大見出し周辺、ECなら商品画像や商品名ブロックが対象になりやすいです。

目安は2.5秒以内で良好、4.0秒超で不良です。LCPが悪いと、ユーザーは「まだ読めない」と感じやすく、スクロール前に離脱する原因になります。

LCPが悪化しやすい典型例は以下です。

LCPが悪化しやすい原因
  • ファーストビューの画像が重い
  • サーバー応答が遅い
  • CSSやJavaScriptが表示をブロックしている
  • クライアントサイドレンダリングに依存しすぎている

たとえば、採用サイトのトップで大きな動画を自動再生している、ECの商品一覧でヒーロー画像を高解像度のまま配信している、といったケースはLCPが悪化しやすいです。

INP:操作してから画面が反応するまでの時間

INPは、クリックやタップ、キー入力などに対して画面がどれだけ素早く反応するかを見る指標です。200ms未満が良好、500ms超は不良が目安です。

以前のFIDは「最初の入力」だけを見ていましたが、INPはページ滞在中の操作全体をより実態に近く評価します。そのため、2026年の実務ではFID対策ではなく、INP改善として考える必要があります。

INPが悪いページでは、次のような症状が起きます。

INPが悪いページで起きやすいこと
  • メニューを押しても開くまで間がある
  • フォーム入力中に引っかかる
  • 絞り込みボタンを押した後の反応が遅い
  • タブ切り替えやモーダル表示が重い

実務でよくあるのは、便利機能を足した結果、JavaScriptの処理が増えすぎてメインスレッドが詰まるケースです。特に、チャットボット、ヒートマップ、ABテスト、広告タグ、レコメンドウィジェットを同時に積んでいるページは要注意です。

INPの原因を特定するには、Chrome DevToolsのPerformanceパネルで操作中のメインスレッド占有を確認するのが近道です。Long Taskとして50ms以上ブロックしているスクリプトが見つかれば、そのタグを遅延読み込みに切り替えるか、不要であれば削除を検討します。操作直後に走る同期処理を`requestAnimationFrame`や`setTimeout`で分割するだけでも、体感の改善につながることがあります。

CLS:表示中のレイアウトずれ

CLSは、読み込み途中に要素が動いてしまう度合いを示します。0.1以下が良好、0.25超で不良です。

ユーザーにとって厄介なのは、読んでいる途中で本文が下に押し出されたり、押そうとしたボタンの位置が変わったりすることです。これは単なる見た目の問題ではなく、誤タップや離脱の原因になります。

CLSが起きやすい例は以下です。

CLSが起きやすい実装例
  • 画像やiframeに縦横サイズを指定していない
  • 広告枠の高さが後から変わる
  • Webフォントの読み込みで文字幅が変わる
  • ページ上部に後からバナーを差し込む

たとえば、記事を読み始めた直後に「資料ダウンロード」バナーが上から差し込まれる、店舗ページでGoogleマップ埋め込みの高さが後から確定する、といった場面はCLSの典型です。

コアウェブバイタルはSEOにどこまで影響するのか

結論として、コアウェブバイタルはSEOに関係しますが、それだけで上位表示できる要素ではありません。検索順位を決めるのは総合評価であり、内容の有用性や検索意図との一致が前提です。

一方で、ページ体験が整っていることは、検索システムが評価しようとする方向と一致しています。つまり、「内容は良いのに使いにくいページ」を減らすための土台と考えるのが適切です。

特に次のような場面では影響を感じやすいです。

コアウェブバイタルを見直す価値が高いケース
  • 競合と内容差が小さいキーワードで戦っている
  • モバイル流入が多い
  • 順位はあるのにCTRや滞在が伸びない
  • リニューアル後に体験が悪化した

当社でもメディア改善では、記事本文そのものより先に、スマホでの初回表示やCTA周辺のずれを確認することがあります。内容が良くても、読み始める前に待たされる、押した瞬間に位置が動く、といった状態では成果につながりにくいためです。

また、コアウェブバイタルだけを完璧にしても、検索意図に合っていないページは伸びません。逆に、内容が非常に強いページは、多少スコアが完璧でなくても評価されることがあります。実務では「100点を狙う」より、「不良をなくし、主要ページを良好に寄せる」ほうが現実的です。

コアウェブバイタルの測定方法

最初に見るべきは、実ユーザーデータを確認できるSearch ConsoleとPageSpeed Insightsです。Lighthouseだけで判断すると、開発環境では良く見えても実際のユーザー体験とずれることがあります。

Google Search Consoleでサイト全体の傾向を見る

Search Consoleの「ウェブに関する主な指標」レポートでは、実際の利用データをもとに、良好・改善が必要・不良のURL群を確認できます。

サーチコンソール、エクスペリエンスから確認する

見るべきポイントは、単一URLよりも「どのテンプレート群で問題が起きているか」です。たとえば、記事ページだけ悪いのか、商品詳細だけ悪いのか、カテゴリページだけ悪いのかで、打ち手が変わります。

Search Consoleは、全体傾向の把握と優先順位付けに向いています。まず不良URL群を洗い出し、次に代表URLを個別診断する流れがおすすめです。

⇒Search Consoleの使い方を整理したい場合は、Googleサーチコンソールとは?機能や設定方法、使い方などを初心者にわかりやすく解説も是非参照ください。

PageSpeed InsightsでURL単位の原因を掘る

PageSpeed Insightsは、1ページ単位でフィールドデータとラボデータを確認できるツールです。どの指標が悪いかだけでなく、改善候補まで見つけやすいのが利点です。

PageSpeed Insightで表示されるデータ

確認したい主な項目は以下です。

PageSpeed Insightsで特に見る項目
  1. LCP:主要コンテンツの表示速度
  2. INP:操作への応答性
  3. CLS:レイアウトの安定性
  4. TTFB:サーバー応答の初速
  5. TBT:JavaScript負荷の大きさを推測する補助指標

実務では、LCPが悪いのに画像最適化だけ見て終わる、INPが悪いのにサーバーだけ疑う、といった見誤りが起きがちです。PageSpeed Insightsでは、指標と原因候補をセットで見ることが重要です。

⇒PageSpeed Insightsの詳細は、PageSpeed Insights(ページスピードインサイト)の使い方と表示速度の改善方法で詳しく解説しています。

Lighthouseで改修前後を比較する

Lighthouseは、開発中や改修後の確認に向いています。ローカル環境やステージングでも使いやすく、変更の影響を素早く見られます。

Lighthouseを使った計測画面

ただし、Lighthouseはラボデータ中心です。実ユーザーの通信環境や端末差までは反映しきれないため、最終判断はSearch ConsoleやPageSpeed Insightsのフィールドデータと合わせて行うのが安全です。

実務での使い分けとしては、Lighthouseは「改修前後の差分確認」、フィールドデータは「本番環境での判定」と役割を分けるのがおすすめです。Lighthouseでスコアが改善しても、フィールドデータは過去28日間の実利用データで集計されるため、反映には数週間かかります。改修直後にフィールドデータが変わらなくても焦らず、ラボデータで方向性を確認しつつ実データの反映を待つ進め方が現実的です。
(参照:Web Vitals - web.dev

Chrome拡張のWeb Vitalsでその場確認する

Web Vitals拡張は、閲覧中のページで指標をざっくり確認したいときに便利です。競合ページを見ながら体感と数値を照らし合わせる用途にも向いています。

Web Vitalsで計測できるスコア

ただし、簡易確認用と考えたほうがよく、改善判断の根拠はSearch ConsoleやPageSpeed Insightsに置くのが無難です。

コアウェブバイタルの改善方法

改善の基本は、指標ごとに原因を切り分け、テンプレート単位で直すことです。1ページずつ場当たり的に対応すると、同じ問題が別URLで再発しやすくなります。

LCPを改善する方法

LCP改善では、ファーストビューの主要要素を早く出すことが最優先です。特に効きやすいのは以下です。

LCP改善で優先したい施策
  • ファーストビュー画像を圧縮し、適切なサイズで配信する
  • 不要なJavaScriptとCSSを減らす
  • サーバー応答を改善する
  • 重要コンテンツをCSR任せにしすぎない
  • CDNやキャッシュを活用する

たとえば、記事上部のメイン画像を横2000px超のまま配信しているなら、まず適正サイズ化の効果が大きいです。BtoBサイトでも、トップページのKV画像だけで数百KBから数MBになっていることは珍しくありません。

また、レンダリング方式も重要です。JavaScriptで後から主要コンテンツを組み立てる構成は、LCPを悪化させやすいです。情報ページや記事ページでは、SSRや静的生成のほうが安定しやすいケースがあります。

INPを改善する方法

INP改善では、ユーザー操作の直後に重い処理を走らせないことが重要です。特に見直したいのはJavaScriptの量と実行タイミングです。

INP改善で見直したいポイント
  • 不要なJavaScriptライブラリを削減する
  • サードパーティタグを整理する
  • 重い処理を分割し、メインスレッド占有を減らす
  • 初回表示に不要なスクリプトを遅らせる
  • フォームや絞り込み機能のイベント処理を軽くする

実務で多いのは、マーケティング施策を積み上げた結果、タグが増えすぎているケースです。広告計測、チャット、レコメンド、ヒートマップ、同意管理が重なると、ページ自体は表示されていても押した後の反応が鈍くなります。

当社でもフォーム改善の場面では、見た目より先に入力補助スクリプトや外部タグの実行順を見直すことがあります。ボタン色を変えるより、押した瞬間に反応する状態を作るほうが成果に直結しやすいためです。

CLSを改善する方法

CLS改善では、後からサイズが確定する要素を減らすことが基本です。画像、動画、広告、埋め込み、バナーの扱いを統一すると改善しやすくなります。

CLS改善で効果が出やすい施策
  • 画像とiframeにwidth・heightまたはアスペクト比を指定する
  • 広告枠の予約領域を確保する
  • 上部への後挿入バナーを減らす
  • Webフォントの表示戦略を見直す
  • 埋め込みSNSや地図の表示サイズを固定する

たとえば、ECで商品詳細の下にレビューウィジェットを後読み込みしている、店舗ページで地図埋め込みの高さがCSS依存で不安定、といったケースは改善余地が大きいです。

このセクションで特に伝えたいのは、CLSはデザインの問題というより運用ルールの問題になりやすいことです。画像サイズの指定方法、広告枠の扱い、埋め込みパーツのテンプレート化が曖昧だと、更新を重ねるほど再発します。ページ単位の修正だけで終わらせず、CMSや制作ガイドラインまで揃えることが現実的です。

⇒画像の最適化を進めたい方は、画像におけるSEO対策とは?メリットや最適化する8つの方法、注意点を詳しく解説もあわせてご覧ください。

コアウェブバイタル以外に一緒に見たいページ体験の要素

コアウェブバイタルだけ整えても、ページ体験全体が良いとは限りません。検索評価やユーザー満足を考えるなら、周辺要素もあわせて確認する必要があります。

モバイルで読みやすいか

スマホで文字が小さい、表がはみ出す、重要情報が折りたたみの奥にある、といった状態では体験が落ちます。特にBtoC領域では、モバイルの最初の1画面で読めるかどうかが重要です。

⇒モバイル対応については、モバイルフレンドリーとは?SEO対策で必要な理由や確認・対応方法も参考にしてみてください。

HTTPSで安全に配信できているか

HTTPSは基本要件です。フォームや決済だけでなく、サイト全体で安全に配信されているかを確認しましょう。混在コンテンツが残っていると、一部リソースだけ安全でない状態になることがあります。

⇒HTTPSの考え方は、SSL化(HTTPS)のSEO対策における効果で整理しています。

広告やポップアップが本文を邪魔していないか

画面全体を覆うポップアップ、閉じにくいバナー、本文の直前に差し込まれる大型広告は、体験を大きく損ねます。特にモバイルでは、閉じる操作そのものがストレスになります。

メインコンテンツが分かりやすいか

本文と広告、関連記事、CTAの境界が曖昧だと、ユーザーは読みたい情報に集中しにくくなります。ページ体験は速度だけではなく、情報の見つけやすさも含めて考えることが大切です。

改善を進める実務フロー

最短で成果につなげるなら、全ページを均等に触るのではなく、影響の大きいURL群から進めるべきです。おすすめの流れは次の通りです。

コアウェブバイタル改善の進め方
  1. Search Consoleで不良URL群を把握する
  2. 代表URLをPageSpeed Insightsで診断する
  3. LCP・INP・CLSのどれが主因か切り分ける
  4. テンプレート、タグ、画像運用のどこに原因があるか整理する
  5. 改修後に再計測し、実データの反映を待つ

ここで大切なのは、公開直後に数値が変わらなくても慌てないことです。Search Consoleの反映には時間差がありますし、フィールドデータは一定期間の実利用データで評価されます。修正後すぐに結論を出すのではなく、代表ページのラボデータ確認と、後日の実データ確認を分けて考えると判断しやすいです。

よくある質問

コアウェブバイタルはSEOに必須ですか?

必須というより、検索評価とユーザー体験の両方に関わる重要項目です。内容の質が前提ですが、競合との差が小さい場面では無視しにくい要素です。

2026年でもFIDを見ればよいですか?

いいえ。2026年時点では、操作性の主要指標はINPです。古い資料のFID中心の見方は更新したほうがよいでしょう。

PageSpeed Insightsの点数が低いと順位は下がりますか?

点数だけで順位が決まるわけではありません。重要なのは、実ユーザー体験に近い指標で不良状態が続いていないかを確認することです。

まず何から改善すべきですか?

Search Consoleで不良URL群を確認し、流入やCVに近い重要ページから着手するのがおすすめです。全ページを一度に直すより、影響の大きいテンプレートから進めるほうが効率的です。

コアウェブバイタルは開発チームだけの課題ですか?

いいえ。画像運用、広告配置、埋め込みルール、タグ追加の判断など、マーケティングや編集の運用も大きく関わります。開発だけに任せると再発しやすいです。

まとめ

コアウェブバイタルは、ページの速さだけでなく、読める・押せる・ずれないという体験を数値で確認するための指標です。2026年時点では、LCP・INP・CLSの3つを正しく理解し、Search ConsoleとPageSpeed Insightsを軸に改善を進めることが重要です。

SEOではコンテンツ品質が前提ですが、体験面の弱さが足を引っ張る場面は少なくありません。まずは不良URL群の把握から始め、テンプレート単位で原因を直していくと進めやすいでしょう。

コアウェブバイタルは単発の点検ではなく、更新運用の中で崩れやすい領域です。内部対策全体もあわせて見直したい方は、以下のページも是非ご覧ください。