コアウェブバイタルを改善する手順｜3指標の意味と計測方法

コアウェブバイタル（Core Web Vitals）は、Googleがページの体験品質を評価する3つの指標です。スコアが低いとSEO（検索エンジン最適化）の順位に直接影響するため、Web担当者なら押さえておきたい知識のひとつです。

本記事では、3指標の意味と計測ツールの使い方、スコアを改善する具体的な手順をまとめています。「何から手をつければいいかわからない」という方でも、読み終えれば自サイトの現状確認と改善の優先順位が整理できます。

コアウェブバイタル（Core Web Vitals）とは

コアウェブバイタルとは、LCP・INP・CLSの3指標でユーザー体験を数値化するGoogleの評価基準です。Googleが定める「ページエクスペリエンス」を構成するシグナルのひとつとして位置付けられ、2021年6月に検索ランキング要因として正式に導入されました。

「読み込み速度」「操作への応答性」「視覚的安定性」という3つの側面からサイトのUX（ユーザー体験）を定量的に評価します。単なる技術指標ではなく、実際に検索順位へ影響するため、Web担当者が押さえておくべき重要な基準です。

Googleは「Web Vitals」という上位概念のもと、ウェブサイトの品質を測る複数の指標を定義しています。その中でもすべてのサイト運営者が対応すべき中核指標として絞り込まれたのが、コアウェブバイタルです。Web Vitals全体には、FCP（最初のコンテンツ描画）やTTFB（最初のバイトまでの時間）といった補助指標も含まれます。ただし検索評価で直接参照されるのはコアウェブバイタルの3指標であり、優先的に対応する価値があります。

Googleは公式ドキュメントの中で「コアウェブバイタルで良好なスコアを達成することを強く推奨する」と明記しています。補助指標の改善も大切ですが、まずはこの3指標を優先しましょう。

コアウェブバイタルは、ユーザーがページを訪問したときの体験を3つの側面から評価します。それぞれが異なるUX上の問題を可視化する指標です。

指標	測る内容	良好の目安
LCP	読み込み速度（主要コンテンツの表示時間）	2.5秒以内
INP	操作応答性（クリック・タップへの反応速度）	200ms以内
CLS	視覚的安定性（レイアウトのズレの少なさ）	0.1以下

INPは2024年3月に旧指標FIDから置き換わった新しい指標です。より実態に近いインタラクション全体の応答性を測定します。(出典: Google Search Central Blog – INPをCore Web Vitalsに導入)

(出典: Google Search Central – Understanding Core Web Vitals and Google search results)

コアウェブバイタルを構成する3つの指標と判定基準

3つの指標はすべて「Good（良好）／Needs Improvement（改善が必要）／Poor（不良）」の3段階で評価されます。Googleは実ユーザーデータ（CrUX：Chrome User Experience Report）の75パーセンタイル値を基準に判定しており、全ページビューの75%以上がGoodでなければ合格になりません。

3指標のうち1つでもPoorまたはNeeds Improvementがある場合、サイト全体のコアウェブバイタル評価は不合格になります。各指標の仕組みと閾値を正確に把握しておきましょう。

LCP（Largest Contentful Paint）：読み込み速度の指標

LCPは、ビューポート内で最も大きなコンテンツ要素（ヒーロー画像・見出しテキスト・動画サムネイルなど）が画面に描画されるまでの時間を計測します。ユーザーが「ページが読み込まれた」と体感するタイミングに最も近い指標です。

評価	閾値
Good（良好）	2.5秒以内
Needs Improvement	2.5〜4秒
Poor（不良）	4秒超

LCPの対象となる要素はPageSpeed Insightsの「LCP要素の特定」セクションで確認できます。モバイルでの合格率は約59〜62%と、3指標の中で最も合格が難しい指標です。

