2026年7月29日にGoogle Search Central、web.dev、Chrome UX Reportの公式資料を再確認しました。仕様やツール画面は更新されるため、実装前にも公式情報をご確認ください。
Core Web Vitalsの改善で最も大切なのは、「フィールドで問題を発見し、ラボで原因を再現し、公開後にフィールドで確認する」ことです。 Lighthouseの総合点を上げるだけでは、実際の利用者が遅いと感じているページや操作を取りこぼすことがあります。
Core Web Vitalsは、3指標の合否より「どこで待たせているか」を読む
現行のCore Web VitalsはLCP・INP・CLSです。良好の目安はLCP 2.5秒以下、INP 200ミリ秒以下、CLS 0.1以下。モバイルとデスクトップを分け、ページ読み込みの75パーセンタイルで評価します。
| 現行指標 | LCP（読み込み）、INP（操作応答）、CLS（視覚的安定性） |
|---|---|
| 良好の目安 | LCP 2.5秒以下、INP 200ミリ秒以下、CLS 0.1以下 |
| 判定方法 | モバイルとデスクトップを分け、75パーセンタイルで3指標すべてを評価 |
| 問題発見 | Search Console、PageSpeed InsightsのCrUXデータ、自社RUM |
| 原因診断 | Chrome DevTools、Lighthouse、ネットワーク・Performance記録 |
| データ期間 | CrUX系の主要ツールは過去28日間のローリング集計を日次更新 |
| SEOとの関係 | ページエクスペリエンスの一部。良好な値だけで順位上昇は保証されない |
Core Web Vitalsとは？現行指標はLCP・INP・CLS
Core Web Vitals（コアウェブバイタル）は、Webページを使う人が感じる読み込みの速さ、操作への反応、表示の安定性を共通の基準で測る指標です。サーバーの応答速度だけでなく、画像が見えるまでの待ち時間、クリック後の画面更新、読み込み中のレイアウト移動まで含めて評価します。
読み込み
2.5秒以下初期表示領域で、最大の画像またはテキストブロックが描画されるまでを測ります。
改善が必要：2.5秒超〜4.0秒以下／不良：4.0秒超操作応答
200ms以下クリック、タップ、キーボード入力から、次の画面が描画されるまでを測ります。
改善が必要：200ms超〜500ms以下／不良：500ms超表示の安定性
0.1以下利用者が予期しないレイアウト移動の大きさと距離を、無単位の値で評価します。
改善が必要：0.1超〜0.25以下／不良：0.25超平均値ではなく75パーセンタイルを使うのは、速い利用者だけで全体を良く見せず、遅い側の利用体験も含めて判断するためです。たとえば100回のページ訪問がある場合、速い順に並べた75番目付近の値が目標内にあるかを確認します。
Core Web VitalsとSEOの関係を正しく理解する
GoogleはCore Web Vitalsを、その他のページエクスペリエンス要素とともにランキングで考慮すると説明しています。ただし、Core Web Vitalsだけで検索順位が決まるわけではありません。検索意図への回答、内容の独自性と信頼性、クロール・インデックス、内部リンク、モバイルでの使いやすさなども重要です。
利用者が目的を達成しやすくする
- 主要内容が早く見える
- クリックや入力へすぐ反応する
- ボタンや文章が突然動かない
- 離脱や誤操作を減らせる
点数だけで順位・売上を予測しない
- 良好でも検索意図に合わなければ上位表示は難しい
- 成約率は価格、訴求、導線、フォームにも左右される
- 一時点の計測値だけでは因果関係を判断できない
フィールドデータで問題を見つけ、ラボデータで原因を再現する
Core Web Vitalsを改善するときは、実際の利用者を集計したフィールドデータと、設定した端末・回線で再現するラボデータを混同しないことが重要です。両者は競合する数字ではなく、役割が違います。
| 比較 | フィールドデータ | ラボデータ |
|---|---|---|
| 主な目的 | 実利用者に問題があるページ・端末・指標を発見する | 同じ条件で問題を再現し、原因を詳しく調べる |
| 代表ツール | CrUX、Search Console、PageSpeed Insights、自社RUM | Lighthouse、Chrome DevTools、WebPageTest |
| 期間・条件 | 多様な端末・回線・地域・行動を過去28日で集計 | 特定の端末・CPU・回線・キャッシュ状態で実行 |
| INP | 実際の操作から測定できる | 自動読み込みだけのLighthouseでは直接測れず、TBTを代理指標にする |
| 使い方 | 何を優先して直すか決める | どの要素・リソース・処理を直すか決める |
PageSpeed Insightsは上から順番に読む
モバイルかデスクトップか
端末区分を混ぜず、主な利用者と問題が出ている側を確認します。一般にモバイルはCPUや回線の制約を受けやすくなります。
URLデータかオリジンデータか
URL単位の標本が不足すると、サイト全体に近いオリジンデータが表示される場合があります。見出しと対象を必ず読みます。
実ユーザーデータの3指標
LCP・INP・CLSのどれが閾値を外れているか、分布のどこに遅い訪問があるかを見ます。
ラボ診断と改善候補
Lighthouseの総合点ではなく、LCP要素、リソース依存、長いタスク、Layout Shiftなど原因へつながる項目を確認します。
問題ページと原因を5段階で絞り込む
全ページへ同じ高速化を適用する前に、どの利用者、ページ群、指標、要素で問題が起きているかを特定します。原因が違えば、最適な修正も変わります。
問題の範囲を端末・URLグループ・指標で分ける
Search Consoleでモバイルとデスクトップ、URLグループ、LCP・INP・CLS、良好・改善が必要・不良を確認します。共通テンプレートの問題か、特定記事の画像や埋め込みだけの問題かを分けます。
代表URLのフィールド値と分布を読む
PageSpeed InsightsでURL単位かオリジン単位か、75パーセンタイル、過去28日の集計であることを確認します。平均値やLighthouse点数だけで優先順位を決めません。
ラボで同じ症状を再現する
DevToolsのPerformanceパネルやLighthouseで、キャッシュなしの初回表示、代表的な画面幅、メニュー・検索・フォームなど重要操作を記録します。
要素・リソース・処理へ結び付ける
LCP要素とその取得経路、遅い操作と長いタスク、Layout Shiftと原因要素を対応付けます。「画像が重い」「JavaScriptが多い」のような抽象論で止めないことが重要です。
一つずつ変更し、機能回帰も確認する
変更前の記録を保存し、一度に複数の最適化を重ねません。見た目、フォーム、計測タグ、広告、アクセシビリティ、主要ブラウザで問題がないか確認します。
| 優先度 | 判断軸 | 例 |
|---|---|---|
| A | 利用者数が多く、事業上重要で、共通テンプレートに影響 | トップ、商品一覧、申込み、問い合わせ、全記事共通ヘッダー |
| B | 影響は大きいが、修正リスクや検証工数も高い | 検索、絞り込み、カート、会員画面、第三者タグ |
| C | 訪問が少ない、問題が限定的、代替導線がある | 古い単発記事、限定キャンペーン、画面外の埋め込み |
LCPは「最大要素が見えるまで」を4つに分解する
LCPは画像容量だけで決まりません。サーバー応答、ブラウザがリソースを見つけるまで、取得時間、取得後の描画までを分けると、効果の高い修正を選びやすくなります。
HTMLの最初の応答を早くする
アプリ処理、データベース、キャッシュ、CDN、リダイレクト、ホスティングを確認します。サーバー移転を先に決めず、代表URLと地域、キャッシュ有無をそろえて測ります。
LCPリソースをHTMLから早く見つける
主要画像をJavaScript実行後やCSS背景だけで追加すると取得開始が遅れます。初期HTMLのimg、適切なpreload、fetchpriorityを検討します。
表示サイズに合う画像を配信する
AVIF・WebP、圧縮、srcset・sizes、CDN、長いキャッシュを検討します。画質を落としすぎず、実際の表示幅より過大な画像を送らないようにします。
CSS・フォント・JavaScriptの待ちを減らす
初期表示に不要なCSSや同期スクリプト、長いメインスレッド処理を減らします。フォントのウェイトと字形を絞り、フォールバック時のレイアウトも確認します。
<link rel="preload" as="image" href="/img/hero.avif" fetchpriority="high">
<img
src="/img/hero.avif"
srcset="/img/hero-800.avif 800w, /img/hero-1400.avif 1400w"
sizes="(max-width: 760px) 100vw, 52vw"
width="1400"
height="875"
fetchpriority="high"
decoding="async"
alt="ページ内容を具体的に説明する代替テキスト"
>- DevToolsで実際のLCP要素を確認した
- TTFB・発見遅延・取得時間・描画遅延のどこが長いか分けた
- LCP画像が初期HTMLにあり、遅延読み込みされていない
- 画像の実表示幅に合うsrcset・sizes・形式を使った
- 不要なCSS・フォント・同期JavaScriptを減らした
INPは遅い操作を特定し、次の描画までを短くする
INPはページ滞在中のクリック、タップ、キーボード入力に対する応答性を測ります。単にJavaScriptの容量を見るのではなく、どの操作が、入力待ち・イベント処理・描画のどこで遅いかを特定します。
入力遅延
利用者が操作してからイベント処理を開始できるまで。長いタスクやスクリプト評価がメインスレッドを占有すると伸びます。
処理時間
イベントハンドラーが完了するまで。大きな再計算、全件フィルタ、同期処理、重い第三者コードが原因になります。
描画遅延
処理完了後、次のフレームを表示するまで。大きなDOM、同期レイアウト、複雑な描画が影響します。
重要操作を実際に記録する
メニュー、検索候補、入力、絞り込み、カート、モーダル、送信など、利用者が目的を達成する操作を優先します。
長いタスクと不要なJavaScriptを減らす
初期表示に不要なコード、第三者タグ、大きなライブラリを見直し、必要な機能だけを読み込みます。
イベント処理を分割し、描画を先に通す
利用者へ見せる更新を先に行い、集計・保存・追加計算は後続タスクへ分けます。処理中の状態もすぐ表示します。
DOM更新と寸法取得の往復を減らす
スタイル変更と要素サイズ取得を交互に行わず、読み取りと書き込みをまとめます。更新対象を必要な範囲へ限定します。
CLSは予期しない移動の発生源に領域を予約する
CLSは時間ではなく、表示中の要素がどれだけ大きく、どれだけ遠く移動したかから計算されます。初期表示だけでなく、同意バナー、広告、埋め込み、遅延コンテンツ、操作後の更新も確認します。
画像・動画へ寸法または縦横比を指定する
imgとvideoへwidth・heightを指定し、レスポンシブ表示ではaspect-ratioを保ちます。読み込み前に領域を確保します。
広告・埋め込み・動的領域を先に確保する
広告、地図、動画、フォーム、通知へmin-heightやaspect-ratioを設定します。内容が返らない場合の空状態も設計します。
既存内容の上へ予告なく挿入しない
上部バナーやメッセージは最初から領域を取るか、必要に応じてオーバーレイにします。操作対象が逃げないことを確認します。
Webフォントとアニメーションを確認する
代替フォントとの寸法差を抑え、必要なフォントだけを早く読み込みます。移動を伴う演出はtransformとopacityを優先します。
<img
src="/img/article.webp"
width="1200"
height="675"
loading="lazy"
decoding="async"
alt="記事画像の内容"
>
<div class="video-frame">...</div>
<style>
.video-frame {
aspect-ratio: 16 / 9;
min-height: 220px;
}
</style>WordPressでCore Web Vitalsを改善する優先順位
WordPressでは、テーマ、プラグイン、画像、フォント、広告、計測タグ、サーバーが重なり、原因が一つとは限りません。高速化プラグインを追加する前に、問題の指標と要素を特定します。
効果が大きく、壊れにくい項目から
- ファーストビュー画像の容量・形式・寸法
- 不要なプラグインと第三者タグ
- フォントの種類・ウェイト・読み込み
- キャッシュ、CDN、PHP、データベース
- テーマ共通部のCSS・JavaScript
一括最適化で起きやすい問題
- LCP画像まで遅延読み込みする
- JavaScript結合でメニューやフォームが壊れる
- 未使用CSS削除で特定ページだけ崩れる
- 複数のキャッシュプラグインが競合する
- 計測タグや同意管理が動かなくなる
| 順序 | 確認・修正 | 主に効く指標 |
|---|---|---|
| 1 | LCP画像、画像寸法、WebP／AVIF、画面外画像の遅延読込 | LCP・CLS |
| 2 | 不要プラグイン、第三者タグ、長いJavaScriptタスク | INP・LCP |
| 3 | キャッシュ、CDN、PHP、DB、リダイレクト、TTFB | LCP |
| 4 | フォント、CSS、広告・埋め込み領域、同意バナー | CLS・LCP |
| 5 | テーマ・プラグイン更新とステージングでの回帰確認 | 全指標・機能 |
実装から公開後検証までの実務フロー
Core Web Vitalsは一度の修正で終わる作業ではありません。変更前の基準を残し、狭い範囲で実装し、機能回帰を確認し、公開後のフィールドデータで継続的に判断します。
変更前の基準を保存する
URL、日時、端末、回線・CPU条件、キャッシュ、ログイン状態、同意バナー、試行回数、LCP要素、代表操作を記録します。
改善仮説を一文で書く
「トップ画像の発見遅延を減らせばLCPが短くなる」「検索候補の全件再計算を分割すればINPが改善する」のように、原因と期待効果を結び付けます。
ステージングで一つずつ実装する
変更範囲を限定し、Chrome・Edge・Safari、モバイル、キーボード、文字拡大、フォーム、画像、計測タグを確認します。
同条件のラボ測定を複数回行う
単発値ではなく複数回の傾向を見ます。対象指標が改善しても、別指標や機能が悪化していないか確認します。
公開日とリリース番号を記録する
公開後のRUM・CrUX推移と重ねられるようにします。広告、キャンペーン、流入構成など同時期の変化も残します。
28日窓を踏まえて日次で追跡する
CrUX系データは過去28日を含むため、公開直後に完全には入れ替わりません。ラボと自社RUMで早期回帰を監視しながら、フィールドの分布を追います。
公開前の最終チェックリスト
- 変更前後を同じURL・端末・回線条件で比較した
- LCP要素、遅い操作、Layout Shiftの原因を実要素まで特定した
- 対象指標だけでなく、他のCore Web Vitalsも確認した
- 主要フォーム、検索、メニュー、決済、ログインが動作する
- Chrome・Edge・Safariと実機モバイルで表示を確認した
- アクセシビリティ、計測タグ、同意管理に回帰がない
- 公開日、変更内容、担当、リリース番号を記録した
Core Web Vitals改善でよくある7つの失敗
Lighthouseの点数だけをKPIにする
総合点は診断の入口です。実ユーザーデータのLCP・INP・CLSと、利用者が目的を完了できるかを合わせて見ます。
平均値だけを見る
平均が速くても、遅い端末や回線で問題が残ることがあります。75パーセンタイルと分布を確認します。
画像圧縮だけでLCPを直そうとする
TTFB、発見遅延、レンダリングブロックが主因なら、画像容量だけ減らしても改善は限定的です。
INPを初期読み込みだけで判断する
INPはページ滞在中の操作を対象にします。検索、入力、メニュー、モーダルなど実際の操作を記録します。
CLSを再読み込み時だけ確認する
同意バナー、広告、遅延コンテンツ、無限スクロール、操作後の通知でも移動が起きます。
複数の高速化を同時に有効化する
何が効いたか、何が壊したか分からなくなります。変更を小さくし、記録と回帰確認を残します。
公開直後のCrUXだけで失敗と判断する
過去28日間のデータが残るため、ラボ・RUM・公開日・日次推移を合わせて評価します。
参照した公式資料
指標、基準、測定期間、改善方法は次の公式資料を2026年7月29日に確認しました。仕様やツール画面は更新されるため、実装前にも再確認してください。
Core Web Vitalsのよくある質問
Core Web Vitalsとは何ですか？
実際の利用者が感じる読み込み、操作応答、表示の安定性を、LCP・INP・CLSで評価する指標です。モバイルとデスクトップを分け、75パーセンタイルで判定します。
PageSpeed Insightsの点数が100ならCore Web Vitalsも良好ですか？
同じ意味ではありません。Lighthouseの点数は設定された条件でのラボ結果です。Core Web Vitalsの合否は、PageSpeed Insights上部のCrUX実ユーザーデータを中心に判断します。
フィールドデータとラボデータが違うのは不具合ですか？
必ずしも不具合ではありません。フィールドは過去28日間の多様な端末、回線、地域、キャッシュ、行動を集計し、ラボは一つの設定で測定します。差から端末差や操作後の問題を探します。
PageSpeed Insightsに実ユーザーデータがない場合は良好ですか？
良好と判定されたわけではありません。対象URLまたはオリジンの標本が不足している可能性があります。Lighthouse、Chrome DevTools、自社RUMで補ってください。
FIDはもう測らなくてよいですか？
Core Web VitalsではINPがFIDを置き換えています。古い記事やダッシュボードがFIDだけの場合はINPへ更新し、ページ滞在中の操作全体を確認します。
WordPressの高速化プラグインだけで改善できますか？
原因によります。キャッシュや遅延読込が役立つ場合もありますが、LCP画像の遅延、JavaScript競合、表示崩れ、計測漏れを起こすこともあります。ステージングで一つずつ変更します。
修正後、Core Web Vitalsの結果はいつ変わりますか？
ラボ結果はすぐ確認できますが、CrUXやPageSpeed Insightsのフィールドデータは過去28日間のローリング集計です。公開日を記録し、RUMと日次推移を合わせて確認します。
Core Web Vitalsが良好なら検索順位は上がりますか？
保証されません。Core Web Vitalsはページエクスペリエンスの一部です。検索意図への適合、内容の品質、クロール・インデックス、内部リンクなどを同時に整えます。
まとめ：実ユーザーデータから始め、原因を分解して一つずつ直す
Core Web Vitalsの現行指標はLCP・INP・CLSです。まずSearch ConsoleとPageSpeed Insightsのフィールドデータから問題のある端末・URLグループ・指標を見つけ、DevToolsとLighthouseで要素・リソース・処理へ分解します。
LCPは応答・発見・取得・描画、INPは入力遅延・処理・描画、CLSは移動した要素と原因要素へ分けると、修正の優先順位が明確になります。実装は一つずつ行い、速度だけでなく機能・アクセシビリティ・計測の回帰も確認してください。
ラボでは変更の効果をすぐ確認し、公開後はRUMとCrUXの28日窓を追跡します。点数のためではなく、利用者が読み、操作し、目的を完了しやすいページを目標に改善を続けることが重要です。