このCore Web Vitalsレポートで何がわかるのか
ドメインまたはURLを1つ入力し、モバイルかデスクトップを選択すると、GoogleのCrUX History APIから25週分のfield dataが取得されます。LCP、INP、CLSに加え、TTFBとFCPの週次グラフが表示されます。LCPはこのどちらよりも速くなることはありません。十分なChromeトラフィックがあれば、競合サイトも含め、どのサイトでも利用できます。
読み込みグラフの下では、LCPが4つの要素に分解されています。さらに下には、CLSとINPの推移、続いてデバイス別とナビゲーションタイプ別のデータが並びます。後ろの2項目と、LCPにおける画像・テキストの比率は、どちらのトグルを選択していても全デバイス合算の値です。
週次CrUXグラフの見方
バー1本が1週間を表します。バーにホバーすると、その週のp75と、「良好」「改善が必要」「不良」それぞれのページ読み込みの割合が表示されます。
p75はGoogleが評価基準にする数値です。4回中3回のページ読み込みが、少なくともこの水準と同等以上に良好だったことを意味します。
- LCPは2.5秒以下なら「良好」、4秒を超えると「不良」です
- INPは200 ms以下なら「良好」、500 msを超えると「不良」です
- CLSは0.1以下なら「良好」、0.25を超えると「不良」です
3つの指標すべてがp75で「良好」であれば、Core Web Vitalsに合格します。
各指標カードのバッジは、全週を通して引いた直線の向きを表しています。上部のサマリーでは、期間の前半と後半でp75の平均値を比較しています。その隣にあるUX happiness scoreは、私独自の数値です。直近の週における「良好」なページ読み込みの割合を、LCP、INP、CLS、FCP、TTFBで平均したものです。Googleはこの数値を使っていません。そもそも公式のCore Web Vitalsスコアは存在しません。
CrUXデータはどこから来ているのか
AndroidおよびデスクトップのChromeから収集されています。閲覧履歴を同期し、Googleに使用統計の共有を許可しているユーザーが対象です。iPhone版のChromeは含まれません。Edgeも対象外です。
各週のデータポイントは、その直前28日間を対象としているため、集計期間が重複します。火曜日にリリースした修正が数値に完全に反映されるまでには、約4つのデータポイントが必要です。
Googleは毎週月曜日に、直前の土曜日までのデータを含む新しいデータポイントを追加します。そのため、月曜日の時点での最新データは2日前のものです。28日間というのは集計ウィンドウの幅にすぎません。「28日間の遅延」が誤解であるのはそのためです。
これは、訪問者が自身のデバイスで実際に体験した結果です。PageSpeed Insightsは、低速なスマートフォンとネットワーク環境をシミュレートし、GoogleのサーバーからLighthouseを1回実行するだけです。Lighthouseは何もクリックしないため、INPは一切計測されません。Lighthouseで98点が出ていても、ここのINPが赤い線を示すことは十分にあり得ます。どちらも事実です。
Search ConsoleのCore Web Vitalsレポートとの違い
Search Consoleも同じCrUXデータを読み取りますが、対象は自身が所有するサイトのみです。挙動が似ているURLをグループ化し、直近28日間で最も悪かった指標に基づいて各グループにラベルを付けます。
Search Consoleでわかるのは、どのページグループが不合格になっているかまでです。ここの週次バーを見れば、問題が始まった週を特定でき、そこから原因となったリリースを突き止めることができます。
指標が悪化したときに確認すべきこと
まずはモバイルのまま確認してください（レポートは初期状態でモバイルが開きます）。大抵の場合、モバイルのほうが悪いためです。次に、グラフの線の形状を確認します。
デプロイによる影響は、約4週間にわたって数値が上昇し、その後に横ばいになる形で現れます。新テーマの適用、Tag Managerでのタグ追加、ヒーロー画像へのloading="lazy"の付与などがその例です。数値の上昇が始まった週に、何がリリースされたかを調べてください。
何ヶ月も線がじわじわと上昇し続けているなら、通常はサードパーティスクリプトの蓄積が原因です。
LCPについては、内訳グラフを開いてどの部分が増加したかを確認してください。この内訳は、LCP要素が画像であるページ読み込みのみを集計しています。TTFBの増加はサーバーやキャッシュの問題を示します。読み込み遅延が長い場合は、ブラウザがLCP画像を見つけるのが遅いことを意味します。読み込み時間が長い場合は、画像が重いか、ホスト先への接続が遅いことが原因です。レンダリング遅延の増大は、CSSやJavaScriptが表示を遅らせていることが原因です。
CrUXの履歴データではわからないこと
小規模なサイトではデータが表示されません。Googleは多数のChrome訪問数を必要としていますが、具体的な必要数は非公開です。noindexが指定されたページや、ステータスコードが200以外のページも対象外です。入力したURLでデータが出ない場合は、ドメイン全体で試してみてください。このレポートは、wwwの有無を自動で試します。
データがある場合でも、得られるのはドメイン全体またはアクセスの多い1つのURLに対する、指標ごと・週ごとのp75が1つだけです。どのテンプレートが遅いのか、どの要素が動いたのか、どのスクリプトがクリックをブロックしているのかは、CrUXからはわかりません。
それを把握するには、自身のサイトでリアルユーザーモニタリング（RUM）を行う必要があります。そのために開発したのがCoreDashです。サイト上のページ読み込みに、LCP要素や処理の遅いインタラクションの情報が紐づくため、修正の効果を数時間以内に確認できます。
