Core Web Vitals は、ページの実際の体験を測るために Google が使う3つの指標です。どれだけ速く読み込まれるか、どれだけ速く反応するか、読み込み中にどれだけ安定しているかを測ります。Google がランキングで考慮するページエクスペリエンスのシグナルの一部であり、さらに重要なのは、訪問者がサイトを実際にどう感じているかを反映していることです。
3つの Core Web Vitals
| 指標 | 測るもの | 良好 | 改善が必要 | 不良 |
|---|---|---|---|---|
| LCP – Largest Contentful Paint | 読み込み：メインコンテンツが表示されるまで | ≤ 2.5秒 | 2.5〜4.0秒 | > 4.0秒 |
| INP – Interaction to Next Paint | 応答性：操作にページが反応する速さ | ≤ 200ミリ秒 | 200〜500ミリ秒 | > 500ミリ秒 |
| CLS – Cumulative Layout Shift | 視覚的な安定性：レイアウトのずれの大きさ | ≤ 0.1 | 0.1〜0.25 | > 0.25 |
実際の訪問の少なくとも75%（75パーセンタイル）が3つすべての指標で「良好」を満たすと、そのページは合格です。
2024年3月、INP は First Input Delay（FID）に代わって Core Web Vitals の一つになりました。INP はより厳しく、最初の操作だけでなく、訪問中のすべての操作の応答性を考慮します。
フィールドデータとラボデータ
フィールドデータは実際の Chrome ユーザーから得られるもので、28日間の移動期間で Chrome UX Report（CrUX） に収集されます。Google がページエクスペリエンスに使うのはこのデータです。Search Console の「ウェブに関する主な指標」レポートや PageSpeed Insights で確認できます。
ラボデータは、Lighthouse などのシミュレーションテストで、決まった端末とネットワーク上で得られるものです。原因の調査や変更のテストには最適ですが、Google がランキングに使うものではなく、INP を直接測ることもできません（最も近いラボの指標は Total Blocking Time です）。
Chrome UX レポートから、ページとサイト全体の実ユーザーの LCP、INP、CLS を確認します。
アクセスの少ないページには十分なフィールドデータがないことがあり、その場合 Google は似たページやサイト全体（「オリジン」）のデータを使うことがあります。
Largest Contentful Paint（LCP）
LCP は、画面内で最も大きな画像やテキストブロックの描画が完了した時点を示します。通常はヒーロー画像、大きな見出し、注目動画のポスター画像です。
LCP は4つの部分に分解でき、それぞれが改善策を示します。
- Time to First Byte – サーバーが応答するまでの時間
- リソースの読み込み遅延 – ブラウザが LCP のリソースのダウンロードを始めるまでの時間
- リソースの読み込み時間 – ダウンロードにかかる時間
- 要素の描画遅延 – ダウンロードから描画までの時間
LCP の改善方法
- サーバーを速くする：ページキャッシュ、CDN、より速いホスティング、データベースクエリの削減
- LCP の画像を早く見つけられるようにする：CSS の背景や JavaScript で挿入した画像ではなく、HTML 内の通常の
<img>を使い、fetchpriority="high"を付ける - LCP の画像は決して遅延読み込みしない
- 画像を最適化する：適切なサイズ、WebP や AVIF、十分な圧縮
- 描画をブロックするリソースを減らす：重要な CSS はインライン化し、重要でない JavaScript は遅らせる
- 画像 CDN など必要なサードパーティのオリジンに preconnect を使う
Interaction to Next Paint（INP）
INP は、クリック、タップ、キー入力といったユーザーの操作から、画面上の次の視覚的な更新までの遅延を測ります。訪問中の最も遅い操作の一つが報告されます。
INP が悪いのは、たいていメインスレッドで実行される JavaScript が多すぎるためで、ブラウザがすばやく反応できなくなっています。
INP の改善方法
- JavaScript を減らし、分割する：使っていないライブラリを削除し、コード分割を行い、必要なときだけ機能を読み込む
- 長いタスクを分割する：50ミリ秒を超えるタスクはメインスレッドをブロックします。処理の合間にブラウザに制御を戻しましょう
- サードパーティのスクリプトを見直す：タグマネージャー、チャットウィジェット、A/Bテストツール、広告スクリプトはよくある原因です
- DOM を軽く保つ：非常に大きなページでは、あらゆる更新が遅くなります
- 操作にはすぐに視覚的なフィードバックを返し、重い処理はその後に行う
Cumulative Layout Shift（CLS）
CLS は予期しないレイアウトの移動を測ります。タップしようとした瞬間にボタンが逃げていく、あのいらだたしい体験です。どれだけのコンテンツがどれだけ動いたかをスコア化します。
CLS の改善方法
- 画像と動画に幅と高さを指定するか、CSS の
aspect-ratioを使い、スペースを確保する - 広告、埋め込み、iframe のためのスペースを確保する（サイズ固定のコンテナを使う）
- 既存のコンテンツの上に新しいコンテンツを挿入しない（読み込み後にページを押し下げるバナーなど）
font-display: swapは慎重に使い、主要な Web フォントをプリロードするか、代替フォントのメトリクスを使ってテキストの再配置を防ぐ- アニメーションには
transformを使い、topやheightなどレイアウトの再計算を引き起こすプロパティは避ける
実践的な作業の流れ
- Search Console の「ウェブに関する主な指標」レポートを確認し、どのURLグループがどの指標で不合格かを見る
- 不合格の各グループから代表的なURLを選ぶ
- ラボテストを実行して、何が遅いのかを診断する
- テンプレート単位で修正する – ほとんどの問題は同じレイアウトを使うすべてのページに影響します
- 検証する：デプロイ後に Search Console で検証を開始します。フィールドデータに改善が反映されるまで最大28日かかります
任意のページの Lighthouse パフォーマンススコア、ラボデータ、実ユーザーの Core Web Vitals。
Core Web Vitals は順位にどれほど影響するのか
Google は、ページエクスペリエンスは数あるシグナルの一つにすぎず、関連性と役に立つコンテンツのほうが重要だと明言しています。内容の弱い速いページが、優れたページを上回ることはありません。しかし、関連性が同程度のページ同士なら、よりよい体験が助けになることがあります。そして速いページは一貫してコンバージョン率が高く、これは順位に関係なく重要です。
プラットフォーム別のヒント
WordPress
- キャッシュプラグインかサーバー側のキャッシュを使い、サーバーの応答時間を短縮する
- 軽量なテーマを選ぶ（重いページビルダーは大量の CSS と JavaScript を追加しがちです）
- プラグインを見直す（それぞれがすべてのページにスクリプトを追加し、INP を悪化させることがあります）
- WebP や AVIF を配信し、幅と高さの属性を追加する画像最適化プラグインを使う
- すべてのページで必要ではないサードパーティのスクリプトは遅らせるか削除する
Shopify
- インストールしたアプリを見直す（使っていなくても全ページにスクリプトを挿入するものが多くあります）
- テーマに組み込まれたレスポンシブ画像の機能を使う
- トップページのセクションやスライダーの数を絞る
- アップロード前に画像を圧縮・リサイズする
独自開発や JavaScript の多いサイト
- サーバーサイドレンダリングや静的生成を使い、JavaScript を待たずにコンテンツが表示されるようにする
- ルートごとにコードを分割し、コンポーネントを必要に応じて読み込む
- JavaScript ライブラリ
web-vitalsで実ユーザーの INP を測ってアクセス解析に送り、どの操作が遅いかを把握する
実ユーザーのデータを自分で測る
Search Console と PageSpeed Insights は集計された Chrome のデータを表示しますが、十分なアクセスがあるページに限られ、時間差もあります。すべてのページとすべての訪問者の Core Web Vitals を見るには、リアルユーザーモニタリング（RUM）を導入しましょう。オープンソースの web-vitals ライブラリは、訪問者のブラウザから LCP、INP、CLS を報告し、その値を Google アナリティクス 4 などの解析ツールに送れます。RUM はどの要素が LCP だったか、どの操作が最も遅かったかも記録します。まさに問題の解決に必要な情報です。
Total Blocking Time と Speed Index について
Lighthouse は Core Web Vitals 以外の指標も報告します。**Total Blocking Time（TBT）**は読み込み中にメインスレッドがブロックされた時間を測り、INP と相関があります。**First Contentful Paint（FCP）**は最初に何かが表示された時点を示します。Speed Index は画面の表示領域がどれだけ速く埋まるかを測ります。いずれも診断には役立ちますが、Core Web Vitals そのものではありません。
よくある誤解
- 「上位表示には PageSpeed で100点が必要」 いいえ。ページエクスペリエンスで重要なのは、フィールドデータで Core Web Vitals のしきい値を満たすことであり、関連性のほうがはるかに重要です。
- 「Core Web Vitals は Google のためだけのもの」 速くて安定したページは、どこから来た訪問者にとってもコンバージョンと満足度を高めます。
- 「キャッシュプラグインを増やせば効果がある」 キャッシュや最適化のプラグインを重ねると、競合が起きることがよくあります。よく設定した1つの方法を使いましょう。
重要なポイント
- Core Web Vitals は、読み込み（LCP）、応答性（INP）、視覚的な安定性（CLS）を測ります。
- よい状態のしきい値は、実際の訪問の75パーセンタイルで LCP 2.5秒以下、INP 200ミリ秒以下、CLS 0.1以下です。
- 重要なのは実際の Chrome ユーザーのフィールドデータで、ラボテストは問題の診断に使います。
- LCP は、より速いサーバーとよく最適化されたヒーロー画像で改善することがほとんどです。
- INP は、JavaScript、特にサードパーティのスクリプトを減らして分割すると改善します。
- CLS は、画像、広告、埋め込みのスペースを確保すると改善します。
よくある質問
ラボとフィールドのスコアが違うのはなぜですか？
ラボテストは1つの端末とネットワークをシミュレートします。フィールドデータは、ラボテストが行わない操作も含め、実際の訪問者の端末、ネットワーク、行動を反映しています。
改善が Search Console に反映されるまでどのくらいかかりますか？
フィールドデータは過去28日間を対象としているため、修正が完全に反映されるまで最大4週間かかります。
Core Web Vitals はデスクトップでも重要ですか？
重要です。Google はモバイルとデスクトップを別々に評価します。端末とネットワークが遅いため、通常はモバイルのほうが合格しにくくなります。
PageSpeed のよいスコアとはどのくらいですか？
90以上なら良好です。ただし、スコアはラボの要約にすぎません。ページエクスペリエンスで重要なのは、フィールドデータで Core Web Vitals に合格することです。
自分のサイトをチェック
80 以上の項目を無料で診断し、すべての問題の改善方法を確認しましょう。