Core Web Vitalsとは何か、中小企業が気にすべき理由は？
Core Web Vitalsとは、Googleが定めるページ体験の品質指標で、LCP・INP・CLSの3指標から構成されます。2021年6月に検索ランキングシグナルとして正式採用されており（出典: Google Search Central公式ブログ「Page experience update and more」）、制作・リニューアル後のサイトは公開前に必ず計測する必要があります。
LCP・INP・CLSそれぞれの定義と合格基準値
3指標の意味と合格基準は次のとおりです（出典: Google Search Central「Core Web Vitals」公式ドキュメント）。
| 指標 | 正式名称 | 意味 | 良好（Good）の基準 |
|---|---|---|---|
| LCP | Largest Contentful Paint | ページ内の最大コンテンツが画面に描画されるまでの時間 | 2.5秒以内 |
| INP | Interaction to Next Paint | クリックや入力への応答が画面に反映されるまでの時間 | 200ミリ秒以内 |
| CLS | Cumulative Layout Shift | ページ表示中にレイアウトがずれる量の累積スコア | 0.1以下 |
各指標は「Good（良好）」「Needs Improvement（要改善）」「Poor（不良）」の3段階で評価されます。検索ランキングへの影響が生じるのは、実ユーザのデータ（Field Data）が「Poor」または「Needs Improvement」に集中している場合です。
LCPは読み込み速度の体感に直結し、CLSは「読もうとしたらボタンがずれた」という操作ミスの原因になります。INPは操作への反応速度であり、フォームや問い合わせボタンを多用するサイトで特に重要です。
Field DataとLab Dataの違い、どちらを優先すべきか
計測データには2種類あり、改善の優先判断を誤らないために区別が必要です。
Field Data（実環境データ）
- 実際のユーザが御社のサイトを訪問した際の計測値を集計したもの
- Google Search Consoleや PageSpeed InsightsのCrUX（Chrome User Experience Report）として表示される
- 検索ランキングのシグナルとして実際に使われるのはこちら
- データが蓄積されるまでに一定のトラフィックが必要であり、新規サイトや低トラフィックサイトでは表示されない場合がある
Lab Data（模擬環境データ）
- PageSpeed InsightsやLighthouseが一定の条件下でシミュレートした計測値
- トラフィックに関係なく即座に取得でき、改善施策の効果確認に使いやすい
- ただし実ユーザの環境（端末性能・回線速度）を完全には再現できない
優先すべきはField Dataです。検索順位に影響するのはField Dataであるため、Lab Dataのスコアが高くても Field Dataが悪ければ評価は上がりません。Field Dataが取得できる場合は常にそちらを基準に改善の判断をしてください。新規サイトや小規模サイトでField Dataが取れない場合は、Lab DataでGoodを達成することを暫定目標として設定します。
各指標の具体的な改善手順はこのあとのセクションで順に解説します。
まず何をすべきか？計測ツールの選び方と起動手順
最初にPageSpeed Insightsを使い、モバイルスコアを確認するところから始めてください。URLを入力するだけで3指標すべてのField Dataと改善優先度が表示されます。
無料で使えるツールは複数ありますが、最初の1本に選ぶべき理由はシンプルです。PageSpeed InsightsはGoogleが公式に提供しており、実ユーザデータ（Field Data）とLab Dataの両方を同一画面で確認できます。計測に技術的な前提知識は不要です。
PageSpeed Insightsの読み方（Field Data / Diagnostics / Opportunities）
PageSpeed Insightsは、pagespeed.web.dev にアクセスし、調べたいページのURLを入力するだけで使えます。所要時間は1分もかかりません。
結果画面は大きく3つのブロックに分かれています。それぞれの役割を理解してから数値を読むと、何を直すべきかが明確になります。
| ブロック名 | 表示される内容 | 優先度 |
|---|---|---|
| Field Data（実データ） | 過去28日間の実ユーザのLCP・INP・CLSスコア | ★★★ 最優先で確認 |
| Opportunities（改善機会） | 実施すれば読み込み時間を短縮できる施策の一覧 | ★★ 次に確認 |
| Diagnostics（診断） | パフォーマンスに関する詳細な技術情報 | ★ 原因調査に使う |
つまずきやすい点: Field Dataエリアに「十分なデータがありません」と表示されるケースがあります。これはそのページへの実訪問数が少なく、Googleがデータを収集できていない状態です。その場合はLab Dataのみが表示されます。Lab DataはあくまでGooglebotの仮想環境での測定値のため、実ユーザの体感とずれることがある点に注意してください。
画面上部のタブで「モバイル」と「デスクトップ」を切り替えられます。検索エンジンはモバイルファーストインデックスを採用しているため、モバイルのField Dataを必ず先に確認してください。
各指標の判定色は以下の3段階です。
- 緑（Good）: 合格。対応は維持のみ
- 橙（Needs Improvement）: 要改善。優先度を上げて対処する
- 赤（Poor）: 不合格。検索順位への悪影響リスクがある
Google Search Consoleの「ウェブに関する主な指標」レポートとの使い分け
Google Search Console（以下、GSC）にも「ウェブに関する主な指標」という専用レポートがあります。PageSpeed InsightsとGSCは役割が異なるため、目的に応じて使い分けてください。
| 比較項目 | PageSpeed Insights | GSC「ウェブに関する主な指標」 |
|---|---|---|
| 主な用途 | 特定URLの詳細分析 | サイト全体の問題把握 |
| データの単位 | 1ページずつ | ページグループ（URL群）単位 |
| アクセス | ログイン不要 | GSCプロパティ登録が必要 |
| 向いている場面 | 改善前後の比較検証 | どのページ群から着手すべきか判断する |
GSCのレポートでは、類似したURL（例: /blog/ 配下の記事一覧）をまとめてスコアが表示されます。「Poor URLが集中しているグループ」を発見するのに優れており、サイト全体の優先順位付けに使います。
実務上の推奨フロー:
- まずGSCで「Poor」に分類されているURLグループを特定する（所要時間: 5〜10分）
- そのグループの代表URLをPageSpeed Insightsに貼り付け、Opportunitiesを確認する（所要時間: 1〜2分）
- 改善施策を実施したら、同じURLで再度PageSpeed Insightsを計測して変化を確認する
改善施策の具体的な内容は、LCP・CLS・INP別に次のセクション以降で詳しく解説します。
LCP（最大コンテンツの描画）を「Good」にする改善手順
LCPの合格基準は2.5秒以内です。原因の大半は画像の最適化不足とサーバ応答の遅さにあるため、この2点を先に対処するだけでスコアが大きく改善します。
LCP（Largest Contentful Paint）とは、ページを開いてから最も大きな画像またはテキストブロックが描画完了するまでの時間です。訪問者が「表示された」と感じる体感速度に最も直結する指標です。
| 評価 | LCP値 |
|---|---|
| Good（合格） | 2.5秒以内 |
| Needs Improvement | 2.5秒超〜4.0秒以下 |
| Poor（不合格） | 4.0秒超 |
改善は次の3手順で進めてください。後述するCLSやINPの対応より先に取り組むことで、体感速度の改善効果が最も大きく出やすいのが、実装上の特徴です。
手順1: LCP要素を特定し、画像をWebP化・サイズ指定する
最初にLCPの対象要素（LCP Element）を特定します。PageSpeed InsightsのDiagnosticsセクションに「Largest Contentful Paint element」として表示されるため、まずここを確認してください。
対象がJPEGまたはPNG画像だった場合、WebPへの変換が最優先の対処になります。WebPはJPEGと比較して同等の画質でファイルサイズを削減できるため、転送量が減り読み込み速度が向上します。
つまずきやすい点: WebPに変換しても<img>タグにwidthとheight属性が抜けていると、CLSの原因にもなります。変換と同時に必ず両属性を追記してください。
具体的な対応手順は以下のとおりです。
- PageSpeed Insightsで「Largest Contentful Paint element」を確認し、対象の画像URLをメモする（所要時間: 約5分）
- 変換ツール（Squoosh、cwebpコマンド等）でWebP形式に変換し、元ファイルと置き換える（所要時間: 1枚あたり約2〜5分）
<img>タグにwidth属性とheight属性を追加し、表示サイズと実寸を合わせる（所要時間: 約10分）- PageSpeed Insightsで再計測し、LCP値が短縮されたことを確認する（所要時間: 約3分）
手順2: fetchpriority="high"でLCP画像を優先読み込みする
fetchpriority="high"は、ブラウザに対して「この画像を優先してダウンロードしてほしい」と指示するHTML属性です。LCP要素に指定するだけで、他のリソースより先に取得されるため、描画開始が早まります。
<img
src="hero.webp"
width="1200"
height="630"
fetchpriority="high"
alt="サービス紹介画像"
/>
つまずきやすい点: fetchpriority="high"を複数の画像に同時に指定すると優先度が分散し、逆効果になります。LCP要素1枚のみに限定してください。
また、WordPressを使用している場合、テーマのヘッダー画像にこの属性を追加するにはテーマのテンプレートファイル（多くの場合header.php）を直接編集する必要があります。プラグインで対応可能なケースもありますが、テーマのアップデートで上書きされるリスクがあるため、子テーマへの変更が推奨です。
手順3: サーバ応答時間（TTFB）をキャッシュ設定で短縮する
TTFB（Time to First Byte）とは、ブラウザがリクエストを送信してからサーバが最初の1バイトを返すまでの時間です。TTFBが長いと、画像の最適化を行っても手順1・2の効果が十分に出ません。
PageSpeed InsightsのDiagnosticsに「Reduce initial server response time」と表示されている場合は、TTFBが問題です。
対処の優先順位は以下のとおりです。
- ページキャッシュの有効化: WordPressであればWP Super Cache、W3 Total Cache等のキャッシュプラグインを導入する（所要時間: 約30分）
- 静的アセットのキャッシュヘッダ設定:
.htaccessまたはNginx設定にCache-Controlヘッダを追記し、CSS・画像・フォントをブラウザにキャッシュさせる（所要時間: 約20〜60分。設定ファイルの編集が必要） - CDN（コンテンツデリバリネットワーク）の導入: 地理的に遠いユーザへの応答を高速化する。Cloudflare等の無料プランから試せる（所要時間: 初期設定に約2〜4時間）
つまずきやすい点: キャッシュを有効化すると、コンテンツ更新後も古いページが表示され続けることがあります。更新作業のたびにキャッシュをクリアする手順を社内フローに組み込んでおいてください。
3手順を完了したら、再度PageSpeed Insightsでモバイルスコアを計測し、Field DataのLCP値が2.5秒以内（Good）に入ったかを確認します。Field Dataは実ユーザのデータ蓄積に時間がかかるため、Lab Dataのスコアを先に参考値として確認する方法については、前セクションで説明したとおりです。