Core Web Vitals(コアウェブバイタルズ)は、ページの読み込み、操作への応答、表示の安定性を実際の利用者に近い形で捉える指標です。
2026年現在の3指標は、LCP、INP、CLSです。
数値を改善する目的は、テストの点数を上げることではありません。
訪問者が「内容がなかなか見えない」「押しても反応しない」「表示が動いて押し間違える」と感じる場面を減らすことです。
この記事では、GoogleのCore Web Vitals公式資料に沿って、指標の読み方、測定ツールの使い分け、改善の優先順位を整理します。
Core Web Vitalsの現行3指標
Core Web Vitalsは、すべてのWebページに共通する利用体験のうち、測定可能な3つの側面を扱います。
評価では、モバイルとデスクトップを分け、ページ読み込みの75パーセンタイルで基準を満たしているかを確認します。
| 指標 | 測るもの | 良好の目安 | 利用者が感じる問題の例 |
|---|---|---|---|
| LCP | 主要な画像やテキストが表示されるまでの時間 | 2.5秒以下 | ページを開いても主な内容が見えない |
| INP | クリック、タップ、キーボード操作に対して次の画面更新が行われるまでの応答性 | 200ミリ秒以下 | ボタンを押しても反応が遅い |
| CLS | 閲覧中に起きた予期しないレイアウト移動の大きさ | 0.1以下 | 読んでいる途中で文字やボタンの位置が動く |
LCPは主要コンテンツが見える速さ
LCP(Largest Contentful Paint)は、最初に見える範囲にある最大の画像またはテキストブロックが描画されるまでの時間です。
多くのページでは、メインビジュアル、記事タイトル付近の画像、大きな見出しなどが対象になります。
LCPが遅い場合、画像サイズだけを疑うと原因を見落とします。
サーバー応答、対象リソースをブラウザが見つけるまでの遅れ、転送時間、描画を妨げるCSSやJavaScriptを分けて調べる必要があります。
INPは滞在中の操作への応答性
INP(Interaction to Next Paint)は、ページ滞在中に行われた操作への応答を継続して観測する指標です。
最初の操作だけを測っていたFIDより、閲覧中の使いにくさを広く捉えます。
FIDは2024年3月12日にCore Web Vitalsから外れ、INPに置き換えられました。
古い資料や計測設定でFIDを参照している場合は、INPを扱える状態へ更新します。
CLSは予期しない表示のずれ
CLS(Cumulative Layout Shift)は、閲覧中に発生した予期しないレイアウト移動を表す単位のないスコアです。
画像の読み込み後に本文が押し下げられる、広告が後から現れてボタンが移動するといった現象が悪化要因になります。
利用者の操作に応じて意図どおり表示が変わることと、読み込みの都合で突然位置が変わることは区別します。
CLSで減らしたいのは後者です。
SEOとの関係を正しく捉える
Googleの検索ランキングシステムはCore Web Vitalsを利用していますが、良好な数値だけで上位表示が保証されるわけではありません。
検索意図に合う有用な内容を土台にして、ページ体験を妨げる要因を減らすという順序で考えます。
Core Web Vitalsは、クロール、インデックス、モバイル対応などと並ぶ技術的SEOの改善項目です。
Googleも、Core Web Vitalsだけに注目せず、ページ体験全体を確認するよう案内しています。
表示速度とWebアクセシビリティも同じものではありません。
待ち時間や表示のずれを減らすことは使いやすさに役立ちますが、キーボード操作、代替テキスト、見出し構造、色のコントラストなどは別に確認する必要があります。
フィールドデータとラボデータの使い分け
測定結果を読むときは、実際の訪問者から集めたフィールドデータと、一定条件でテストしたラボデータを分けます。
両者は目的が異なるため、数値が一致しないこと自体は異常ではありません。
| データ | 向いている用途 | 注意点 |
|---|---|---|
| フィールドデータ | 実際の端末、通信環境、操作を含む利用体験の把握 | 十分な利用データがないURLでは表示されない場合がある |
| ラボデータ | 公開前の検証、原因調査、変更前後の比較 | 一つの模擬環境の結果なので、実利用のばらつきをそのまま表さない |
PageSpeed InsightsでURLを調べる
PageSpeed Insightsは、利用可能な場合にChrome User Experience Reportのフィールドデータと、Lighthouseによるラボデータを同じ画面に表示します。
フィールドデータは過去28日間を対象とするため、修正直後の変化はラボデータで先に確認します。
URL単位のデータが不足すると、サイト全体を示すオリジン単位のデータへ切り替わることがあります。
画面に表示されている対象がURLかオリジンかを確認してから判断します。
Search Consoleでページ群の傾向を見る
Search Consoleのウェブに関する主な指標レポートは、実利用データを基に、似たページをURLグループとして分類します。
モバイルとデスクトップを分けて、不良、改善が必要、良好の件数を追う用途に向いています。
このレポートは、特定の1ページを細かく診断する道具ではありません。
問題のあるページ群を見つけたら、代表URLをPageSpeed InsightsやChrome DevToolsで調べます。
Chrome DevToolsとLighthouseで原因を絞る
Chrome DevToolsのPerformanceパネルやLighthouseは、ネットワーク要求、長時間のメインスレッド処理、レイアウト移動などの原因調査に使います。
変更前後を同じ条件で比べると、施策が狙った箇所に効いたかを確認しやすくなります。
利用者の操作がない模擬テストでは、INPそのものを測れません。
LighthouseではTotal Blocking Timeを手掛かりにしつつ、INPの最終判断は実際の操作を含む計測で行います。
指標ごとの改善方法
LCPは対象要素と読み込み順を確認する
- LCP要素を特定する:画像、見出し、テキストブロックのどれが対象かをDevToolsで確認します。
- 対象リソースを早く見つけられるようにする:主要画像のURLを初期HTMLから参照できるようにし、必要な場合だけプリロードや読み込み優先度を検討します。
- 画面上部の主要画像を遅延読み込みしない:LCP候補に
loading="lazy"を付けると、読み込み開始が遅れることがあります。 - 転送量とサーバー応答を見直す:表示サイズに合う画像、適切な圧縮、キャッシュ、CDN、サーバー処理を順に確認します。
- 描画を妨げる処理を減らす:不要なCSSやJavaScriptを削り、初期表示に不要な処理を後へ回します。
すべての画像を一律に遅延読み込みする施策は、画面上部の主要画像では逆効果になり得ます。
LCP要素を特定してから読み込み方を変えます。
INPは長い処理とイベント処理を分ける
- 遅い操作を特定する:メニューを開く、検索する、商品を絞り込むなど、どの操作で待ち時間が生じるかを記録します。
- 起動時のJavaScriptを減らす:利用していないコードや初期表示に不要な処理を遅らせます。
- 長い処理を小さく分ける:メインスレッドを長時間占有する計算やDOM更新を分割し、描画の機会を確保します。
- イベント処理を必要最小限にする:クリック直後に不要な計算、同期処理、大量の要素更新をまとめて実行しないようにします。
- 第三者スクリプトを点検する:計測、広告、接客ツールなどを用途ごとに棚卸しし、必要性と読み込み時期を見直します。
コード分割やWeb Workerは選択肢ですが、導入するだけでINPが改善するとは限りません。
遅延の原因がメインスレッド上のどの処理にあるかを確認してから使います。
CLSは読み込み前に場所を確保する
- 画像と動画:
widthとheight、またはCSSのaspect-ratioで縦横比を伝えます。 - 広告、埋め込み、バナー:読み込み前から必要な領域を確保します。
- 動的コンテンツ:既に表示している内容の上へ突然挿入せず、利用者の操作と位置関係が分かる場所に表示します。
- Webフォント:フォント切り替え時の文字幅の差を確認し、読み込み方法と代替フォントを調整します。
CLSの原因は、ページを開いた瞬間だけに現れるとは限りません。
遅れて表示される広告、同意バナー、関連コンテンツも、実際の閲覧時間を通して確認します。
症状から改善の優先順位を決める
複数の施策を同時に入れると、どの変更が効いたか分かりにくくなります。
最も悪い指標を選び、代表ページで原因を特定し、影響の大きい変更から検証します。
| 症状 | 最初に確認すること | 初手の例 |
|---|---|---|
| LCPが遅い | LCP要素、ネットワークの読み込み開始、サーバー応答 | 主要画像を初期HTMLから見つけられるようにする |
| INPが遅い | 遅い操作、長いタスク、イベント処理、第三者スクリプト | 最も長い処理を分割する |
| CLSが大きい | 移動した要素と、その直前に読み込まれた要素 | 画像や埋め込みの領域を先に確保する |
継続的に測定する運用
Core Web Vitalsは、公開時に一度合格すれば終わる検査ではありません。
コンテンツ追加、タグの変更、広告の差し替え、ライブラリ更新によって数値は変わります。
- Search Consoleで問題のあるページ群と端末区分を把握する。
- 代表URLをPageSpeed InsightsとDevToolsで調べる。
- 原因に対応する変更を小さく実施する。
- ラボデータで意図した改善と副作用を確認する。
- 公開後はフィールドデータと独自の実ユーザー計測で推移を見る。
web-vitalsライブラリを使うと、LCP、INP、CLSを実際のページ上で測定し、利用中の分析基盤へ送れます。
平均値だけでなく、ページ種別、端末、リリース前後で分けると、問題が発生した範囲を絞りやすくなります。
Core Web Vitals改善の要点
- 現行指標はLCP、INP、CLSであり、FIDはINPに置き換えられています。
- 良好の目安は、75パーセンタイルでLCPが2.5秒以下、INPが200ミリ秒以下、CLSが0.1以下です。
- フィールドデータで実態を捉え、ラボデータで原因を調べます。
- SEOでは点数だけを追わず、内容の有用性とページ体験を一緒に整えます。
- 改善後も、コンテンツや機能の変更に合わせて継続的に測定します。
この記事に関連する株式会社greedenの取り組み
Core Web Vitalsは、一度の高速化で終わらず、実測と改善を繰り返す運用課題です。
株式会社greedenは、Webシステム開発から既存システムの使い勝手改善、リリース後の保守・改善まで継続して支援します。