LCPが遅くなる主な原因は、サーバー応答時間（TTFB）の遅さ、レンダリングブロックするCSS・JavaScript、ヒーロー画像の未最適化、クライアントサイドレンダリングへの過剰依存です。

INP（Interaction to Next Paint）：操作応答性の指標

INPは、ページ滞在中に発生したクリック・タップ・キーボード入力のすべての操作に対する応答時間のうち、最も遅い操作（外れ値は除外）を代表値とする指標です。操作を受け付けてから「次のフレームが描画される」までの時間を測定します。

評価	閾値
Good（良好）	200ミリ秒以内
Needs Improvement	200〜500ミリ秒
Poor（不良）	500ミリ秒超

デスクトップでの合格率は約97%と高い一方、モバイルでは約74%まで低下します。JavaScriptによるメインスレッドの長時間ブロックや重いイベントハンドラー、サードパーティスクリプトの大量読み込みが主な悪化原因です。

「視覚的フィードバックが表示される」までの時間を測る点がポイントです。ボタンを押した後、画面に何も変化がないと感じる状態がINPの悪化として数値に表れます。

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

CLSは、ページのライフスパン全体を通じて発生した予期せぬレイアウトシフトの合計スコアです。0が最良で、数値が大きいほどシフトが多いことを示します。スコアは「影響を受けた要素のビューポートに対する割合（Impact Fraction）×移動した距離のビューポートに対する割合（Distance Fraction）」で算出されます。

評価	閾値
Good（良好）	0.1以下
Needs Improvement	0.1〜0.25
Poor（不良）	0.25超

モバイルでの合格率は約79〜81%と、3指標の中で最も合格しやすい指標です。ただし、広告バナーやCookieバーの動的挿入、サイズ未指定の画像・iframeタグ、Webフォント切り替え時のテキストサイズ変動は代表的な悪化原因のため注意が必要です。

指標は変更される可能性がある：FIDからINPへの移行を例に

コアウェブバイタルの指標は固定ではなく、Googleは随時見直しを行っています。直近の大きな変更が、2024年3月12日に実施されたFIDからINPへの移行です。

FID（First Input Delay）は「最初のインタラクションの遅延のみ」を測定していましたが、INPは「ページ滞在中のすべての操作」を対象とするため、より厳格でユーザー体験の実態に近い指標です。Googleは2023年5月に移行を発表し、約1年の移行期間を設けました。Google Search ConsoleのCore Web VitalsレポートもFIDの表示を停止し、INPに切り替え済みです。

指標は今後も変更される可能性があります。Googleの公式アナウンスを継続的にチェックし、最新の基準に合わせて対策を見直す姿勢が重要です。

(出典: Google Search Central – Core Web Vitals / Google Search Central Blog – Introducing INP to Core Web Vitals)

コアウェブバイタルがSEO・検索順位に与える影響

コアウェブバイタルはGoogleのランキング要因として公式に認められています。ただし「影響はあるが過大評価は禁物」というのが正確な認識です。コンテンツの関連性・品質・被リンクが依然として最重要であり、コアウェブバイタルはあくまでセカンダリシグナルに位置します。

コアウェブバイタルはGoogleのランキング要因のひとつ

Googleは公式ドキュメントで「コアウェブバイタルはランキングシステムで使用されており、ページエクスペリエンスとして評価される」と明記しています。2024年3月にドキュメントが更新され、その位置づけがより明確になりました。

ただし、ランキングへの反映にはいくつかの重要な前提があります。

• 対象はフィールドデータ（実ユーザーデータ＝CrUX）のみ
• PageSpeed InsightsのスコアやLighthouseのラボデータはランキングに直接影響しない
• 使用データはAndroid版ChromeとChrome for Desktopのみ（iOS版Chromeは対象外）
• 28日間のローリングウィンドウで集計されるため、改善後の反映に約28日かかる
• モバイルとデスクトップはそれぞれ独立して評価される

