Core Web Vitals（コアウェブバイタル）は、ユーザーがページを「速く表示され、すぐ操作でき、ずれにくい」と感じられるかを確認するための指標です。現在はLCP・INP・CLSの3つで構成され、良好の目安はLCPが2.5秒以下、INPが200ミリ秒以下、CLSが0.1以下です。
ただし、3指標をすべて良好にしただけで検索順位が上がるわけではありません。SEOでは、検索意図に合う有用なコンテンツや、Googleがクロール・インデックスできる技術的な基盤を整えたうえで、ページ体験の明確な問題を減らすためにCore Web Vitalsを改善します。
実務では、まずGoogle Search Consoleで問題が多いURLグループを把握し、次にPageSpeed Insightsで個別ページの原因を調べる流れが効率的です。数値だけを追うのではなく、検索流入や成果に重要なページ、共通テンプレートから優先順位を付けて対応しましょう。
Core Web Vitalsの基準とSEOでの結論
Core Web Vitalsは、実際のユーザーによるページ表示を、表示速度・応答性・視覚的な安定性の観点から評価する指標です。各指標は、ページ読み込みの75パーセンタイル値で評価されます。
| 指標 | 測る内容 | 良好 | 改善が必要 | 不良 |
|---|---|---|---|---|
| LCP | 主なコンテンツが表示されるまでの速さ | 2.5秒以下 | 2.5秒超〜4.0秒以下 | 4.0秒超 |
| INP | 操作してから画面が反応するまでの速さ | 200ミリ秒以下 | 200ミリ秒超〜500ミリ秒以下 | 500ミリ秒超 |
| CLS | 予期しないレイアウト移動の大きさ | 0.1以下 | 0.1超〜0.25以下 | 0.25超 |
75パーセンタイルとは、計測対象となるページ読み込みのうち、75％がその値以下であったかを見る考え方です。たとえばLCPが2.5秒以下の閲覧が多くても、遅い通信環境や性能の低い端末を含めた75パーセンタイル値が4秒を超える場合、その指標は不良に分類されます。
SEOにおいてCore Web Vitalsはページ体験に関わる要素の一つですが、唯一の順位決定要因ではありません。内容の正確性、検索意図との一致、情報の見つけやすさなどが不足しているページは、速度だけを改善しても成果につながりにくいでしょう。まずは重要ページで、待たされる、タップしても反応しない、読んでいる途中で表示がずれるといった問題を減らすことが重要です。
出典：web.dev「How the Core Web Vitals metrics thresholds were defined」
出典：Google Search Central「Understanding page experience in Google Search results」
LCP・INP・CLSの評価基準と意味
LCP・INP・CLSは、いずれもユーザー体験に関わる指標ですが、測定対象は異なります。悪い体験の種類を分けて把握することが、効果的な改善の第一歩です。
LCP：主要コンテンツが表示されるまでの速さ
LCP（Largest Contentful Paint）は、表示領域内で最も大きな画像またはテキストブロックが描画されるまでの時間を示す指標です。記事ページでは、アイキャッチ画像、メインビジュアル、大きな見出しやテキストブロックなどがLCP要素になることがあります。
LCPは2.5秒以下が良好です。2.5秒を超えて4秒以下は改善が必要、4秒を超えると不良です。ただし、常に画像がLCP要素になるとは限りません。ページ構造、画面サイズ、表示順、ユーザー環境によって、判定される要素は変わります。
LCPが悪い場合は、画像ファイルの大きさだけで判断せず、サーバー応答、画像の読み込み開始タイミング、レンダリングを妨げるCSSやJavaScript、キャッシュ設定などを順に確認します。複数の原因が重なっていることも珍しくありません。
出典：web.dev「Optimize Largest Contentful Paint」
INP：操作してから画面が反応するまでの速さ
INP（Interaction to Next Paint）は、クリック、タップ、キー入力などを行ってから、画面上に反応が表示されるまでの応答性を測る指標です。メニューを開く、絞り込み条件を変更する、フォームを送信する、アコーディオンを展開するといった操作で反応が遅い場合に影響します。
INPは200ミリ秒以下が良好です。200ミリ秒を超えて500ミリ秒以下は改善が必要、500ミリ秒を超えると不良に分類されます。INPはページ滞在中の操作を対象に評価するため、ユーザーが感じる操作の重さを把握しやすい指標です。
以前はFID（First Input Delay）が応答性に関するCore Web Vitalsでしたが、2024年3月12日にINPが正式な指標となり、FIDを置き換えました。FIDは最初の入力までの待ち時間を中心に測るのに対し、INPは入力遅延、イベント処理、画面更新までを含めて評価します。古い記事やレポートを見る際は、FIDとINPを同じ基準で比較しないよう注意してください。
出典：web.dev「Advancing Interaction to Next Paint」
CLS：予期しないレイアウトのずれの大きさ
CLS（Cumulative Layout Shift）は、ページ表示中に要素が予期せず移動する度合いを示す指標です。記事を読もうとした瞬間に広告が表示されて本文が下へ押し出される、ボタンを押そうとしたら画像の読み込みで位置が変わる、といった体験が代表例です。
CLSは0.1以下が良好です。0.1を超えて0.25以下は改善が必要、0.25を超えると不良です。CLSは秒数ではなく、表示中の要素がどの程度、どれだけ移動したかを基にしたスコアです。そのため、時間を短縮するLCPやINPとは異なる観点で対処します。
主な原因には、サイズが未指定の画像・動画、表示領域が確保されていない広告枠や外部埋め込み、後から挿入されるバナー、Webフォントの切り替えなどがあります。ユーザー操作に対して意図的に表示を変える動きと、読み込みの都合で意図せず起きるレイアウト移動は分けて考える必要があります。
出典：web.dev「Optimize Cumulative Layout Shift」
Core Web VitalsはSEOにどう影響するか
Core Web VitalsはGoogle検索におけるページ体験に関わる要素ですが、良好判定だけで上位表示は保証されません。Googleは、良好なページ体験を提供することは重要である一方、それだけで検索結果の上位が保証されるわけではないと案内しています。
検索順位や自然検索からの成果を考える際は、少なくとも次の要素を並行して確認します。
- 検索意図に直接答える、有用で信頼できるコンテンツになっているか
- タイトル、見出し、本文の内容が検索語句と自然に対応しているか
- 重要ページがクロール・インデックス可能な状態か
- モバイルでも読みやすく、HTTPSで安全に提供されているか
- 広告、ポップアップ、過剰な装飾が主コンテンツの閲覧を妨げていないか
- 表示、操作、レイアウト移動に明確なストレスがないか
実務上は、同程度に役立つページが競合する場面ほど、ページ体験の差が成果に影響する可能性があります。一方で、内容が薄いページを高速化することより、ユーザーの疑問に正確かつ分かりやすく答えることを優先すべきケースも多くあります。Core Web VitalsはSEOだけの採点項目ではなく、離脱や操作ミスを減らすための改善指標として扱うと判断を誤りにくくなります。
出典：Google Search Central「Understanding page experience in Google Search results」
最初に確認する場所と数値の見方
Core Web Vitalsの確認では、サイト全体の問題発見と個別URLの原因調査を分けると効率的です。Search Consoleで対象を絞り、PageSpeed Insightsで掘り下げる流れを基本にしてください。
Search Consoleで改善対象を絞り込む
Google Search Consoleの「ウェブに関する主な指標」レポートでは、実際の利用状況に基づき、URLグループを「不良」「改善が必要」「良好」に分類して確認できます。モバイルとパソコンは別々に表示されるため、まずは不良になっている指標と、影響を受けているURLグループを把握します。
このレポートは、個別URLを一件ずつ採点するための一覧ではありません。似た構造・体験を持つURLをグループ化して表示する仕組みです。そのため、記事ページ、商品詳細ページ、カテゴリーページなど、共通テンプレートを使うページ群で同じ問題が起きている場合があります。
優先順位は、原則として不良から着手します。そのなかでも影響URL数が多い問題、検索流入やコンバージョンに重要なページ群、共通テンプレートでまとめて直せる問題を優先します。すべてのURLを個別に最適化しようとするより、原因が共通するグループを見つけるほうが効率的です。
出典：Google Search Console ヘルプ「Core Web Vitals report」
PageSpeed Insightsでフィールドデータとラボデータを使い分ける
PageSpeed Insightsでは、実ユーザーの利用状況を集計したフィールドデータと、一定条件でページを計測するラボデータの両方を確認できます。数値が異なることは珍しくなく、一方の数値だけで良否を断定しません。
| データ種別 | 特徴 | 主な使いどころ |
|---|---|---|
| フィールドデータ | 実際のChrome利用者の端末・回線・利用状況を反映した集計値 | ユーザー体験の傾向把握、改善後の確認 |
| ラボデータ | 固定されたテスト環境で計測する診断値 | 原因調査、修正前後の比較、開発時の検証 |
フィールドデータはChrome UX Report（CrUX）を基にした過去28日間のデータです。十分なデータがないURLでは、ページ単位ではなくオリジン単位のデータが表示されたり、フィールドデータ自体が表示されなかったりすることがあります。公開直後の新規ページやアクセスが少ないページでデータがない場合は、ラボデータを使って技術的な問題を調べます。
一方、ラボデータは特定の端末・ネットワーク条件での再現テストです。実ユーザーの多様な環境を完全には再現できないため、改善施策の診断には有用でも、検索上の評価確認をラボスコアだけで判断するのは適切ではありません。
出典：Google for Developers「About PageSpeed Insights」
モバイルとパソコンは分けて判断する
Core Web Vitalsの良好基準はモバイルとパソコンで共通ですが、実際の計測結果は分けて確認する必要があります。モバイルでは、端末の処理性能、通信品質、画面サイズの制約により、LCPやINPの問題が現れやすいことがあります。
ただし、モバイルの数値だけを機械的に最優先にする必要はありません。たとえばBtoBサイトでパソコンからの流入が大半であれば、パソコン側の問題も重要です。Search Consoleのデバイス別レポートとアクセス解析を照らし合わせ、重要なユーザーが使う環境から改善することが現実的です。
出典：Google Search Console ヘルプ「Core Web Vitals report」
LCP・INP・CLSが悪化する主な原因と改善の方向性
改善策は、診断結果を見ずに一律で適用するものではありません。同じLCP不良でも、画像、サーバー、CSS、JavaScriptなど原因は異なります。指標と実際のボトルネックを対応させることが重要です。
LCPは画像・サーバー応答・表示を妨げるリソースを確認する
LCPが悪いときは、まずPageSpeed Insightsやブラウザの開発者ツールで、LCP要素が何かを確認します。記事上部の大きな画像がLCP要素なら、表示領域に対して必要以上に大きなファイルを配信していないか、適切な画像形式や圧縮を使えているか、モバイル向けの画像サイズを用意できているかを見直します。
次に、初期表示を遅らせる要因を調べます。代表例は、サーバー応答の遅さ、不要に多いリダイレクト、レンダリングをブロックするCSSやJavaScript、LCP画像の読み込み開始が遅いことです。CDNやキャッシュの導入が有効なケースもありますが、サイト構成、更新頻度、会員機能の有無によって適した設定は異なります。
ファーストビューのLCP画像を遅延させないことも重要です。画像の遅延読み込みは画面外の画像を中心に適用し、主要コンテンツの表示を妨げていないか、変更後に計測して確認してください。
出典：web.dev「Optimize Largest Contentful Paint」
INPは長いJavaScript処理とイベント処理を見直す
INPが悪い場合は、ブラウザのメインスレッドを長時間占有するJavaScript処理を確認します。ユーザーがクリックしてもイベント処理を開始できない、イベント処理が重い、処理後に画面を更新するまで時間がかかる、といった状態がINP悪化につながります。
確認対象には、テーマやページビルダーが読み込むJavaScript、フォーム・絞り込み・検索機能の処理、アクセス解析や広告配信などの第三者スクリプト、不要なアニメーションがあります。操作直後に必要な処理を減らす、重い処理を分割する、画面表示に不要なスクリプトの必要性を再検討する、といった方向で改善します。
ただし、JavaScriptを単に遅延・削除すればよいわけではありません。メニュー、フォーム、購入ボタン、計測タグなどの機能が壊れたり、必要な処理が遅れたりする可能性があります。修正後は主要な操作を実機でも確認し、ラボデータとフィールドデータの両方で変化を追うことが大切です。
出典：web.dev「Optimize Interaction to Next Paint」
出典：web.dev「Optimize long tasks」
CLSは表示領域の確保と後から変わる要素を確認する
CLSの改善では、読み込み後に大きさが判明する要素や、後から追加される要素によって本文が押し動かされていないかを確認します。画像や動画には幅・高さ、または適切なアスペクト比を指定し、読み込み前から表示領域を確保します。
広告、SNS投稿、地図、動画プレーヤーなどの外部埋め込みもCLSの原因になりやすい要素です。サイズが変動する広告枠では完全にずれをなくせない場合もありますが、想定される枠を確保する、本文の途中に突然大きな要素を挿入しない、といった設計で影響を抑えられます。
Webフォントによる文字幅の変化も確認対象です。フォントの読み込み後に文字幅や行間が変わると、テキスト周辺のレイアウトが移動することがあります。フォールバックフォントとの見た目の差を小さくする、重要なフォントの読み込み方法を見直すなど、フォント表示も確認してください。
出典：web.dev「Optimize Cumulative Layout Shift」
WordPressサイトで優先して見直したいポイント
WordPressでは、テーマ、プラグイン、ページビルダー、広告タグ、外部サービスが積み重なり、表示や操作の負荷が増えることがあります。有効な機能数だけでは負荷を判断できません。
- 画像：アップロード原本が大きすぎないか、記事内で適切な画像サイズを使えているか、幅・高さが指定されているかを確認します。
- テーマ・ページビルダー：全ページで使われていないCSSやJavaScript、過剰なDOM構造、アニメーションが初期表示や操作を重くしていないかを確認します。
- プラグイン：不要な機能がフロント画面でスクリプトやスタイルを読み込んでいないか、同種の機能が重複していないかを確認します。
- 広告・計測タグ：広告枠のサイズ未確保、タグの過剰な読み込み、同一タグの二重設置がないかを確認します。
- 外部埋め込み：YouTube、Googleマップ、SNS投稿、チャットなどが初期表示時に必要か、埋め込み領域を確保できているかを確認します。
プラグインを減らすこと自体が目的ではありません。機能数が少なくても重い処理をするテーマや外部タグがあれば影響しますし、適切に実装されたプラグインが問題にならない場合もあります。ステージング環境がある場合は、変更前後でPageSpeed Insights、主要導線、フォーム送信、表示崩れを確認してから本番へ反映すると安全です。
改善の優先順位と効果確認の進め方
Core Web Vitalsの改善は、全ページを同時に完璧にしようとすると停滞しやすくなります。まずは影響が大きく共通化しやすい課題から進めてください。
- Search Consoleでモバイル・パソコン別に、不良または改善が必要の指標とURLグループを確認します。
- 検索流入、問い合わせ、購入、資料請求などに重要なページ群を選びます。
- PageSpeed Insightsで代表URLを調べ、フィールドデータの傾向とラボデータの診断を分けて確認します。
- 画像、テンプレート、JavaScript、広告枠など、複数ページに共通する原因を特定します。
- ステージング環境または限定範囲で修正し、表示・操作・計測タグ・コンバージョン導線に影響がないか検証します。
- 公開後はラボデータで明らかな後退がないかを確認し、フィールドデータの蓄積後に再評価します。
Search ConsoleやPageSpeed Insightsのフィールドデータは、過去28日間の実ユーザーデータを基にします。そのため、公開直後に改善結果が確定するわけではありません。Search Consoleで修正の検証を開始した場合も、一定期間のデータ収集と監視を経て、問題の再発がないかが確認されます。
改善後に数値がすぐ変わらないときは、変更内容だけでなく、対象URLに十分なアクセスがあるか、ページ単位ではなくURLグループやオリジンのデータを見ていないか、季節要因や広告配信の変化で利用環境が変わっていないかも確認しましょう。
出典：Google Search Console ヘルプ「Core Web Vitals report」
出典：Google for Developers「About PageSpeed Insights」
よくある質問
Core Web Vitalsについて、判断時に混同しやすい点を補足します。
すべて良好でなければSEOで不利になりますか？
必ずしもそうではありません。Core Web Vitalsはページ体験の重要な要素ですが、検索順位はコンテンツの関連性や有用性を含む多くの要素で決まります。ただし、不良の状態でユーザーが閲覧・操作しにくいなら、SEOだけでなく離脱や成果にも影響し得るため、重要ページから改善する価値があります。
PageSpeed InsightsのパフォーマンススコアとCore Web Vitalsは同じですか？
同じではありません。PageSpeed Insightsのパフォーマンススコアは主にLighthouseによるラボテストの指標であり、Core Web Vitalsの評価はLCP・INP・CLSのフィールドデータを基にします。ラボスコアと実ユーザー評価は別のものです。
フィールドデータがないページは改善できませんか？
改善できます。アクセスが少ない、公開直後であるなどの理由でフィールドデータがない場合は、PageSpeed Insightsのラボデータ、Chrome DevTools、Lighthouseなどを用いて原因を調べます。ただし、ラボ計測の結果を実ユーザー全体の評価と同一視しないことが大切です。
出典：Google Search Central「Understanding page experience in Google Search results」
出典：Google for Developers「About PageSpeed Insights」
Core Web Vitalsはユーザー体験を継続改善するための指標
Core Web Vitalsでは、LCPを2.5秒以下、INPを200ミリ秒以下、CLSを0.1以下にすることが良好の目安です。ただし、本来の目的はスコアを飾ることではなく、ユーザーが待たず迷わず操作できるページを作ることにあります。
SEO施策としては、良質なコンテンツ、検索意図との一致、適切なインデックス設定を前提に、Search Consoleで問題の大きいURLグループを把握し、PageSpeed Insightsで原因を調べる進め方が有効です。LCP・INP・CLSのどれが悪いかによって確認箇所を変え、重要ページと共通テンプレートから着実に改善していきましょう。
