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が集中しているグループ」を発見するのに優れており、サイト全体の優先順位付けに使います。

実務上の推奨フロー:

  1. まずGSCで「Poor」に分類されているURLグループを特定する（所要時間: 5〜10分）
  2. そのグループの代表URLをPageSpeed Insightsに貼り付け、Opportunitiesを確認する（所要時間: 1〜2分）
  3. 改善施策を実施したら、同じ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の原因にもなります。変換と同時に必ず両属性を追記してください。

具体的な対応手順は以下のとおりです。

  1. PageSpeed Insightsで「Largest Contentful Paint element」を確認し、対象の画像URLをメモする（所要時間: 約5分）
  2. 変換ツール（Squoosh、cwebpコマンド等）でWebP形式に変換し、元ファイルと置き換える（所要時間: 1枚あたり約2〜5分）
  3. <img>タグにwidth属性とheight属性を追加し、表示サイズと実寸を合わせる（所要時間: 約10分）
  4. 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が問題です。

対処の優先順位は以下のとおりです。

  1. ページキャッシュの有効化: WordPressであればWP Super Cache、W3 Total Cache等のキャッシュプラグインを導入する（所要時間: 約30分）
  2. 静的アセットのキャッシュヘッダ設定: .htaccessまたはNginx設定にCache-Controlヘッダを追記し、CSS・画像・フォントをブラウザにキャッシュさせる（所要時間: 約20〜60分。設定ファイルの編集が必要）
  3. CDN（コンテンツデリバリネットワーク）の導入: 地理的に遠いユーザへの応答を高速化する。Cloudflare等の無料プランから試せる（所要時間: 初期設定に約2〜4時間）

つまずきやすい点: キャッシュを有効化すると、コンテンツ更新後も古いページが表示され続けることがあります。更新作業のたびにキャッシュをクリアする手順を社内フローに組み込んでおいてください。

3手順を完了したら、再度PageSpeed Insightsでモバイルスコアを計測し、Field DataのLCP値が2.5秒以内（Good）に入ったかを確認します。Field Dataは実ユーザのデータ蓄積に時間がかかるため、Lab Dataのスコアを先に参考値として確認する方法については、前セクションで説明したとおりです。

CLS（レイアウトのずれ）を0.1以下に抑える改善手順

CLSの合格基準は0.1以下です。原因の9割は画像・広告・フォントの寸法未指定にあるため、要素に幅と高さを明示するだけで解決するケースがほとんどです。

CLSとは、ページ読み込み中にコンテンツが予期せず動いてしまう現象を数値化した指標です。たとえば記事を読もうとした瞬間に広告が差し込まれてボタンを誤タップした、という体験がCLS悪化の典型です。

手順1: Layout Shift Regions機能で「ずれている要素」を特定する

改善の前に「どの要素がずれているか」を可視化することが先決です。ChromeのDevToolsに内蔵されているLayout Shift Regionsを使うと、ずれが発生した要素が青色でハイライト表示されます。

操作 手順
DevToolsを開く F12キー（WindowsはF12、MacはCmd+Option+I）
Renderingパネルを表示 右上の「…」→「More tools」→「Rendering」
レイアウトずれを可視化 「Layout Shift Regions」にチェックを入れる
対象ページを再読み込み Ctrl+R（Cmd+R）でページをリロードする

つまずきやすい点: Renderingパネルはデフォルトで非表示です。「Elements」や「Console」タブと並んでいないため、More toolsから明示的に開く必要があります。

PageSpeed Insightsの「Diagnostics」セクションにも「Avoid large layout shifts」として原因要素が列挙されるため、両方を照合すると確認がスムーズです。

手順2: imgタグにwidth/height属性を追加し、aspect-ratioを確保する

所要時間の目安: 画像10〜20枚あたり30分程度

画像に幅と高さが指定されていないと、ブラウザは読み込み完了まで表示領域を確保できず、後からレイアウトを押し広げます。これがCLS悪化の最大原因です。

<!-- 修正前: サイズ未指定 -->
<img src="hero.webp" alt="サービス紹介">

<!-- 修正後: width/height属性を追加 -->
<img src="hero.webp" alt="サービス紹介" width="800" height="450">