PageSpeed Insightsで高スコアを出しても、フィールドデータが改善されなければランキングには反映されません。実ユーザーの体験データに目を向けることが重要です。

順位への直接的な影響はわずか：コンテンツ品質が優先される理由

GoogleのJohn Mueller氏（Google Search Advocate）は2024年に「コアウェブバイタルはランキングにおいて大きな要因ではない」と明言しています。さらに「コンテンツの関連性はコアウェブバイタルよりもはるかに重要で、サイトが速いだけで1位になれるわけではない」とも述べています。

また、Googleは2023年4月にページエクスペリエンスシグナルの扱いを「単一の明示的シグナル」から「コアランキングシステムによる総合評価」へと変更しました。

「Good」評価を達成したあと、さらにスコアを上げても追加のSEO効果はありません。コンテンツが薄いページはコアウェブバイタルが良好でも上位表示されないケースが多く、あくまで「Goodに到達すること」がゴールです。

コンテンツ品質が同等のとき、スコアが高いサイトが有利になる仕組み

競合ページ間でコンテンツの質・被リンクが同等の場合、コアウェブバイタルは「タイブレーカー」的な役割を果たします。特に「Poor」評価から「Good」評価への改善が、ランキングへの影響が最も大きいとされています。「Good」の範囲内での細かい最適化は影響が限定的です。

また、モバイル検索ではスコアの影響が相対的に大きくなる傾向があります。多くのサイトでモバイルのスコアが低いため、改善による差別化効果が出やすいためです。

コアウェブバイタルの改善はSEO以外にも、直帰率の低下やCVR（コンバージョン率：訪問者のうち目標を達成した割合）の向上といった副次効果が期待できます。ランキング改善とUX改善を同時に実現できる指標として位置づけると、投資対効果が高まります。

(出典: Google Search Central – Understanding Core Web Vitals and Google search results)

コアウェブバイタルのスコアを計測・確認する方法

計測ツールは大きく「フィールドデータ（実ユーザーデータ）」を測るものと、「ラボデータ（シミュレーション）」を測るものの2種類に分かれます。SEOのランキング評価に影響するのはフィールドデータのみです。ラボデータはあくまで原因特定や改善検証の補助として使います。

基本的な使い分けは「サイト全体の状況把握はGoogle Search Console、URLごとの詳細分析はPageSpeed Insights」です。それぞれの役割を理解したうえで、状況に応じてツールを組み合わせていきましょう。

Google Search Console：サイト全体を継続監視する

Google Search Console（グーグルサーチコンソール）は、サイト全体のCWV状況を定点観測するのに最適なツールです。実ユーザーのデータが蓄積されるため、改善施策の前後変化をモニタリングするのにも適しています。

「ウェブに関する主な指標」レポートでは、LCP・INP・CLSの状況をモバイル／デスクトップ別に確認できます。データは過去28日間の実ユーザー計測値（CrUX）を75パーセンタイルで集計したもので、Googleのランキング評価に直結するデータです。URLは「良好」「改善が必要」「低速」の3区分でグループ分けして表示されます。グラフで時系列のトレンドを確認できるため、施策の効果が数値として見えやすいのも特徴です。

CrUX（Chrome User Experience Report）とは、Chromeユーザーの実際のページ表示速度を集計したGoogleのデータベースです。統計情報の送信に同意したユーザーのみが対象となります。

「改善が必要」または「低速」のグループをクリックすると、該当URLの一覧と代表URLが確認できます。URLグループとは、同じ構造のページ（記事ページ群・商品ページ群など）をGoogleが自動でまとめたものです。問題のあるURLグループを特定したら、代表URLをPageSpeed InsightsやLighthouseでさらに詳細分析します。これが推奨される基本の流れです。

Search ConsoleはURLグループ単位で集計するため、PageSpeed Insightsで個別URLを計測した値と異なる場合があります。これはツールの仕様であり、異常ではありません。

