Core Web Vitalsレポート

フィールドデータとラボデータは別物

Lighthouseのようなラボテストは、通信を制限した中程度のスマホを模擬して、ページを一度だけ読み込みます。何度でも繰り返せて詳細も豊富ですが、そこに描かれる訪問者は架空の存在です。

フィールドデータは実際の訪問から得られます。利用統計の共有に同意したChromeユーザーが匿名の計測値を送り、Googleがそれを直近28日分、CrUXと呼ばれるChrome UX Reportに集計します。Google検索がページエクスペリエンスを評価するときに読むのがこのデータです。実際の利用者が古いスマホを使っていれば、ラボで95点のページでもフィールドでは不合格になりえます。逆に、ほとんどの訪問者がキャッシュの残った状態で来るなら、ラボのスコアが平凡でもフィールドでは合格することがあります。

このレポートはまずフィールドデータを求めます。評価に使われるのはそちらだからです。

表にある五つの計測値

最初の三つがCore Web Vitalsです。FCPとTTFBは、LCPが遅い理由を説明する助けになるので参考として載せています。評価には数えません。

レポートの作り方

リダイレクトをたどって最終的なアドレスに着いたら、CrUXにスマホ用とPC用の2回問い合わせます。どちらの問い合わせもまずそのページ自体を試し、ページ単体の訪問が少なすぎる場合はオリジン全体に切り替えます。各表の上の行に、どちらを読んでいるかを示します。

指標に表示される値は75パーセンタイルです。つまり訪問の4回に3回は少なくともその速さだった、ということです。横の色付きバーは、良好、改善が必要、不良の各範囲に入った訪問の割合を示します。

評価では、各Core Web Vitalが良好なら2点、改善が必要なら1点、不良なら0点です。6点満点中6点でA、5点でB、4点でC、3点でD、2点でE、それ未満はFです。不良の指標が一つでもあれば、ほかの二つがどれほど良くても評価はDまでです。見出しの評価は、スマホのデータがあればスマホの評価です。

Chromeにデータがないとき

CrUXが扱うのは、公開されていて十分に訪問されているページだけです。それ以外では、このレポートは模擬スマホでPageSpeed Insightsのテストを一度実行し、そうしたことをはっきり伝えます。その場合は、Lighthouseのパフォーマンススコア（90以上でA、75以上でB、50以上でC、35以上でD、20以上でE）、LCPとCLSのラボ値、そしてINPの代わりにTotal Blocking Timeが表示されます。入力への反応速度は、実際に人が入力しなければ計測できないからです。推定短縮時間が大きい監査項目を最大五つ、下に一覧にします。

各数値を動かすもの

LCP

Chrome DevToolsのPerformanceパネルでLCP要素を探します。たいていはメイン画像です。表示サイズのままWebPかAVIFで配信し、fetchpriority="high"を加え、決してloading="lazy"を付けないでください。TTFBがすでに0.8秒を超えているなら、ページキャッシュやCDNでまずサーバーを直します。ページ容量の内訳で一番重いファイルがわかります。

INP

長いJavaScriptのタスクは、ページが入力に反応するのを妨げます。もう使っていないタグやプラグインを外し、外部スクリプトはdeferで読み込み、50 msを超えて走る処理は分割してください。

CLS

すべての画像と動画にwidthとheight属性を付け、広告や埋め込みの場所をmin-heightかaspect-ratioで確保し、すでに見えているコンテンツの上にバナーを差し込まないでください。

フィールドデータは28日間の移動期間です。修正後、数値は毎日少しずつ良くなり、効果がすべて表れるまで4週間かかります。Safariからの訪問と、iPhone上のあらゆるブラウザからの訪問はCrUXに含まれないので、このレポートが示すのはChromeの利用者だけです。