width/height属性を追加すると、モダンブラウザはCSSでaspect-ratio: 800 / 450を自動計算し、画像読み込み前から表示領域を確保します。

WordPressを使用している場合、メディアライブラリへのアップロード時に元画像のサイズ情報が保存されるため、the_post_thumbnail()やwp_get_attachment_image()関数は標準でwidth/height属性を出力します。ただしサードパーティのビルダープラグイン（Elementor等）経由で挿入した画像は属性が省略されるケースがあるため、ソースコードを直接確認してください。

広告枠のCLS対策として、バナー表示前にもmin-heightでスペースを確保することが有効です。

.ad-container {
  min-height: 250px; /* 広告の最小高さを予約 */
}

手順3: Webフォントにfont-display: swapを設定してFOIT/FOUTを抑制する

所要時間の目安: CSSファイルの編集で5〜10分

Webフォントの読み込み遅延は、テキストの非表示（FOIT: Flash of Invisible Text）や別フォントへの一時差し替え（FOUT: Flash of Unstyled Text）を引き起こし、CLSに影響します。

font-display: swapを指定すると、Webフォントが読み込まれるまでシステムフォントで代替表示し、フォント差し替え時のレイアウトずれを最小化できます。

@font-face {
  font-family: 'NotoSansJP';
  src: url('/fonts/NotoSansJP.woff2') format('woff2');
  font-display: swap; /* ← この1行を追加する */
}

Google Fontsを使用している場合は、URLパラメータに&display=swapを追記するだけで適用されます。

<link href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP&display=swap" rel="stylesheet">

実装者視点の注意点: font-display: swapはFOUTを完全になくすのではなく、CLSスコアへの影響を許容範囲内に抑えるものです。フォント差し替えによる字体の変化が大きい場合（例: 欧文フォントと日本語フォントの混在）は、代替フォントのline-heightやletter-spacingをCSS側で調整しておくと、差し替え時のずれが小さくなります。

以上3手順を順に実施することで、多くの中小企業サイトでCLSを0.1以下に改善できます。改善後のスコア確認方法については「改善後の継続モニタリングと再チェックの頻度は？」で後述します。

制作・リニューアル発注時にCore Web Vitalsを要件に組み込む方法は？

制作会社への発注仕様書に「PageSpeed InsightsのField DataでLCP・INP・CLSすべてGood評価」を納品条件として明記することで、公開後のスコア不足リスクを発注前に排除できます。口頭での確認に留めると、納品後の改善費用が別途発生するケースが少なくありません。

仕様書に書くべきCWV要件の文例と確認タイミング

仕様書にCWV要件を盛り込む際は、以下の3点を明示することが重要です。

記載項目 具体的な記述例
合格基準 「PageSpeed Insights（モバイル）のField DataにてLCP 2.5秒以内・INP 200ミリ秒以内・CLS 0.1以下をすべて満たすこと」
確認ツール 「Google PageSpeed Insights（URL: pagespeed.web.dev）を使用し、計測結果のスクリーンショットを納品物に含めること」
確認タイミング 「公開前のステージング環境でLab Dataを確認、公開後28日時点でField Dataを再確認し報告すること」

確認タイミングは2段階に分けることがポイントです。公開前はLab Dataで技術的な問題をつぶし、公開後はField Dataで実ユーザの体験を検証します。Field Dataは収集に最大4週間かかるため、検収期限を公開から35日以上後に設定してください。

制作会社を選定する段階では、「過去案件のPageSpeed Insightsスコアを見せてもらえるか」を打診するとよいでしょう。対応できる会社であれば、数値付きの実績データをすぐに提示できます。

当社の品質保証基準

当社（株式会社ノーティックラボ）では、ホームページ制作においてCWVの品質を以下のように担保しています。

PREMIUMプラン: Core Web Vitals（LCP・INP・CLS）のGood評価を納品条件として保証します。公開後のField Dataレポートを提出し、基準未達の場合は追加費用なしで対応します。

STANDARDプラン（60万円から）: 設計段階からCWVを意識した実装を行います。具体的には、LCP画像のWebP化・fetchpriority設定、全imgタグへのwidth/height付与、フォント読み込み最適化を標準作業として含みます。