(出典: Google Search Console ヘルプ – Core Web Vitals レポート)

PageSpeed Insights：URLごとの詳細スコアを確認する

PageSpeed Insights（ページスピードインサイツ、以下PSI）は、特定のURLを入力するだけでフィールドデータとラボデータの両方を一画面で確認できるツールです。改善が必要な指標を絞り込む際に役立ちます。

フィールドデータは、過去28日間に実際にそのURLを閲覧したChromeユーザーから収集した実測値です。SEOの評価に直結するのはこちらです。一方ラボデータは、Lighthouseが事前設定された端末・ネットワーク環境でシミュレーションした計測値で、再現性が高く原因特定に活用します。「ラボデータで高スコアでもフィールドデータが悪い」という乖離はよく起こります。実ユーザーのデバイス・回線・スクロール操作などが多様なためです。また、アクセスが少ないページではデータ量不足のためフィールドデータが表示されない場合もあります。

PSIはCrUXをフィールドデータのソースとして使用しています。フィールドデータとラボデータの乖離が起きやすい理由については、Googleも公式ドキュメントで解説しています。(出典: web.dev – Why lab and field data can be different)

PSIの0〜100の「パフォーマンススコア」はLighthouseのラボデータに基づく加重スコアです。このスコア自体はSEOに直接影響しません。SEO上で重要なのは、画面上部の「フィールドデータ」セクションに表示されるCWVの合否（Good／Needs Improvement／Poor）です。改善の優先順位は、フィールドデータで「Poor（低速）」と判定されている指標から対応するのが原則です。複数の実務ガイドでは「TTFB改善→LCP改善→INP改善→CLS改善」の順が効率的とされています。

(出典: PageSpeed Insights について（Google for Developers）)

Lighthouse：ローカル環境でパフォーマンスを診断する

Lighthouseは、Chrome DevToolsに内蔵されているラボデータ計測ツールです。URLを指定するだけで詳細なパフォーマンス診断レポートを生成できます。

改善施策の効果を素早く検証するのに特に役立ちます。フィールドデータは更新に約28日かかるのに対して、Lighthouseであれば実装直後に即時確認が可能です。また、Lighthouseのスコア自体はランキング要因ではないため、あくまで「改善の手応えを確かめる道具」として活用しましょう。

TBT（Total Blocking Time）とは、メインスレッドが長時間ブロックされる合計時間です。ラボ環境でのINP代替指標として活用されています。

Chrome拡張「Web Vitals」：リアルタイムで数値を把握する

Googleが公式提供するChrome拡張機能「Web Vitals」を使うと、実際のページ閲覧中にLCP・INP・CLSの値をリアルタイムで確認できます。インストールするだけで使えるため、手軽に計測を始めたい方に最適です。

• ページをスクロールしながらCLSの発生箇所を目視確認できる
• 実ユーザーに近い操作をしながらINPの値を確認できる

Chrome DevTools／CrUX：補助ツールとしての活用場面

Chrome DevToolsの「Performance」タブでは、操作中の長いタスク（Long Task）を特定できます。INPの原因となるJavaScript処理をピンポイントで発見するのに有効です。

CrUXはBigQueryやCrUX APIを通じて公開されており、競合サイトのフィールドデータとの比較にも活用できます。また、Google Search Consoleのレポートにある「PageSpeed Insightsで開く」リンクを使えば、URLグループから直接PSI分析に遷移できるため、調査の手間を省けます。

ツール	データ種別	対象範囲	主な用途
Google Search Console	フィールド（実ユーザー）	サイト全体	継続監視・改善効果確認
PageSpeed Insights	両方	URL単位	詳細スコア確認・原因特定
Lighthouse	ラボ（シミュレーション）	URL単位	ローカル診断・改善検証
Chrome拡張 Web Vitals	フィールド（実ユーザー）	閲覧中ページ	リアルタイム数値把握

