ユーザー体験の目標

Google の Web Vitals を取得して読み、理解した内容を自分の言葉で書いたもの。本文の引用はしていない。

なぜあるのか

指標もツールも増えすぎて追いきれない、という問題への答えとして作られた。 Web の体験の質を表す指標を、統一された形で少数に絞るのが狙い。

可観測性の「SLO はできるだけ少なく」と同じ発想。

指標	測るもの	良好の基準
LCP (Largest Contentful Paint)	読み込みの体感	2.5秒以内
INP (Interaction to Next Paint)	操作への反応	200ミリ秒以下
CLS (Cumulative Layout Shift)	表示の安定性	0.1以下

INP は FID を置き換えた指標。 2023年に実験的から保留状態へ格上げされ、2024年に正式な Core Web Vital になった。 FID を使っている資料は古い。

75パーセンタイルで測り、モバイルとデスクトップを分ける。

平均ではなく75パーセンタイルなのは、可観測性で書いたのと同じ理由。 平均はテールを覆い隠す。

分けるのは、片方が良くてももう片方が悪ければ、その利用者にとっては悪いから。

	何を測るか	限界
フィールド	実際の利用者のデータ	出してからでないと取れない
ラボ	開発中、リリース前の測定	INP は測れない。実際の操作が必要なため

両方いる。ラボだけだと現実の分布が分からず、フィールドだけだと出す前に気づけない。

Core Web Vitals が悪いときに、原因を切り分けるために見る。

指標	用途
TTFB (Time to First Byte)	サーバー応答の遅れが LCP に効いているかを診断する
FCP (First Contentful Paint)	レンダリングをブロックしている資源が LCP に効いているかを見る
TBT (Total Blocking Time)	ラボ指標。INP の問題を検知する代理指標

TTFB が悪ければサーバー側、FCP と LCP の差が大きければフロント側、という切り分けの入口になる。

性能を測るが資源の側から見るのに対して、こちらは利用者の側から見る。

そして可観測性の枠組みで言えば、 Core Web Vitals はそのまま SLI になる。閾値を SLO として置ける。

スケールするリーダーにあった「レイテンシを偶発的な副作用ではなく第一級のゴールとして扱う」を、フロントエンドで具体化したものと読める。