（出典: 自社料金表）

実装者として設計段階から関わることが、最終的なスコアの安定につながります。制作後に改善を依頼すると、テンプレートやプラグインの構造上、根本的な対処が難しい場合があります。発注前の段階でCWV対応を仕様に含めることを強くお勧めします。

御社のサイトが現在どの指標で基準を下回っているかを把握するところから始めたい方には、無料診断をご用意しています。URLをお知らせいただければ、LCP・INP・CLSの現状値と優先対応箇所をレポートにまとめてお伝えします。

[無料診断を申し込む（/diagnostic）]

改善後の継続モニタリングと再チェックの頻度は？

CWVのField Dataは過去28日間の実ユーザデータを集計するため、改善施策を反映してから結果がスコアに現れるまで最大4週間かかります。月次でSearch Consoleを確認する運用を標準にしてください。

なぜ「改善したのにスコアが変わらない」と感じるのか

Field Dataとは、実際にサイトを訪れたユーザのブラウザから収集されるデータです。Googleは過去28日分を累積して集計するため、施策を適用した翌日にスコアが改善されることはありません。

改善前のデータが集計ウィンドウから完全に抜けきるまで、数値は緩やかにしか変化しません。「直した」のにスコアが動かないように見える原因の多くは、この集計ラグです。

推奨する月次モニタリングの手順

以下の順番で確認すると、問題の見落としを防げます。

  1. Google Search Console を開く（所要時間: 5分） 「ウェブに関する主な指標」レポートを確認し、「不良」「改善が必要」のURLが増えていないかチェックします。増えていた場合は原因となるページ群を特定します。
  2. 該当ページを PageSpeed Insights で個別計測する（所要時間: 10〜15分） モバイルを優先し、Field DataとDiagnosticsの両方を確認します。前月と比較して悪化した指標がある場合は、直近のサイト変更（プラグイン追加、画像差し替え、広告タグ追加など）と照合します。
  3. チェック結果をスプレッドシートに記録する（所要時間: 5分） URL、計測日、LCP・INP・CLSの数値を残します。月次の変化を可視化することで、施策の効果検証と劣化の早期検知が両方できます。

つまずきやすい点: Search Consoleの「ウェブに関する主な指標」レポートに表示されるURLが実際のURLと異なるケース（正規化設定の影響）があります。表示されたURLではなく、PageSpeed Insightsで実際にアクセス可能なURLを計測してください。

スコアが再び悪化しやすいタイミング

改善後も一定のサイクルで劣化が起こりやすい場面があります。発生前に対策を準備しておくと手戻りを防げます。

劣化を招きやすい変更 影響を受けやすい指標 確認すべき対策
サードパーティ広告タグの追加 INP、LCP タグを遅延読み込み（defer）に設定する
プラグインのアップデート CLS、INP アップデート後に PageSpeed Insights で再計測する
ヒーロー画像・バナーの差し替え LCP、CLS 新画像にwidth/height属性とfetchpriority="high"を付与する
WordPressテーマ変更 全指標 ステージング環境で先行計測してから本番に反映する
動画埋め込みの追加 LCP、INP サムネイル表示＋クリック後読み込み（ファサードパターン）を採用する

「月次」以外に確認が必要な場合

大規模なサイト改修や新機能のリリース直後は、月次を待たずに計測します。ステージング環境でLab DataをPageSpeed Insightsで確認した上で本番に反映し、反映後1週間の時点でもう一度計測するサイクルが有効です。

サイト訪問数が少ない中小企業のサイトでは、Field Dataの収集に必要なサンプル数（CrUXの閾値）を下回り、Search Consoleにデータが表示されないことがあります。その場合はLab Dataを主指標として、PageSpeed Insightsで月次計測を継続してください。

現在のスコアを確認して、次のアクションを明確にしたい場合は、当社の無料診断をご活用ください。 御社サイトのURL共有だけで、LCP・INP・CLSの現状と優先改善箇所をレポートとしてお渡しします。

無料診断を受ける（/diagnostic）

関連リンク