コアウェブバイタルの改善方法：指標別の具体的な対策

改善は「原因特定 → 施策実施 → フィールドデータで効果確認（約28日後）」のサイクルで進めます。効率的な順序はTTFB → LCP → INP → CLSの順が推奨されています。上流を改善するほど下流の指標にも波及するためです。

また、3指標すべてでGoodを達成しないと「合格」になりません。1つでも不合格であれば全体不合格となる点を念頭に置いて取り組みましょう。

LCPの改善方法

LCP（Largest Contentful Paint）の遅延は、主に「画像の重さ」「サーバーの応答遅延」「レンダリングを止めるリソース」の3つが原因です。それぞれを順番に潰していくことで、効率よくスコアを改善できます。

画像の最適化（フォーマット変換・遅延読み込みの見直し）

ヒーロー画像が未圧縮のPNG・JPEGのままだと、ファイルサイズが大きくなりLCPを直接悪化させます。WebPまたはAVIF形式に変換するだけで、ファイルサイズを30〜50%削減できるとされています。

読み込みの優先度設定も重要です。LCP要素となる画像に loading="lazy" を付けると、ブラウザが意図的に読み込みを後回しにしてしまいます。ファーストビュー内の画像にはおすすめしないでください。

<img> タグに fetchpriority="high" を追加すると、ブラウザに優先読み込みを明示的に指示できます。合わせて <link rel="preload"> をHTMLヘッダーに記述すれば、より早いタイミングで画像の取得を開始できます。

サーバー応答時間（TTFB）の短縮

TTFB（Time to First Byte：最初の1バイトが届くまでの時間）は、LCPの「床」になります。TTFBが800msであれば、LCPは最速でも800ms以上にしかなりません。

まずCDN（コンテンツデリバリーネットワーク）を導入し、ユーザーに近いエッジサーバーからコンテンツを配信する設定にしましょう。WordPressの場合はWP Super CacheやW3 Total CacheなどのプラグインでページキャッシュをONにすることが有効です。

TTFBが600ms以上の場合はサーバー環境自体の見直しが必要です。低スペックな共有ホスティングではプラグイン最適化だけでは限界があり、ホスティングプランのアップグレードを検討してください。

レンダリングブロックリソースの排除

HTMLの上部に配置されたCSSやJavaScriptは、ブラウザが読み込みを完了するまでページの描画を止めます。この「レンダリングブロック」がLCPを遅らせる大きな原因の一つです。

JavaScriptタグには defer または async 属性を付与し、描画処理をブロックしない形にしましょう。CSSについては、ファーストビューに必要な最小限のスタイルのみをインライン化（クリティカルCSS）し、残りは非同期で読み込む構成が効果的です。

不要なプラグインやサードパーティスクリプトを削除・統合してHTTPリクエスト数を減らすことも、レンダリング速度の改善に直結します。

INPの改善方法

INP（Interaction to Next Paint）が悪化する根本原因は、JavaScriptがメインスレッドを長時間占有することです。ユーザーがクリックやタップをしても、メインスレッドが塞がっていると応答できなくなります。

JavaScriptの実行時間を削減する

最初に確認すべきは、不要なJavaScriptが読み込まれていないかです。使っていないライブラリやプラグインを削除・無効化するだけで、大きく改善するケースがあります。

チャットウィジェットやリターゲティングピクセル、A/BテストツールなどのサードパーティスクリプトはINPに大きく影響します。最初のユーザー操作後に遅延読み込みする設定にするだけで、初期インタラクションの応答速度が向上します。

ReactやVue、AngularなどのSPA（シングルページアプリケーション）を使う場合、ハイドレーション処理（サーバーで生成したHTMLをクライアントサイドで再アクティブ化する処理）が適切でないとINPが悪化しやすいため、フレームワーク固有の最適化も検討してください。

長いタスクを分割してメインスレッドの詰まりを解消する

