「表示速度は問題ないはずなのに、なぜか検索順位が上がらない。」
そんな状況に心当たりがあるなら、Core Web Vitalsのスコアを確認してみてください。 2021年にGoogleがランキング要因として正式導入して以来、Core Web VitalsはテクニカルSEOにおいて避けて通れない指標になっています。
ただし、多くのサイト運営者が誤解しているポイントがあります。 Core Web Vitalsは「ページの表示速度」だけを測っているわけではありません。読み込み速度、操作への応答性、視覚的な安定性という3つの軸で、ユーザーが実際に体感する品質を数値化した指標です。
つまり、「速いだけ」では不十分。ボタンを押してからの反応が遅かったり、ページが読み込まれる途中でレイアウトがガクッとずれたりすれば、スコアは下がります。
この記事では、Core Web Vitalsの3指標（LCP・INP・CLS）の意味と改善方法を、具体的な数値目安とともに解説します。 どの指標から手を付けるべきかの優先順位や、測定ツールの使い分けまでカバーしているので、「何をどう改善すればいいのか分からない」という方は最後まで読んでください。
なお、SEO対策の全体像についてはSEO対策とは？初心者でもわかる完全ガイドで解説しています。 また、ページ速度の改善手法をより詳しく知りたい方はページスピード最適化ガイドもあわせて確認してください。
Core Web Vitalsとは？3つの指標を理解する
Core Web Vitalsとは、Googleが定義する「Webページのユーザー体験を定量的に測る3つの指標」のことです。
従来、ページの品質を測る指標はページ読み込み時間やTime to First Byte（TTFB）など多数ありましたが、Googleはその中から「ユーザーにとって本当に重要なもの」を3つに絞り込みました。 それが LCP、INP、CLS です。
この3指標は、それぞれ異なる側面のユーザー体験を測定しています。
| 指標 | 正式名称 | 測定対象 | 一言でいうと |
|---|---|---|---|
| LCP | Largest Contentful Paint | 読み込み速度 | メインコンテンツが表示されるまでの時間 |
| INP | Interaction to Next Paint | 操作への応答性 | ユーザーの操作に対する反応の速さ |
| CLS | Cumulative Layout Shift | 視覚的安定性 | ページ表示中のレイアウトのずれ |
2024年3月に、応答性の指標がFID（First Input Delay）からINP（Interaction to Next Paint）に正式に置き換わりました。 FIDは「最初の操作」だけを測定していましたが、INPはページ滞在中のすべての操作を対象にしています。より厳格で実態に即した指標に進化したということです。
なぜCore Web Vitalsが重要なのか
Core Web Vitalsが重要な理由は、大きく2つあります。
1つ目は、Googleのランキング要因だからです。 Core Web Vitalsは「ページエクスペリエンス」の一部としてランキングに影響します。もちろん、コンテンツの質や被リンクと比べれば影響度は小さいですが、競合と同水準のコンテンツ品質の場合、Core Web Vitalsのスコアが順位を左右する可能性があります。
2つ目は、ユーザーの行動に直接影響するからです。 Googleが公開しているデータによると、LCPが2.5秒以内のページは、4秒以上のページと比較してコンバージョン率が有意に高いと報告されています。 表示が遅いページからはユーザーが離脱し、レイアウトがずれるページではミスクリックが発生します。これらは数値として現れなくても、ビジネスの成果を確実に蝕んでいます。
各指標の合格ライン
Googleは各指標に「Good（良好）」「Needs Improvement（改善が必要）」「Poor（不良）」の3段階を設けています。
| 指標 | Good（良好） | Needs Improvement | Poor（不良） |
|---|---|---|---|
| LCP | 2.5秒以下 | 2.5秒〜4.0秒 | 4.0秒超 |
| INP | 200ms以下 | 200ms〜500ms | 500ms超 |
| CLS | 0.1以下 | 0.1〜0.25 | 0.25超 |
重要なのは、この数値は「ラボデータ（開発環境のテスト）」ではなく「フィールドデータ（実際のユーザーのデータ）」で判定されるということです。 自分のPCで測定したら高速でも、スマホの4G回線で見ているユーザーの実測値が悪ければ、Googleは「不良」と評価します。
ここを理解していないと、「PageSpeed Insightsでは90点なのに、Search Consoleでは不良と表示される」という状況に陥ります。
LCP・INP・CLSの改善方法
ここからは、各指標の具体的な改善方法を解説します。 技術的に深い話もありますが、「何を」「なぜ」やるのかを理解できれば、実装はエンジニアに依頼できます。
LCP（Largest Contentful Paint）の改善
LCPは、ビューポート内で最も大きなコンテンツ要素が表示されるまでの時間を測定します。 多くの場合、ファーストビューのメイン画像、ヒーロー画像、または大きなテキストブロックがLCPの対象になります。
LCPが遅くなる主な原因は4つです。
原因1: サーバーの応答が遅い（TTFB）
サーバーがHTMLを返すまでの時間（Time to First Byte）が遅ければ、その後のすべての処理が遅延します。 TTFBが800msを超えているなら、まずサーバー側の改善が必要です。
改善策としては、CDN（Content Delivery Network）の導入、サーバーのスペック増強、サーバーサイドのキャッシュ設定が有効です。 Next.jsやWordPressであれば、静的生成（SSG）やISR（Incremental Static Regeneration）を活用してサーバー処理を最小化するアプローチも効果的です。
原因2: レンダリングをブロックするリソース
CSSやJavaScriptの読み込みが、ページのレンダリングをブロックしている場合があります。
ブラウザはCSSを読み込み終わるまで画面を描画しません。巨大なCSSファイルや、<head>内に記述された同期的なJavaScriptは、描画を大幅に遅延させます。
改善策は以下のとおりです。
- クリティカルCSSのインライン化（ファーストビューに必要なCSSだけをHTMLに直接埋め込む）
- 不要なCSSの削除（使っていないスタイルを特定して除去）
- JavaScriptのdefer/async属性の付与
- フォントの
font-display: swap設定
原因3: 画像の読み込みが遅い
LCPの対象がヒーロー画像やメインビジュアルの場合、画像の最適化が直接的にLCPを改善します。
具体的にやるべきことは次のとおりです。
- WebPまたはAVIF形式への変換（JPEGやPNGより30〜50%軽量化できる）
- 適切なサイズの画像を配信（幅2000pxの画像を幅600pxで表示していないか）
<img>タグへのwidthとheight属性の明示- LCP対象の画像に
fetchpriority="high"を付与 - LCP対象の画像に
loading="lazy"を付けない（遅延読み込みはLCPを悪化させる）
原因4: クライアントサイドレンダリングの遅延
SPAやReactベースのサイトでは、JavaScriptが実行されるまでメインコンテンツが表示されないケースがあります。 SSR（サーバーサイドレンダリング）またはSSG（静的サイト生成）に切り替えることで、HTMLにコンテンツが含まれた状態でブラウザに届くため、LCPが大幅に改善します。
INP（Interaction to Next Paint）の改善
INPは、ユーザーがクリック・タップ・キーボード操作をしてから、画面が次に更新されるまでの時間を測定します。 200ms以内であれば、ユーザーは「即座に反応した」と感じます。
INPが悪化する最大の原因は、メインスレッドの長時間占有です。
ブラウザのメインスレッドは、JavaScriptの実行もUIの更新も同じスレッドで処理します。 つまり、重いJavaScriptが実行されている間は、ユーザーがボタンをタップしても反応しません。
改善策1: 長時間タスクの分割
50msを超えるJavaScriptの実行タスク（Long Task）を、requestIdleCallbackやsetTimeoutを使って小さなチャンクに分割します。
これにより、タスクの合間にユーザー操作への応答を挟めるようになります。
具体的には、yield to main threadパターンと呼ばれるテクニックを使います。
// 重い処理を分割する例
async function processItems(items) {
for (const item of items) {
processItem(item);
// 各アイテムの処理後にメインスレッドに制御を返す
await new Promise(resolve => setTimeout(resolve, 0));
}
}
改善策2: 不要なJavaScriptの削減
そもそも実行するJavaScriptの量を減らすことが根本的な対策です。
- 未使用のJavaScriptをバンドルから除去する（Tree Shaking）
- サードパーティスクリプト（広告、アナリティクス、チャットウィジェット等）の精査
- コード分割（Code Splitting）で初期ロードのJavaScript量を削減
特にサードパーティスクリプトは盲点です。 Googleタグマネージャー経由で大量のスクリプトが読み込まれ、メインスレッドを圧迫しているケースは非常に多い。定期的にスクリプトの棚卸しを行いましょう。
改善策3: イベントハンドラの最適化
クリックイベントやスクロールイベントのハンドラ内で重い処理を行っていないか確認してください。 特にスクロールイベントはデバウンスまたはスロットリングを適用しないと、秒間数十回の発火でメインスレッドを占有します。
CLS（Cumulative Layout Shift）の改善
CLSは、ページの読み込み中にコンテンツが予期せずずれる現象を数値化した指標です。
記事を読んでいるときに、突然広告が挿入されて本文がガクッと下にずれた経験はないでしょうか。あれがLayout Shiftです。
CLSの数値は、ずれた要素のサイズとずれた距離の掛け算で算出されます。0に近いほど良く、0.1以下がGood判定です。
改善策1: 画像・動画にサイズを明示する
画像や動画のwidthとheight属性を指定するか、CSSのaspect-ratioを設定してください。
サイズが指定されていないと、ブラウザは画像が読み込まれるまでその領域の大きさを確保できません。画像が読み込まれた瞬間にレイアウトが動きます。
<!-- 悪い例: サイズ未指定 -->
<img src="hero.webp" alt="ヒーロー画像">
<!-- 良い例: サイズ明示 -->
<img src="hero.webp" alt="ヒーロー画像" width="1200" height="630">
改善策2: 広告・埋め込みコンテンツのスペース確保
広告バナーや外部埋め込み（YouTube、Twitterなど）は、読み込みが完了するまでの領域をあらかじめCSSmin-heightで確保しておきます。
.ad-slot {
min-height: 250px; /* 広告の想定サイズ */
}
改善策3: Webフォントの読み込み制御
Webフォントの読み込みが遅れると、フォールバックフォントからWebフォントに切り替わるタイミングでテキストの高さが変わり、Layout Shiftが発生します。
font-display: optionalを使うと、フォントの読み込みが一定時間以内に完了しなかった場合はフォールバックフォントのまま表示するため、CLSを防げます。
見た目の一貫性を重視するならfont-display: swapを使い、size-adjustプロパティでフォールバックフォントのサイズを近づける方法もあります。
改善策4: 動的コンテンツの挿入に注意
JavaScriptでDOMに要素を動的に追加する場合、既存コンテンツの上部に挿入するとLayout Shiftが発生します。
通知バー、Cookie同意バナー、ポップアップなどは、既存コンテンツの位置を変えない方法（position: fixedやposition: stickyなど）で実装してください。
Core Web Vitalsの測定ツールと使い方
Core Web Vitalsの測定には「ラボデータ」と「フィールドデータ」の2種類があります。 この違いを理解していないと、改善の方向性を見誤ります。
ラボデータとフィールドデータの違い
| 項目 | ラボデータ | フィールドデータ |
|---|---|---|
| 測定方法 | シミュレーション環境で測定 | 実際のユーザーのブラウザで収集 |
| データソース | Lighthouse等のツール | Chrome UX Report（CrUX） |
| メリット | 再現性が高く、デバッグに有用 | 実際のユーザー体験を反映 |
| デメリット | 実環境と乖離する場合がある | 一定のトラフィック量が必要 |
| Googleの評価対象 | 対象外 | こちらが対象 |
Googleがランキングに使うのはフィールドデータです。 ラボデータでいくら高スコアでも、実際のユーザーのスコアが悪ければ意味がありません。
主要な測定ツール
1. Google Search Console（フィールドデータ）
Search Consoleの「ウェブに関する主な指標」レポートは、フィールドデータに基づいてサイト全体の状況を把握できます。 「良好」「改善が必要」「不良」の3段階でURLがグループ分けされるため、問題のあるページを一目で特定できます。
最大のメリットは、ページ単位ではなくURLグループ単位で問題を表示してくれること。テンプレートが同じページ群は似たスコアになるため、グループ単位の改善が効率的です。
まず最初に確認すべきツールはSearch Consoleです。
2. PageSpeed Insights（ラボデータ + フィールドデータ）
PageSpeed Insights（PSI）は、1つのURLに対してラボデータとフィールドデータの両方を表示してくれる便利なツールです。
画面上部に表示されるのがフィールドデータ（CrUXデータ）、下部に表示されるのがラボデータ（Lighthouseの結果）です。 フィールドデータがない場合（トラフィックが少ないページ）は、ラボデータのみ表示されます。
PSIの最大の利点は、改善項目の具体的な提案が表示されることです。 「レンダリングをブロックしているリソースを除外してください」「使用していないJavaScriptを削除してください」といった具体的な改善提案と、それによる推定改善効果が数値で示されます。
3. Chrome DevTools（Lighthouse）（ラボデータ）
Chrome DevToolsのLighthouseパネルでは、手元のブラウザでCore Web Vitalsを含むパフォーマンス監査を実行できます。 開発中の変更が数値にどう影響するかを即座に確認できるため、改善→測定のサイクルを高速に回せます。
Performance パネルでは、操作ごとのINPの詳細をトレースできます。どのイベントハンドラがメインスレッドを長時間占有しているかを特定する際に不可欠です。
4. Web Vitals拡張機能（フィールドデータの簡易確認）
Chromeの「Web Vitals」拡張機能をインストールすると、閲覧中のページのLCP・INP・CLSがリアルタイムで表示されます。 開発中に「今の変更でCLSが悪化していないか」をサッと確認するのに便利です。
5. CrUX Dashboard（フィールドデータの時系列分析）
Chrome UX Report（CrUX）のデータをGoogleのData Studioテンプレートで可視化できます。 Core Web Vitalsの推移を月次で追跡できるため、改善施策の効果検証や、Googleのアルゴリズムアップデート前後の変化を確認する際に重宝します。
測定の注意点
測定時に注意すべきポイントがいくつかあります。
まず、ラボデータとフィールドデータの乖離が大きい場合、フィールドデータを信頼してください。 ラボデータはCPUスロットリングやネットワーク制限をシミュレートしますが、実際のユーザー環境はもっと多様です。古いAndroid端末でモバイル回線を使っているユーザーもいれば、最新のiPhoneで光回線に接続しているユーザーもいます。
次に、フィールドデータは過去28日間の集計値です。 今日改善を実施しても、フィールドデータに反映されるまで最大28日かかります。Search Consoleのレポートに改善が反映されるまでには、さらに時間がかかる場合があります。
焦って「改善したのに数値が変わらない」と判断しないでください。ラボデータで改善を確認できていれば、フィールドデータにも時間差で反映されます。
Core Web Vitalsの改善優先順位
3つの指標すべてを同時に改善するのは現実的ではありません。 限られたリソースで最大の効果を出すために、優先順位をつけて取り組む必要があります。
ステップ1: まずSearch Consoleで現状を把握する
最初にやるべきは、Search Consoleの「ウェブに関する主な指標」を確認することです。 モバイルとPCの両方をチェックし、「不良」のURLがどれだけあるかを確認してください。
モバイルのスコアのほうが悪いのが一般的です。Googleはモバイルファーストインデックスを採用しているため、モバイルのスコア改善を優先してください。
ステップ2: 不良判定の指標から着手する
3指標のうち、「Poor（不良）」になっている指標が最優先です。 「Good（良好）」の指標をさらに良くするよりも、「Poor」を「Needs Improvement」にするほうが、ランキングへのインパクトは大きい。
もし複数の指標が不良の場合は、以下の順序で取り組むことを推奨します。
LCP → CLS → INP
理由は3つあります。
LCPを最優先する理由は、ユーザーの第一印象に直結するからです。 ページを開いてメインコンテンツが表示されるまでの時間が遅ければ、そもそもユーザーはページを離脱します。直帰率に直接影響するため、ビジネスインパクトが最も大きい。
CLSを次にする理由は、比較的少ない労力で改善できるケースが多いからです。 画像のサイズ指定や広告スロットの高さ確保など、HTMLやCSSの修正だけで対応できることが多く、JavaScriptの大規模な改修は不要な場合がほとんどです。
INPを最後にする理由は、改善の難易度が最も高いからです。 JavaScriptの実行パフォーマンスに起因するため、サードパーティスクリプトの削減やコードの最適化など、大がかりな対応が必要になることが多い。
ステップ3: テンプレート単位で改善する
ブログ記事ページ、商品ページ、カテゴリページなど、同じテンプレートを使用しているページ群は、同じCore Web Vitalsの問題を共有しているケースが大半です。
1ページだけ個別に修正するのではなく、テンプレートを改善することで数十〜数百ページを一括で改善できます。 Search Consoleの「URLグループ」を確認すると、テンプレート単位の問題が見えてきます。
ステップ4: 改善サイクルを回す
改善は一度やって終わりではありません。 新しいコンテンツの追加、サードパーティスクリプトの変更、CMSのアップデートなどによって、スコアは常に変動します。
月に1回はSearch ConsoleとPageSpeed Insightsを確認する運用を定着させてください。
なお、テクニカルSEO全般のチェック項目についてはSEO内部対策チェックリストで体系的にまとめています。Core Web Vitalsの改善と並行して、他の内部対策も確認することをおすすめします。
FAQ
Core Web Vitalsを改善すれば検索順位は必ず上がりますか？
上がるとは限りません。 Core Web Vitalsはランキング要因の1つですが、コンテンツの質や被リンクなど、より影響度の大きい要因が多数あります。ただし、競合と同水準のコンテンツ品質であれば、Core Web Vitalsの差が順位を左右するケースはあります。 逆に、Core Web Vitalsが不良のままだと、他の要因で勝っていてもマイナス評価を受ける可能性があります。
フィールドデータがSearch Consoleに表示されません
フィールドデータはChrome UX Report（CrUX）から収集されますが、表示されるには一定のトラフィック量が必要です。 月間PVが極端に少ないサイトでは、CrUXにデータが蓄積されず、フィールドデータが表示されません。
その場合はラボデータ（PageSpeed InsightsやLighthouse）を参考に改善を進め、トラフィックが増えてフィールドデータが収集されるのを待ちましょう。
WordPressでCore Web Vitalsを改善するにはどうすればいいですか？
WordPressサイトの場合、以下の対策が効果的です。
- 画像最適化プラグイン（ShortPixel、Imagify等）でWebP変換を自動化する
- キャッシュプラグイン（WP Super Cache、W3 Total Cache等）を導入する
- 使っていないプラグインを削除する（プラグインの数はJavaScriptの量に直結する）
- テーマのパフォーマンスを見直す（高機能テーマほど重い傾向がある）
- Autoptimize等でCSS/JavaScriptの最適化・結合を行う
特にプラグインの棚卸しは効果が大きい。使っていないプラグインが10個以上放置されているサイトは珍しくありません。
INP（Interaction to Next Paint）とFID（First Input Delay）の違いは？
FIDは「ユーザーの最初の操作」に対する応答遅延だけを測定していました。 INPは「ページ滞在中のすべての操作」を対象にし、その中で最も遅かった応答時間（外れ値を除く）をスコアとします。
つまり、INPのほうが厳しい指標です。FIDで問題なかったサイトでも、INPでは不良と判定されるケースがあります。 特に、スクロール後に出現するボタンやフォーム入力など、ページの後半で行われる操作のパフォーマンスが問われるようになりました。
Core Web VitalsのスコアはモバイルとPCで別々に評価されますか？
はい、別々に評価されます。 そしてGoogleはモバイルファーストインデックスを採用しているため、モバイルのスコアのほうが重要です。
一般的に、モバイルのスコアはPCより悪くなります。端末の処理能力が低く、通信環境も不安定なためです。 PCでは良好でもモバイルでは不良、というケースは非常に多いので、必ずモバイルのスコアを基準に改善を進めてください。
サードパーティスクリプト（広告、アナリティクス等）がスコアを悪化させています。削除すべきですか？
削除が最善とは限りません。 広告は収益に直結しますし、アナリティクスはデータ分析に不可欠です。
まずは「本当に必要なスクリプトかどうか」を精査してください。使っていないタグ、導入後放置されたチャットツール、効果の薄いリマケタグなどは削除対象です。
残すスクリプトについては、以下の方法で影響を最小化できます。
asyncまたはdefer属性を付与して読み込みタイミングを最適化- Google Tag Managerで遅延読み込みのトリガーを設定
PartytownのようなWebWorkerベースのソリューションで、サードパーティスクリプトをメインスレッドから隔離
まとめ
Core Web Vitals（LCP・INP・CLS）は、ユーザー体験を数値化するGoogleの指標であり、ランキング要因の1つです。
この記事のポイントを整理します。
3指標の合格ライン
- LCP: 2.5秒以下（メインコンテンツの表示速度）
- INP: 200ms以下（操作への応答性）
- CLS: 0.1以下（レイアウトの安定性）
改善の基本方針
- LCPは画像最適化、サーバー高速化、レンダリングブロックの解消が鍵
- INPはJavaScriptの削減と長時間タスクの分割で対処
- CLSは画像サイズの明示と動的コンテンツの制御で改善
改善の優先順位
- Search Consoleで「不良」判定のページを特定
- LCP → CLS → INPの順に着手
- テンプレート単位で修正して効率化
- 月1回の定期チェックで品質を維持
Core Web Vitalsの改善は、SEOのためだけではありません。 表示が速く、操作に即座に反応し、レイアウトが安定しているサイトは、ユーザーに信頼感を与えます。その信頼感が、滞在時間の延長やコンバージョン率の向上という形でビジネス成果につながります。
技術的に難しい部分もありますが、この記事で解説した改善策を1つずつ実施すれば、確実にスコアは改善します。 まずはSearch Consoleを開いて、自サイトの現状を確認するところから始めてください。
SEO対策全体の戦略設計についてはSEO対策とは？初心者でもわかる完全ガイドを、テクニカルSEOのチェックリストはSEO内部対策チェックリストを参考にしてください。