Core Web Vitalsの現行指標はLCP・INP・CLS
2026年7月24日時点の安定指標は、読み込みを示すLargest Contentful Paint（LCP）、操作応答を示すInteraction to Next Paint（INP）、視覚的安定性を示すCumulative Layout Shift（CLS）の3つです。FIDは2024年にINPへ置き換えられたため、FIDだけを監視する構成は更新してください。
| 指標 | 測る体験 | 良好 | 不良 |
|---|---|---|---|
| LCP | 初期表示領域で最大の画像またはテキストブロックが描画されるまで | 2.5秒以下 | 4.0秒超 |
| INP | クリック、タップ、キーボード入力から次の描画までの応答性 | 200ミリ秒以下 | 500ミリ秒超 |
| CLS | 利用者が予期しないレイアウト移動の大きさと距離 | 0.1以下 | 0.25超 |
良好と不良の間は「改善が必要」です。Googleの公式資料では、モバイルとデスクトップを分け、ページ読み込みの75パーセンタイルで目標を評価します。平均値だけでは、遅い利用者層の問題を隠す場合があります。
Google Search CentralでCore Web Vitalsの現行指標を確認する
最初の結論
Search ConsoleまたはPageSpeed Insightsの実ユーザーデータに問題があるなら改善対象です。実ユーザーデータがない小規模ページは「良好」ではなく「判定に必要な標本が不足」と考え、ラボ計測と自社のReal User Monitoring（RUM）で補います。
フィールドデータで問題を見つけ、ラボデータで原因を再現する
Core Web Vitalsの判断では、実際の利用環境を集計したフィールドデータと、設定した端末・回線条件で一回ずつ再現するラボデータを混同しないことが重要です。PageSpeed Insightsには両方が表示されるため、同じ画面内でも対象期間と計測条件を確認してください。
CrUX・Search Console
Chrome UX Report（CrUX）は対象条件を満たすChrome利用者の体験を集計します。PageSpeed InsightsとCrUX APIは過去28日間の移動窓を毎日更新し、Search Consoleは似た体験のURLをページ群として示します。修正直後に値が完全に入れ替わるわけではありません。
PageSpeed Insights
URLまたはオリジンのCrUXデータと、Lighthouseによるラボ診断を一画面で確認できます。URL単位の標本が足りない場合はオリジンデータが表示されることがあるため、見出しと対象を確認します。
Lighthouse・DevTools
同じ条件で再実行しやすく、LCP候補、ネットワーク依存、長いタスク、レイアウト移動を調べるのに向きます。ただし、単発のラボ値を実利用者全体の合否として扱いません。INPはページ滞在中の操作を扱うため、実際の操作フローも記録します。
自社RUM
CrUXだけでは遅かった操作や要素の詳しい文脈が不足します。必要に応じて、URLテンプレート、端末、LCP要素、操作対象、リリース番号を個人情報へ配慮して収集します。収集量、保存期間、同意、除外条件を先に決めます。
Chrome UX Report公式資料で各ツールの期間と集計単位を確認する
測定日・端末・URL・キャッシュ状態を残す
改善前後を比べるときは、URL、計測日時、モバイルまたはデスクトップ、回線とCPU条件、ログイン状態、キャッシュ、同意バナー、試行回数を記録します。条件が違う一回のLighthouse点数だけで「改善した」と結論付けません。
問題ページと原因を4段階で絞り込む
全ページへ同じ最適化を適用する前に、どの利用者、ページ群、指標、要素で問題が起きるかを特定します。表示速度プラグインを追加するだけでは、原因が残る場合や機能が壊れる場合があります。
- 段階 01
影響範囲をページ群と端末で分ける
Search Consoleでモバイルとデスクトップ、URLグループ、指標、良好・改善が必要・不良を確認します。テンプレート共通の問題か、特定記事の画像や埋め込みだけの問題かを分けます。
- 段階 02
代表URLのフィールド値を読む
PageSpeed InsightsでURL単位かオリジン単位か、75パーセンタイル、過去28日の集計であることを確認します。データなしを0や良好と読み替えません。
- 段階 03
ラボで同じ症状を再現する
DevToolsのPerformanceパネルやLighthouseで、キャッシュなしの初回表示、代表的な端末幅、メニュー・検索・カートなど重要操作を記録します。LCP要素、長いタスク、Layout Shiftを実要素へ結び付けます。
- 段階 04
一つずつ変更して回帰確認する
変更前の記録を保存し、一度に多くの最適化を重ねません。見た目、フォーム、計測、広告、アクセシビリティを確認し、改善した指標と悪化した指標の両方を残します。
LCPは最大要素が見えるまでの待ち時間を分解する
LCPは単に画像ファイルの大きさだけで決まりません。サーバーから最初の応答が届くまで、ブラウザがLCPリソースを発見するまで、リソースを取得するまで、取得後に描画できるまでの遅延へ分けると、修正対象を選びやすくなります。
サーバー応答とHTML生成を確認する
TTFBが長い場合は、アプリケーション処理、データベース、キャッシュ、ホスティング、CDN、リダイレクトを確認します。サーバー変更を先に決めず、代表URLと地域、キャッシュ有無をそろえて測ります。
LCPリソースをHTMLから早く発見できるようにする
主要画像をJavaScript実行後やCSS背景だけで遅く追加すると、取得開始が遅れます。初期HTMLのimg要素、適切なpreload、fetchpriorityを候補にし、非表示画像や多数のリソースを高優先度にしません。
表示サイズに合う画像と形式を配信する
width・height、srcset・sizes、圧縮、WebPやAVIFを検討します。LCP画像へloading="lazy"を付けると取得が遅れる場合があるため、画面外画像だけを遅延読込します。画質と読みやすさを実機で確認します。
描画を止めるCSS・フォント・JavaScriptを減らす
初期表示に必要なCSSを優先し、不要なCSSや同期スクリプト、長いメインスレッド処理を減らします。フォントは必要な字形とウェイトを絞り、フォールバック時のレイアウトも確認します。
LCPの検証
DevToolsでLCP要素と構成時間を記録し、低速条件で複数回測ります。公開後はCrUXの28日窓が更新される間、日次の分布とリリース日を重ね、他の変更やトラフィック構成の影響も考慮します。
INPは遅い操作を特定し、次の描画までを短くする
INPは、ページ滞在中のクリック、タップ、キーボード操作の応答性を捉えます。入力を待つ時間、イベント処理を実行する時間、ブラウザが次の画面を描くまでの時間へ分け、どの操作が遅いかを先に特定します。
実際に遅い操作をフィールドで記録する
メニュー、検索候補、入力、絞り込み、カート、モーダルなど重要操作を対象にします。CrUXのINPだけで要素までは特定しにくいため、自社RUMまたは利用者報告とラボ記録を組み合わせます。
長いタスクと不要なJavaScriptを減らす
大きなスクリプトの解析・実行、第三者タグ、同期的な計算がメインスレッドを占有していないか確認します。コード分割、不要機能の削除、処理の分割を行い、視覚的な応答に不要な仕事を次の描画後へ回します。
イベント処理を必要最小限にする
一回の入力で全一覧を再計算したり、大きなDOMを作り直したりしないようにします。処理中の状態をすぐ表示し、ネットワーク完了まで無反応に見せません。ただし二重送信や不整合を防ぐ制御も残します。
描画コストとレイアウトの往復を減らす
JavaScriptでスタイル変更と寸法取得を交互に行うと、同期レイアウトが繰り返されます。DOMを必要以上に大きくせず、読み取りと書き込みをまとめ、更新範囲を限定します。
INPの検証
ページ読み込み中と読み込み後の両方で代表操作を実行し、Performanceパネルで入力遅延、処理、描画を確認します。ラボで速くても、実利用者の遅い端末や長い滞在で問題が残るため、公開後のRUMとCrUXを確認します。
CLSは予期しない移動の発生源に領域を予約する
CLSは時間ではなく、表示中の要素がどれだけ大きく、どれだけ遠く移動したかから計算される無単位の値です。読み込み時だけでなく、同意バナー、広告、遅延コンテンツ、操作後の更新で発生する移動も確認します。
画像・動画に寸法または縦横比を指定する
imgとvideoへwidth・heightを指定し、レスポンシブ表示ではaspect-ratioを保ちます。読み込み前に領域が確保されれば、後続テキストを押し下げにくくなります。
広告・埋め込み・動的領域を先に確保する
広告、地図、動画、フォーム、通知の想定領域をmin-heightやaspect-ratioで確保します。内容が返らない場合に予約領域を突然閉じることでも移動が起きるため、空状態を設計します。
既存内容の上へ予告なく挿入しない
ページ上部へバナーやメッセージを後から差し込む場合は、最初から領域を取るか、内容を押し下げないオーバーレイを適切に使います。利用者操作に応じた追加でも、操作対象が逃げないことを確認します。
Webフォントとアニメーションを確認する
代替フォントとWebフォントの寸法差を抑え、必要なフォントを早く読み込みます。移動を伴う演出ではレイアウト値を直接変えるアニメーションを避け、transformとopacityを優先します。
CLSの検証
DevToolsのPerformanceパネルでLayout Shiftを選び、移動した要素だけでなく、その上へ追加された原因要素を確認します。再読み込み時と、メニュー、同意、広告、無限スクロールなど操作後の両方を検証します。
影響の大きいテンプレートから直し、変更前後を同条件で比較する
Core Web Vitalsの改善は、最も低い点数から機械的に始める作業ではありません。利用者数、事業上の重要度、影響するURL数、修正リスク、再現性を合わせて優先順位を決めます。
- 1
基準値と対象ページ群を保存する
Search Console、PageSpeed Insights、RUM、代表URLのラボ記録を保存し、日時、端末、リリース番号を記録します。問い合わせや申込みなど重要な利用フローも決めます。
- 2
一つの指標を構成要因へ分ける
LCPなら応答・発見・取得・描画、INPなら入力待ち・処理・描画、CLSなら移動元と原因要素へ分け、修正仮説を一文で書きます。
- 3
狭い範囲で実装し、機能回帰を確認する
ステージングや代表テンプレートで変更し、Chrome・Edge・Safari、モバイル、キーボード、フォーム、計測タグ、画像、フォントを確認します。速度のために必要機能や読みやすさを失わないようにします。
- 4
ラボで即時確認し、フィールドで継続確認する
同じ条件の複数試行で明らかな回帰がないことを確認して公開します。CrUXは過去28日を含むため、公開日を記録し、分布が入れ替わるまで日次で監視します。
- 5
結果から次の仮説を選ぶ
改善しなければ、対象要素やページ群、キャッシュ、第三者タグ、トラフィック構成を再確認します。改善した場合も、INPやCLSなど別指標、機能、成約への悪影響がないか確認します。
SEOと事業への影響を断定しない
GoogleはCore Web Vitalsをページエクスペリエンスの一部として検索ランキングで考慮すると説明していますが、良好な値だけで上位表示が保証されるわけではありません。検索意図への回答、内容の信頼性、クロール・インデックス、内部リンクなどを同時に整えます。売上や成約率も価格、訴求、流入、フォーム、季節性の影響を受けるため、変更前後の同条件比較で判断します。
参照した公式資料
指標、基準、測定期間、改善方法は次の公式資料を2026年7月24日に確認しました。仕様やツール画面は更新されるため、実装前にも再確認してください。
Core Web Vitalsのよくある質問
PageSpeed Insightsの点数が100ならCore Web Vitalsも良好ですか？
同じ意味ではありません。Lighthouseのパフォーマンス点数は設定された条件のラボ結果で、Core Web Vitalsの合否は実利用者データのLCP・INP・CLSを75パーセンタイルで評価します。フィールド欄の対象がURLかオリジンか、データが十分かも確認してください。
フィールドデータとラボデータが違うのは不具合ですか？
必ずしも不具合ではありません。フィールドは多様な端末、回線、地域、キャッシュ、利用行動を過去28日で集計します。ラボは一つの設定と短い実行です。差が大きい場合は、操作後のINP・CLS、第三者タグ、端末差、ページ群の集計を調べます。
FIDはもう測らなくてよいですか？
Core Web VitalsではINPがFIDを置き換えています。古いダッシュボードや記事がFIDだけならINPへ更新してください。独自の分析目的で別の応答指標を併用する場合も、Core Web Vitalsの現行合否と混同しないようにします。
WordPressの高速化プラグインだけで改善できますか？
原因によります。キャッシュや遅延読込が役立つ場合はありますが、LCP画像の遅延、JavaScript競合、表示崩れ、計測漏れを起こすこともあります。原因を特定し、バックアップとステージングを用意して、一つずつ有効化して確認します。
良好になれば検索順位は上がりますか？
保証されません。Core Web Vitalsは検索ランキングで考慮されるページエクスペリエンスの一部ですが、関連性や内容の品質など他の要素もあります。利用者が読み、操作し、目的を完了しやすくなることを主目的に改善します。
次に確認する表示速度・SEOガイド
実ユーザーデータから始め、原因を分解して一つずつ直す
Core Web VitalsはLCP・INP・CLSの3指標を、モバイルとデスクトップに分け、75パーセンタイルで評価します。まずCrUXやSearch Consoleで問題のあるページ群を見つけ、PageSpeed InsightsとDevToolsで要素や処理へ絞り、機能回帰を確認して公開します。ラボ値はすぐ確認し、フィールド値は28日窓と公開日を踏まえて追跡してください。
この記事の検証方針
Finite Field 編集部
Web制作、サーバー、業務システムの記事を、読者が自分で判断・検証できる順序へ編集しています。指標と仕様は公式資料で確認し、単発の点数、検索順位、成約効果を断定しません。
表示速度と機能を両立したい方へ
WebサイトのCore Web Vitals改善をFinite Fieldへ相談できます
対象URL、Search ConsoleまたはPageSpeed Insightsの結果、困っている端末・操作、直近の変更があれば共有してください。原因の切り分け、改善優先順位、実装、Chrome・Edge・Safariでの回帰確認を相談できます。自社で対応できる判断材料は本記事の手順を先に利用してください。
Core Web Vitalsと表示速度の改善を相談する相談によって特定の点数、検索順位、売上、納期、見積額を確約するものではありません。調査範囲と対応内容を確認してご案内します。