50ms超のJavaScript処理（Long Task）が発生している間、ブラウザはユーザーの操作に一切応答できません。Chrome DevToolsのPerformanceパネルで操作を記録し、赤くハイライトされているLong Taskを特定するのが最初のステップです。

50ms超の処理関数は小さな単位に分割し、scheduler.yield()（Chrome 129以降でサポート）などでメインスレッドに処理を返すことで、操作への応答を割り込めるようにします。また、重い計算処理はWeb Workerに移してメインスレッドの負荷を下げる方法も有効ですが、実装難易度が高いため上級者向けの対応策です。

UIの視覚的なフィードバック（ボタンの色変化やローディング表示など）を先行させ、重い処理は後続で実行する設計にするだけでも、体感的な応答速度を大きく改善できます。

CLSの改善方法

CLS（Cumulative Layout Shift）は「ページを読んでいたら突然コンテンツがずれた」という現象の指標です。原因のほとんどはサイズ未指定のリソースや、後から挿入されるコンテンツにあります。

画像・動画に width / height を明示する

サイズ指定のない <img> や <iframe> は、読み込みが完了した瞬間にブラウザがレイアウトを再計算し、周囲のコンテンツがずれる原因になります。すべての画像・iframeタグに width と height 属性を明示するだけで、多くのCLS問題は解消されます。

CSSの aspect-ratio プロパティで縦横比を事前に確保する方法も有効です。この施策はCLS改善策の中でも最もコストパフォーマンスが高く、真っ先に取り組む価値があります。

広告・埋め込みコンテンツの表示領域を事前に確保する

広告バナーやCookieバー、SNSの埋め込みコンテンツが後から挿入されると、既存のコンテンツ全体が押し下げられて大きなレイアウトシフトが発生します。

広告スロットにはCSSで min-height を設定し、表示領域を事前に確保してください。CookieバーやPR通知バナーは position: fixed で画面下部に固定表示するなど、既存コンテンツを動かさない実装にしましょう。YouTubeなど遅延読み込みするiframeも、アスペクト比を指定してスペースを確保しておくことが重要です。

Webフォントの読み込み方を最適化する

Webフォントの読み込み中、ブラウザはフォールバックフォントで表示します。Webフォントの読み込みが完了するとフォントが切り替わり、テキストサイズが変わることでレイアウトシフトが発生します。

font-display: swap を設定すると、フォント読み込み中もフォールバックフォントで表示し続けられ、FOIT（Flash of Invisible Text：テキストが一瞬消える現象）を防げます。より厳格にシフトを抑制したい場合は font-display: optional を使う選択肢もありますが、デザインへの影響を事前に確認してください。

Google Fontsを使用している場合は、URLに display=swap パラメータを追加するだけで font-display: swap が適用されます。また <link rel="preload"> でフォントファイルを事前読み込みすれば、フォント切り替えのタイムラグをさらに最小化できます。

(出典: Google Search Central「Understanding Core Web Vitals and Google search results」、web.dev「Core Web Vitals」)

改善時に確認すべき注意点

数字が改善されたように見えても、実態と乖離しているケースは少なくありません。「特定の環境しか改善されていない」「別の指標を悪化させている」という落とし穴を知っておくことで、改善施策の精度と効率を大幅に高められます。

ラボデータとフィールドデータの乖離に注意する

よくある誤解が「Lighthouseでほぼフルスコアだからコアウェブバイタルは合格している」という思い込みです。ラボデータで95点でも、フィールドデータではCWVが不合格という状況はよく起きます。実ユーザーの端末性能・回線品質・スクロール操作・サードパーティスクリプトの状況がそれぞれ異なるためです。

CLSは特にこの乖離が起きやすい指標です。ページをスクロールしながら発生するレイアウトシフト（ページ下部の埋め込みコンテンツなど）はLighthouseが検出しにくく、「ラボデータ上は0なのにフィールドデータではシフトが発生している」という事例が多く報告されています。

