Search ConsoleのCore Web Vitals: データ不足

「十分な使用状況データがありません」の意味

Search ConsoleのCore Web Vitalsレポートには、実際のChromeユーザーが体験したパフォーマンスが表示されます。適切な設定のChromeでユーザーがページを読み込むたびに、その訪問のLCP、INP、CLSがGoogleへ送信され、Chrome User Experience Report（略称 CrUX）と呼ばれる公開データセットに蓄積されます。Search Consoleはこのデータセットから数値を読み取って表示しています。多くの人が誤解しているような、Search Consoleがサイトを訪問して計測しているわけではありません。収集されているのは、あくまで実際のユーザーデータです。

ページへのそうした訪問が十分に集まらなければ、表示できるデータはありません。その場合に表示されるのが、モバイルやデスクトップ（あるいはその両方）に対する「このデバイス タイプについて、過去 90 日間の十分な使用状況データがありません」というメッセージです。

これを悪い兆候だと受け取る人もいますが、データがないからといってサイトの速さや遅さは何もわかりません。Googleが判断を下せるほど十分な訪問者を確認できていないだけです。

CrUXにサイトのデータがない理由

主な理由はトラフィックです。CrUXがページやオリジン（プロトコルとドメイン。例: https://www.example.com）のデータをレポートするのは、対象が「十分に人気（sufficiently popular）」である場合のみです。具体的にそれがどれほどの数字なのか、Googleは明言していません。算出方法（methodology）のページには、分布の信頼性を十分に確保できるだけの閾値だ、としか書かれていません。

そもそも、サイトの訪問者のうち、この閾値のカウント対象になるのはごく一部だけです。CrUXがデータを収集するのは、使用統計情報の送信を有効にし、閲覧履歴を同期していて、同期パスフレーズを設定していないChromeユーザーに限られます。対象となるのはデスクトップ版のChromeとAndroid版のChromeです。iPhoneのChromeは対象外です（Safariと同様、中身はWebKitだからです）。Safari自体やFirefox、Edge、Instagramアプリ内のブラウザなども一切カウントされません。iPhoneからのトラフィックが多いサイトでは、訪問者の大半が最初からデータセットに含まれないことになります。また、モバイルとデスクトップも別々に集計されます。そのため、デスクトップにはデータがあるのにモバイルにはない、あるいはその逆という事態が起こります。Chromeのトラフィックが少ないデバイスから先に、データなしになります。

さらに、ページ自体にも条件があります。リダイレクト後に200以外のステータスコードを返すものはすべてスキップされます。noindexメタタグや X-Robots-Tag: noindex ヘッダーが付いたページも除外されます。Search Consoleにはさらに独自のルールがあり、実際にインデックスされているURLしかレポートに表示されません。

Search Consoleにプロパティを追加したばかりの場合も、しばらくは何も表示されません。これについては、Google側の処理が進めば自然と解決します。

データのないページにはオリジンのスコアが適用されます

また、Search Consoleはページ単体でのレポートは行わず、類似したURLをグループ化します。グループ単体で十分なデータがない場合、Search Consoleはオリジン（同一のプロトコル、ホスト、ポートを持つすべてのURL）へとfallbackします。そのため、CrUXが一度も観測したことのないページであっても、サイト全体の数値を引き継ぐことで、レポート上に「良好」や「不良」として表示されることがあります。

実際には、トラフィックの大半はトップページやブログに集中するため、オリジンの数値を左右するのはそれらのページです。商品ページやチェックアウトの処理がどれほど遅くても、Search Consoleを見ているだけではそれに気づけません。私がサイト全体のCrUX数値を目標にしないのもこれが理由です。トラフィックによって重み付けされるため、アクセスが最も多いページだけで数値が決まってしまいます。そしてそのページが、本当に重視したいページであるとは限りません。

ここではLighthouseは役に立ちません

CrUXのデータが表示されるまでPageSpeed InsightsやLighthouseを実行しろ、というアドバイスをよく目にします。そう言われる理由はわかりますが、それでは必要な情報は得られません。Lighthouseの計測は、シミュレートされたスマートフォン環境で、通信速度を絞り、キャッシュを空にした状態でページを1回読み込むだけです。ページ自体の問題を見つけるには適していますが、実際の訪問者が体験していることについては何もわかりません。

たとえばINPの計測には、実際のデバイスで生身の人間がクリックやタップをする必要があります。Lighthouseは何もクリックしません。CLSについても、Lighthouseはページの読み込みが完了すると計測を終了します。そのため、遅れて表示された広告によってコンテンツが押し下げられたり、訪問者のスクロール時に表示がずれたりしても、レポートには一切反映されません。さらにLCPは、端末、通信環境、訪問者とCDNとの距離によって左右されます。1回のテスト実行で測定できるのは、そのうちのたった1つの組み合わせに過ぎません。

「待つ」という選択肢が通用するのは、トラフィックが増加傾向にある場合だけです。CrUXが集計対象とするのは過去28日間の訪問です（ちなみに、この遅延は世間で思われているよりずっと短いです。なぜ28日の遅延が誤解なのかを参照してください）。今月、条件を満たすChromeの訪問数が足りなかったのであれば、来月もおそらく足りないままでしょう。

RUMで自サイトの訪問者を計測する

別の選択肢は、自分で計測することです。Real user monitoring（RUM）なら、すべての訪問者のブラウザで小さなスクリプトを実行し、そのアクセスのCore Web Vitalsを計測して、Googleではなく手元に数値を送信します。CrUXと同じ種類のfield dataですが、クリアすべき閾値はなく、Chromeユーザーに限定されることもありません。

月間50アクセスのページでもデータが手に入ります。iPhoneからの訪問者も同様です。Safari 26.2（2025年12月）以降、SafariはLCPとINPを計測できるようになったため、CrUXでは除外されているデータもRUMには表示されます。また、数値悪化の原因となった具体的な要素、たとえばLCP対象の画像や、応答の遅いボタンなども特定できます。デプロイ後も、28日間の平均値を待つことなく、数分以内に変化を確認できます。

そのために私が開発したRUMツールがCore/Dashです。1つのscriptタグ、またはWordPressプラグインを導入するだけで、最初のページビューからデータが収集され始めます。Cookieを設定せず、個人データも収集しないため、同意バナーは不要です。小規模なサイトではこれが大きな意味を持ちます。同意バナーの配下にあるRUMスクリプトは、同意をクリックしたユーザーしか計測できないため、また訪問者のごく一部しか見えなくなってしまうからです。プランは年払いで月額16ドルから利用可能で、14日間のトライアルにクレジットカードは必要ありません。

CrUXがサイトのデータを収集し始めた後も、そのまま動かし続けてください。Search Consoleが表示するのはURLグループ単位に過ぎず、どのページやどの要素が原因でグループ全体が遅くなっているのかまでは決して教えてくれません。

現在CrUXにデータがあるか確認する

何かを変更する前に、そもそもCrUXにオリジンのデータが存在するか確認してください。corewebvitals.ioにあるCrUX Historyツールを使えば、任意のサイトのCrUX履歴を確認できます。そこでモバイルのデータが空であれば、Search Consoleでも同じく空になっています。

こちらも参照してください: Core/Dashのインストール、CrUXが除外する訪問者を把握するためのブラウザディメンション、モバイルとデスクトップを切り分けるデバイスタイプディメンション。

出典: Search Console ヘルプ: Core Web Vitals レポート、CrUX methodology、Safari 26.2がLCPとINPに対応。