Core Web Vitalsとは、ウェブページの読み込み、操作への反応、表示の安定性を測る3つの指標のことです。LCP・INP・CLSを使い、訪問した人が内容を待たずに読み、操作できるかを確かめます。
自社サイトでは、Search Consoleの「ウェブに関する主な指標」を開き、モバイルの問題から確認してください。問題のある製品ページをPageSpeed Insightsで調べ、画像・スクリプト・表示のずれのどこを直すか決めます。
検索結果への表示回数やクリックを数えるレポートとは別です。検索の数字を読む方法はSearch Consoleで最初に見る4つの数字で扱っています。
LCP・INP・CLSは何を測る？
web.devのWeb Vitalsと、Google検索セントラルのCore Web Vitalsの説明で確認した基準です。
| 指標 |
測るもの |
良好のしきい値 |
| LCP |
画面内で最大の画像や文章の表示まで |
2.5秒以下 |
| INP |
クリックやタップなどへの反応 |
200ミリ秒以下 |
| CLS |
予期しないレイアウトのずれ |
0.1以下 |
LCPの仕様で測るのは、ページ内の全画像が読み終わるまでの時間ではありません。最初に見える大きな製品写真や見出しの文章が、いつ表示されたかに関わります。
INPの仕様で測るのは、ボタンを押した後に画面へ次の描画が出るまでの応答性です。最初の操作だけでなく、ページを使っている間の操作を評価します。製品一覧を絞り込むたびに画面が固まるなら、読み込みが速くても操作は快適ではありません。
CLSには秒の単位がありません。読み始めた文章が画像の出現で下へ動く、押そうとしたリンクの位置がずれる、といった現象を数値にします。単にページが縦に長いことを測る数字ではありません。
75パーセンタイルで良好とは、どういう意味？
測った値を小さい順に並べたときの、75%の位置の値で判断します。平均値でも、担当者のパソコンで一度測った値でもありません。モバイルとパソコンを分け、3指標すべてが基準内かを見ます。
たとえば、速い回線では製品写真がすぐ出ても、スマホ利用者の多くが待たされていれば、担当者の体感だけでは問題を見つけられません。実際の利用データを先に確認する理由です。
以前は、最初の入力への遅延を測るFIDが使われていました。web.devの移行告知のとおり、2024年3月12日にINPへ置き換わっています。FIDの測定結果だけが残る古い報告書は、現在の判定と区別してください。
Search ConsoleとPageSpeed Insightsはどう使い分ける？
サイト内で問題が広がっている場所を探すのがSearch Console、具体的なURLで原因を調べるのがPageSpeed Insightsです。ただし「前者は実測、後者は試験だけ」という分け方は正しくありません。PageSpeed Insightsには両方があります。
| ツール・欄 |
データ |
読み取ること |
| Search Consoleの主な指標 |
実際の利用データ |
問題の種類と似たURLのまとまり |
| PageSpeed Insightsの実測欄 |
CrUXの過去28日間 |
ページまたは配信元の利用体験 |
| PageSpeed Insightsの診断欄 |
Lighthouseの試験 |
その試験条件での原因と改善箇所 |
Search Consoleの公式ヘルプでは、似たページをURLグループにまとめて表示すると説明しています。例示されたURLだけの問題とは限りません。共通の製品テンプレートが原因なら、同じ形のページも確認します。
PageSpeed Insightsの仕様によると、実測欄はChrome User Experience Report（CrUX）を使います。対象ページのデータが足りないと、同じオリジン、つまり同じ配信元全体のデータを使います。それも足りなければ実測値は出ません。画面の対象が「このURL」か「オリジン」かを読んでください。
実測欄が無いことは、良好とも不良とも判定できない状態です。訪問が少ない中小企業のサイトでは、試験結果と実機操作で不具合を探し、実測値が出るまで何もしない状態を避けます。
性能スコアが高くても、操作を試す
Lighthouseの読み込み試験は、訪問者が行うすべての操作を再現しません。初期表示の性能スコアだけで、絞り込みやメニューを押した後のINPまで良好と判断しないでください。
制作担当には「点数を上げて」だけでなく、「スマホで材料を切り替えると反応が遅い」のように操作を伝えます。同じ画面で操作の記録を取り、処理時間を調べてもらいます。
検索順位にはどのくらい効く？
ページエクスペリエンスについて、Googleは説明ページで、次のように書いています。
Core Web Vitals are used by our ranking systems.
順位づけの仕組みで使う、という説明です。同じ資料は、レポートで良い結果を得ても上位表示は保証されず、SEOのためだけに完全な点数を追うのは時間の使い方として適切でないこともある、としています。
関連性の高い内容を返すことが優先され、体験の良さも検索で役立つという位置づけです。「LCPを何秒縮めると何位上がる」という換算には使えません。
技術記事に必要な加工条件が書かれていないなら、速度だけ直しても問いへの答えは増えません。表示されているのにクリックされないページの直し方と分担し、本文の不足と操作上の不具合を別々に記録します。
中小企業のサイトでは、何から直す？
次の順番は、限られた作業時間で直す範囲を決めるための手順です。Googleが全サイト共通の修正順を指定しているわけではありません。問題が出た指標に合わせて入れ替えます。
1. 相談につながるページと共通部品を選ぶ
トップだけでなく、主力製品、技術記事、問い合わせへ進むページを開きます。スマホで同じ画像部品やメニューを使っていれば、共通部分から調べます。
製造業なら、設備紹介の動画が全ページで自動読み込みされる設計を考えます。技術記事を読む人にも同じ負担がかかります。その動画が必要なページだけへ移す、再生操作の後に読み込む、といった整理から始めます。
2. LCPなら、大きな画像と読み込み開始を調べる
カメラから出したままの製品写真を、小さな表示枠に読み込ませていないか確認します。表示寸法に合った画像を用意し、通信量を減らします。ただし検査用の傷や加工面が判別できなくなる圧縮は避けます。
web.devのLCP改善手順は、LCPになる画像を遅延読み込みしないよう注意しています。すべての画像に一括でloading="lazy"を付けると、最初に必要な写真まで待たせるためです。画像自体より前にサーバーの応答で待っているなら、その時間も分けて調べます。
3. INPなら、不要なスクリプトと重い操作を減らす
チャット、解析タグ、スライダーなどが重複していないかを見ます。使っていない部品を外し、必要な処理は実行時期や分け方を制作担当に調整してもらいます。
web.devのINP改善手順では、入力待ち、処理、次の描画までを分けて調べます。ファイルの容量だけでなく、読み込んだ後にブラウザへどれだけ仕事をさせるかも確認します。
4. CLSなら、画像や埋め込みの場所を先に確保する
web.devのCLS改善手順は、寸法の無い画像や埋め込み、後から挿入する内容、ウェブフォントを原因として挙げています。画像の幅と高さ、動画枠の縦横比などを指定し、表示前から場所を取ります。
相談ボタンの直前に後からバナーが入るなら、実機で押す位置が動かないか確認してください。指標を改善しても窓口が見つからなければ相談は進みません。導線自体はBtoBサイトの問い合わせ導線で点検できます。
修正後は、いつ何を確認する？
公開した日に、同じURLと同じ操作を試験し直します。画像が出るか、メニューが開くか、フォームへ進めるかまで確認し、軽くする作業で必要な機能を壊していないかを見ます。
実測値は過去28日間を含むため、公開直後にすべてが置き換わるわけではありません。修正日、対象ページ、指標、実測と試験の区別を残し、その後の推移を確認します。順位が動いても、同時期の本文修正などを無視して速度だけの効果としないでください。
依頼時には問題のURLと操作、測定画面、修正したい共通部品を渡せば、作業範囲を絞れます。計測と改善では、検索での表示とサイトに入った後の行動を合わせて確認します。
仕様・出典の確認日：2026年10月22日。