また、フィールドデータはCrUX（Chrome User Experience Report）の28日間のローリングウィンドウで集計されます。改善施策を実施してから数値に反映されるまで最大約28日かかるため、「すぐ変わらない」ことをチームに事前共有しておくことが重要です。

推奨する効果検証フロー：Lighthouseのラボデータで素早く変化を確認→Search Consoleのフィールドデータで約28日後に実際の改善を確認、という2段階で検証するのが効果的です。

モバイルとPCでスコアが大きく異なる場合の優先順位

Google Search ConsoleはモバイルとデスクトップのCWVを独立して評価しており、検索ランキングへの影響もデバイス別に及びます。多くのサイトでモバイルのスコアはデスクトップより大幅に低く、「デスクトップは合格・モバイルは不合格」というサイトは決して少なくありません。Search Consoleではぜひデバイス別に確認する習慣をつけましょう。

モバイルでGoogle検索を行うユーザーが多数を占める現状では、モバイルのCWV改善を優先することが推奨されます。特にINPはモバイルで悪化しやすい傾向があります。スマートフォンのCPU処理能力はデスクトップより低く、JavaScriptによるメインスレッドのブロックが大きく影響するためです。

まずSearch Consoleのコアウェブバイタルレポートをデバイス別に開き、モバイルで「不合格」URL数が多い指標から着手するのが効率的です。

改善施策がほかのスコアに悪影響を与えていないか確認する

1つの指標を改善する施策が、別の指標を悪化させてしまう「副作用」には注意が必要です。LCP・INP・CLSの3指標はトレードオフ関係になることがあります。

これらの副作用を防ぐには、施策を段階的に実施して都度3指標すべてを再測定することが重要です。改善後はPageSpeed InsightsとLighthouseでLCP・INP・CLSのいずれかが悪化していないかを確認してください。

一度に複数の施策をまとめて実施すると、どの施策が副作用を生んでいるか特定が困難になります。1施策ずつ変更・測定・確認のサイクルを回すと原因の切り分けがしやすくなります。

モバイルフレンドリー

コアウェブバイタルは「ページエクスペリエンス」全体の中のひとつのシグナルに過ぎません。Googleはコアウェブバイタルに加えて、モバイルフレンドリー・HTTPS・インタースティシャルの3項目を合わせて総合的に評価しています。

コアウェブバイタルの数値を改善しても、これらの指標に問題があるとページエクスペリエンス全体の評価が下がる可能性があります。各項目をひとつずつ確認しておきましょう。

Googleはモバイルファーストインデックス（モバイル版コンテンツを優先してクロール・インデックスする仕組み）を採用しています。モバイルフレンドリーであることは、SEOにおいてもはや前提条件といえます。

確認はGoogle Search ConsoleのURL検査ツールから「モバイルユーザビリティ」を開くと、問題の有無をページ単位で確認できます。

主なチェック項目は次のとおりです。

• テキストサイズが読める大きさになっている
• タップターゲット（ボタン・リンク）が適切な間隔で配置されている
• 横スクロールが発生しない
• ビューポートメタタグが正しく設定されている

モバイルフレンドリーテストはGoogle Search Consoleのモバイルユーザビリティレポートで確認できます。エラーが出ている場合は優先的に対処しましょう。

HTTPS

HTTPSはGoogleのランキングシグナルとして公式に認定されています。HTTPのままのサイトはブラウザが「保護されていない通信」と警告を表示するため、ユーザーが離脱するリスクも高まります。

SSL/TLS証明書を取得してHTTPSへ移行することが必須です。Let’s Encryptのような無料証明書も広く使われており、費用面のハードルは下がっています。

HTTPからHTTPSへ移行する際は、以下の点に注意してください。

