Core Web Vitals（コアウェブバイタル）｜Webマーケティング

30秒で理解

Core Web Vitalsは、ページの体験を「表示されるまで」「操作に反応するまで」「画面が動かないか」の3方向から測る指標です。現在の構成は、LCP・INP・CLSです。

これはサーバーの速さだけを測る数字ではありません。実際の利用者の端末や通信環境で、ページがどう体験されたかを確認するための共通のものさしです。

店にたとえると、開店して商品が見えるまで、店員に声をかけて返事が来るまで、棚がぐらつかないかを測ります。入口の応答だけ速くても、商品が見えなかったり、触った瞬間に棚が動いたりすれば、体験は良いとは言えません。

3つの指標は、同じ「速さ」ではなく、別々の体験を見ています。Googleの目安では、良好と判定される境界はLCPが2.5秒以下、INPが200ミリ秒以下、CLSが0.1以下です。

判定は、1回のテスト結果だけで決めません。実際のページ表示を集計し、通常は75パーセンタイルの値で見ます。端末による差があるため、モバイルとデスクトップは分けて確認します。

目的によって開く画面を分けます。Search Consoleはサイト全体の傾向と、同じ問題を持つURLグループの発見に向いています。1つのURLをその場で測るときは、PageSpeed Insightsを使います。

知りたいこと	開く場所	読み方
実際の利用者の傾向	Search Console → Core Web Vitals	モバイル／デスクトップを選び、Poor・Need improvement・Goodの件数を見る
問題のまとまり	Search Console → Core Web Vitals → 詳細	ステータスと指標の組み合わせを選び、例のURLを開く
特定URLの現在の状態	PageSpeed Insights	URLを入力し、フィールドデータとラボデータを分けて確認する
公開前の回帰	Lighthouseなどのラボ測定	同じ条件で変更前後を比較する

Search Consoleのレポートは、実ユーザーデータをURLグループ単位で集計します。データが足りないURLや、まだインデックスされていないURLは、レポートに出ないことがあります。

「PageSpeed Insightsで100点なら、すべての利用者に速い」とは限りません。ラボ測定は再現条件でのテスト、フィールドデータは実際の利用者の記録です。端末、通信、操作内容が違えば結果も変わります。

また、1つの指標だけ良ければページ全体がGoodになるわけでもありません。Search Consoleでは、URLグループ内の指標のうち悪い状態が、そのグループのステータスになります。

「データがない」は「問題がない」ではありません。Search Consoleでデータなしと表示されたら、プロパティが新しいか、選んだ端末のCrUXデータが十分かを確認します。特定URLの確認が必要なら、そのURLをPageSpeed Insightsで測定します。

問題を見つけたら、次の順で画面を開きます。最初から全ページのソースを調べる必要はありません。

順番	開く場所	操作	次の判定
1	Search Console → Core Web Vitals	モバイルとデスクトップを別々に開き、Poorの行を選ぶ	どの端末で問題が出ているか分かる
2	詳細画面の問題行	LCP・INP・CLSのどれが該当するか確認し、例のURLを1つ開く	同じURLグループの問題だと分かる
3	PageSpeed Insights	例のURLを入力し、フィールドデータの該当指標を確認する	実ユーザー側の問題か、データ不足かを切り分けられる
4	PageSpeed Insightsの診断	LCPなら最大要素、INPなら長い処理、CLSならサイズ未指定の画像などの診断を開く	変更対象のファイルや処理を絞れる
5	修正後の同じ画面	同じURLを再測定し、公開後はSearch Consoleの該当行を確認する	ラボ結果と実ユーザー結果を混同せず追跡できる

今日1つだけ確認するなら、Search Consoleの「Core Web Vitals」を開いて、モバイルのPoorの行を選びます。該当行がなければ、Need improvementの行を選び、例のURLをPageSpeed Insightsに入力してください。