Core Web Vitals — 数字を上げるのではなく、何が遅いかを特定する

What — 3つが何を測っているのか

Core Web Vitals は3つの指標です。名前を覚えるより、何の代理指標なのかを押さえるほうが役に立ちます。

Largest Contentful Paint

フィールドデータ

実際の利用者の環境で集めた値。端末も回線もばらばらで、これが評価の対象になる。

ラボデータ

決まった条件で測った値。再現性はあるが、利用者の実際とは違う。

TTFB

Time To First Byte。サーバーが最初の1バイトを返すまで。LCP の内訳の先頭。

パーセンタイル

評価は 75 パーセンタイルで見る。平均ではなく「4人に3人はこれより速い」という値。

LCP は合計値。分解しないと直せない

冒頭の事故はここでした。LCP は4つの区間の合計です。

Why — なぜこの3つなのか

速さを表す数字は昔からありました。読み込み完了、最初の描画、リソースの総量。どれも**「利用者が何に困っているか」とずれていました**。

読み込み完了は、画面がとっくに使える状態でも、末尾の解析タグを待って遅く出ます。最初の描画は、背景色が塗られただけで「描画された」ことになります。

Core Web Vitals は逆から作られています。利用者が困る場面を3つに分類して、それぞれに数字を当てた。

だから3つなのであって、技術的な工程に対応しているわけではありません。症状の分類です。

75 パーセンタイルで見る理由

評価は平均ではなく 75 パーセンタイルです。「4人に3人はこれより速い」という値。

平均だと、速い多数が遅い少数を隠します。ハイエンドの端末で 1 秒、古い端末で 12 秒でも、平均は良い数字になります。困っている人がいることが見えません。

かといって最悪値だと、極端な1件に振り回されます。75 パーセンタイルは、無視できない多数派の中で、いちばん困っている層を見る位置です。

ラボとフィールドが食い違う

手元の開発者ツールで測ると良い数字が出るのに、実際の利用者の値は悪い。よくあります。

理由は単純で、測っている条件が違うからです。手元は高速な回線、高性能な端末、キャッシュ済み、拡張機能なし。利用者はその逆が混ざります。

ラボの数字は変更の前後を比べるのに向きます。フィールドの数字はいま困っている人がいるかを知るのに向きます。用途が違うので、片方でもう片方を代用できません。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。