• HTTPページからHTTPSへの301リダイレクトを設定する
• 混在コンテンツ（Mixed Content）を解消する（画像・スクリプトなどがHTTPのまま残っていないか確認）
• Search ConsoleにHTTPSのプロパティを追加して再登録する

混在コンテンツが残っていると、HTTPSに移行してもブラウザが警告を表示する場合があります。移行後はブラウザの開発者ツールで確認しておくと安心です。

インタースティシャル

ページを開いた直後にメインコンテンツ全体を覆うポップアップや、閉じるボタンが見つけにくいオーバーレイ広告は、Googleのページエクスペリエンス評価においてネガティブ要因とされています。

一方、次のケースは許可されています。

• 年齢確認を目的としたインタースティシャル
• ログインが必要なコンテンツへの誘導
• 法的義務のあるCookie同意バナー（合理的なサイズのもの）

CookieバナーやメルマガのポップアップはCLS（レイアウトシフト）を悪化させるケースがあります。表示タイミングや配置を設計する段階で、CLSへの影響も合わせて確認することをおすすめします。

(出典: Google Search Central「Page experience in Google Search results」)

よくある質問

まとめ：コアウェブバイタルはUX改善とSEOを両立させる指標

ここまで解説してきた3指標の意味・計測手順・改善策を最後に整理します。スコアを追いかける前に「何のために改善するのか」をもう一度確認しておきましょう。

3指標の要点まとめ

コアウェブバイタルの合格条件は3指標すべてがGoodであることです。1つでも基準を満たしていなければ、全体として不合格になります。また判定に使われるのはLighthouseのラボデータではなく、実ユーザーの75パーセンタイルを集計したCrUX（Chrome UXレポート）データです。

各指標の基準と主な改善策を以下の表で確認してください。

指標	Good基準	主な改善策
LCP（最大コンテンツ表示速度）	2.5秒以内	画像最適化・TTFB短縮・レンダリングブロック排除
INP（操作応答速度）	200ms以内	JavaScriptの軽量化・Long Task分割
CLS（視覚的安定性）	0.1以下	画像・iframeへのサイズ明示・動的コンテンツの領域事前確保

計測・改善の進め方まとめ

闇雲に施策を打つより、問題の把握→原因特定→優先度付け→効果確認という流れを守ることが近道です。以下のステップを参考にしてください。

• Google Search Consoleでサイト全体の問題URLグループを把握する
• PageSpeed Insightsで問題URLの詳細を分析し、原因指標を特定する
• TTFB→LCP→INP→CLSの順に優先度をつけて施策を実施する
• 施策後、約28日後にSearch Consoleのフィールドデータで効果を確認する
• 3指標すべてでGoodを維持できているか継続的にモニタリングする

CrUXデータの反映には約28日かかります。施策直後にスコアが変わらなくても、焦らず一定期間データを蓄積してから効果を判断しましょう。

スコア改善はゴールではなく、UX向上の手段

コアウェブバイタルの本質は、数値を上げることではありません。ユーザーが実際に快適にページを使える状態をつくることが目的です。

指標が良好なサイトはSEO評価の向上にとどまらず、直帰率の低下・滞在時間の延長・CVR（コンバージョン率：問い合わせや購入などの目標達成率）の改善といったビジネス指標にも好影響を与えます。

ユーザー体験の改善とSEOの強化は、コアウェブバイタルを通じて同じ方向を向いています。どちらか一方のための施策ではなく、両方を同時に底上げする取り組みとして位置づけましょう。

なお、Googleはコアウェブバイタルの指標構成を今後も見直す可能性があります。Google Search Central「Core Web Vitals」やGoogle Search Central「Page experience」などの公式情報を定期的にウォッチしておくことをおすすめします。

SEOの技術的対策をさらに体系的に学びたい方は、テクニカルSEOとは何か｜施策・優先順位・ツールを解説もあわせてご覧ください。コアウェブバイタルを含むページエクスペリエンス全体の改善に役立つ情報をまとめています。