コアウェブバイタルは、Googleがユーザー体験を数値化した指標群で、LCP（表示速度）・INP（応答性）・CLS（安定性）の3つで構成されます。本記事では、各指標が何を測るのか、無料ツールでの診断手順、指標別の具体的な改善策、改善後の運用ルールまで、自社サイトで実施できる形に整理します。数値の合格と検索順位・問い合わせ増加は同一ではない点にも触れます。
良好の境界と、自社サイトの改善手順を分けて説明します。数値の合格だけで検索順位や問い合わせの増加を保証するものではありません。
この記事でわかること 全10テーマ
01コアウェブバイタルとは何か｜3つの体感指標の基礎
Core Web Vitalsは、読み込み、操作への応答、表示の安定性を確認する指標群です。
判定では端末別のページ訪問の測定分布に対する75パーセンタイルを確認します。開発者のPCでの単発測定とは分けて扱います。
| 指標 | 測定内容 | 体験上の意味 |
|---|---|---|
| LCP（Largest Contentful Paint） | 画面内で最も大きな要素が表示されるまでの時間 | 表示の速さ |
| INP（Interaction to Next Paint） | クリックやタップへの応答が画面に反映されるまでの時間 | 操作の快適さ |
| CLS（Cumulative Layout Shift） | ページ利用中の予期しないレイアウト移動の大きさ | 表示の安定性 |
LCP・INP・CLSで読み込み・応答・安定性を確認する。良好域の境界は2.5秒・200ms・0.1。 出典：Core Web Vitals と Google 検索の検索結果について | Google 検索セントラル | Documentation | Google for Developers
Core Web Vitalsの判定では端末別の実利用データの75パーセンタイルを用いる。 出典：Web Vitals | Articles | web.dev
| 指標 | 境界 |
|---|---|
| LCP | 2.5秒以下 |
| INP | 200ミリ秒以下 |
| CLS | 0.1以下 |
02なぜGoogleがこれを評価軸にしたのか
GoogleはCore Web Vitalsをランキングシステムで使用しますが、良好なスコアだけで上位表示は保証されません。
| 比較軸 | 内容 |
|---|---|
| 役割 | ページ体験の一面を測る指標です。順位を単独で決めません。 |
| 優先順位 | 読者の疑問に答える内容と利用時の体験を両方確認します。 |
| 誤解しやすい点 | 数値の合格が順位やコンバージョンの増加を保証するものではない |
| 実務上の意味 | コンテンツと体験の両方を整える運用が必要になる |
03表示速度とユーザー行動の関係をどう捉えるか
速度と問い合わせの関係は、自社の流入・利用環境・変更履歴をそろえて調べます。前後の数値差だけで改善の原因を確定しません。
| 確認項目 | 確認の進め方 |
|---|---|
| 離脱への影響 | 表示速度の区分別に直帰率・離脱率を解析ツールで比較する |
| コンバージョンへの影響 | 速度改善の前後で問い合わせ完了率の推移を同一条件で記録する |
| モバイル比率 | 自社流入に占めるモバイル割合と、モバイル利用者の離脱傾向を確認する |
| 評価の基準環境 | モバイルとデスクトップを分け、測定対象とデータの有無を確かめます。 |
| 状態 | 次に確かめること |
|---|---|
| ラボは良好・実利用は不良 | 対象端末、ページ範囲、操作中の動き、集計期間を確認します。 |
| 実利用データがない | 表示を合格と扱わず、主要な利用手順をラボで再現して原因を調べます。 |
04現状診断｜無料ツール3点で数値を出す
| ツール | 役割 | 確認できること |
|---|---|---|
| PageSpeed Insights | 単一ページの即診断 | 利用可能なフィールドデータと、ラボでの診断を分けて確認します。実利用データが出ない場合もあります。 |
| Search Console | サイト全体の健康診断 | 「ウェブに関する主な指標」レポートでURLを良好・改善が必要・不良の3段階に分類 |
| Chrome DevTools | 原因の深掘り | Performanceタブで読み込みの内訳を可視化し、重い画像や操作を止めるスクリプトを特定 |
| 比較軸 | ラボデータ | フィールドデータ |
|---|---|---|
| 収集方法 | ツールによる疑似環境での測定 | 実際の訪問者の利用から収集 |
| 強み | 原因の再現・切り分けに向く | 判定の基盤になる実測値 |
| 注意点 | 実環境と差が出ることがある | 改善反映まで時間差がある |
05LCP改善｜表示速度を2.5秒以内に収める実践策
TTFBはリクエストから最初のデータが届くまでの時間です。LCPを画像の容量だけで判断せず、応答・取得・描画のどこで待っているかを調べます。
| 原因系統 | 典型的な状態 | 対応策 |
|---|---|---|
| 画像の肥大 | ファーストビューに容量の大きいJPEG画像が載っている | 画像を圧縮し、AVIFなどの次世代形式への変換を検討する |
| サーバー応答（TTFB） | サーバーが最初のデータを返すまでに時間がかかる | CDN導入・サーバー環境の見直し・不要プラグイン整理でTTFBを短縮する |
| 読み込み順の未最適化 | 重要な画像の読み込みが後回しになっている | LCP画像の遅延読み込みを避け、必要な画像のfetchpriorityを検討します。すべての画像を高優先度にはしません。 |
LCP改善の切り分けと修正順
Googleの改善ガイドは、LCP要素の発見・読み込み・描画の遅れを調べ、LCP画像を不要に遅延させない方法を説明しています。 出典：Largest Contentful Paint を最適化する
06INP改善｜操作の応答性を200ミリ秒以内にする
| 区間 | 確認する遅れ |
|---|---|
| 入力遅延 | 操作からイベント処理の開始までです。 |
| 処理時間 | 操作に対応する処理が完了するまでです。 |
| 表示までの遅れ | 処理後の結果が次の画面に描かれるまでです。 |
| 対策 | 具体的内容 |
|---|---|
| JavaScriptの肥大化を断つ | タグ類が多段に載っていないか棚卸しし、本当に必要なものに絞り込む |
| 処理の分割と非同期化 | 長い処理を切り分け、操作を妨げている区間を減らします。実装後に同じ操作で再測定します。 |
| サードパーティの遅延読み込み | 外部機能が必要になるタイミングと依存関係を確かめ、読み込み・実行を見直します。 |
INP問題の確認から修正まで
Googleの改善ガイドは、操作の遅れを入力待ち・処理・次の描画に分けて確認します。 出典：INPを最適化する
07CLS改善｜レイアウトのズレを0.1以下に抑える
CLSは読み込み時だけでなく、ページ利用中の予期しないレイアウト移動も対象になります。動いた要素と、移動を引き起こした要素を区別して調べます。
| 発生源 | 起きていること | 対策 |
|---|---|---|
| 画像・動画 | サイズ未指定のため読み込み後にコンテンツが押し下げられる | width・heightやaspect-ratioで、表示前から適切な領域を確保します。 |
| Webフォント | システムフォントからWebフォントへの置き換えで微細に動く | 代替フォントとの寸法差を減らし、font-display: optionalや必要なフォントの先読みを検討します。swapだけで移動を防げるとは限りません。 |
| 広告・埋め込み | 後から差し込まれる枠がレイアウトを押し広げる | CSSでmin-heightを確保して予約スペースを作る |
CLS対策の実施チェック順
Googleの改善ガイドは、画像や埋め込みの領域確保、フォント切り替えによる移動への対処を説明しています。 出典：Cumulative Layout Shift の最適化
08WordPress運用サイトの改善ルート
テーマやプラグインは本番で試さず、戻せる検証環境で機能と速度を照合します。製品名や機能数だけで軽さを決めません。
| 着手点 | 狙い | 選定・実施時の確認条件 |
|---|---|---|
| 軽量テーマへの切り替え | 多機能テーマは未使用機能のCSS・JSが肥大しがち | 必要機能だけを載せた構成か、公式情報で更新状況を確認する |
| キャッシュ系プラグイン | ページキャッシュ・ブラウザキャッシュ・画像遅延読み込みを一括設定できる | 自社サーバー環境との対応を公式案内で確認し、導入前後で速度を測定する |
| 不要プラグインの棚卸し | 実際に読み込むCSS・JavaScriptと処理を確認します。個数だけで速度を判断しません。 | 用途と依存関係を確認し、停止・削除後も必要な機能が動くかを検証します。 |
WordPressの変更を検証する順序
09改善後の運用｜継続して数値を守る仕組み
| 仕組み | 具体的な運用 |
|---|---|
| 月次モニタリング | 前月比で「不良」が増えていないか、新しいURLパターンが「改善が必要」に分類されていないかを点検する |
| リグレッションチェック | 変更直後に同条件で再測定します。悪化したら直前の変更と他の条件を切り分けます。 |
| 社内ルールへの組み込み | 外部スクリプト追加は速度影響を確認してから決裁、テーマ・プラグイン更新は本番反映前にステージング環境で測定する |
変更から検知までの運用サイクル
相談前に、主要ページのモバイルスコアの記録、Search Consoleの不良URL一覧、現在のテーマ・プラグイン一覧を用意すると討議が進めやすくなります。
自社の状況を相談する10自分で記録・照合できる実務のまとめ
| 記録項目 | 記録する内容 |
|---|---|
| 測定日・対象URL | いつ・どのページを測ったかを必ず併記する |
| フィールドデータ | LCP・INP・CLSの実利用データと判定区分 |
| 実施した変更 | 画像圧縮・スクリプト整理など対策内容と実施日 |
| 変更後の推移 | 次回月次点検での分類の変化 |
| 判断メモ | 次に着手する原因系統と優先度の根拠 |
AUTHOR & EDITOR
原著：小沢 宗弘
山梨県甲府市を拠点に、ホームページ制作・SEO支援・Web広告運用に取り組んでいます。
再編集：株式会社オフィスVONDS
原記事の実務論点を保ち、公式資料で確認できる説明と編集上の手順提案を区別して再編集しました。
参照した一次資料
実務の進め方はVONDS編集部の整理です。本文で参照した仕組み・手順は、次の公式資料で確認しています。
- Core Web Vitals と Google 検索の検索結果について | Google 検索セントラル | Documentation | Google for Developers確認日：2026年9月7日
- Web Vitals | Articles | web.dev確認日：2026年9月7日
- Largest Contentful Paint を最適化する確認日：2026年9月7日
- INPを最適化する確認日：2026年9月7日
- Cumulative Layout Shift の最適化確認日：2026年9月7日