Core Web Vitalsの3つの指標まとめ
3つの指標: LCP, FID, CLS
- LCP: Largest Contentful Paint (Largest Contentful Paint, 最大視覚コンテンツの表示時間)
- FID: First Input Delay (First Input Delay, 初回入力までの遅延時間)
- CLS: Cumulative Layout Shift (Cumulative Layout Shift, 累積レイアウト シフト数)
2種類のデータ: フィールドデータとラボデータ
- フィールドデータ: Chromeのユーザーから収集された実稼働環境のデータ
- ラボデータ: PageSpeed Insightsや、ChromeのLighthouseタブで計測されたデータ
SEOに影響があるのは「フィールドデータ」の方。
LCP, CLSはツールを使って手元で計測ができるが、FIDは実際のユーザーが必要となるため、手元環境では計測できない。つまりFIDは一旦公開してみないと値が取れない。
LCP: Largest Contentful Paint
ビューポート内で最もサイズが大きいコンテンツ要素の表示タイミング。
要は、ファーストビューで一番大きい要素(一般にはキービジュアル)が表示されるまでの時間。
参考: Largest Contentful Paint を最適化する
FID: First Input Delay
ユーザーが最初にページを操作したときから、その操作に応じてブラウザーが実際にイベントハンドラーの処理を開始するまでの時間。
要は、実際に要素をクリックしてからonclickイベントハンドラの関数がよばれるまでの時間。
どうやって計測しているのか
LCP, CLSはブラウザのパフォーマンス測定イベント機能で計測するのでJSの世界からは見えないが、FIDだけはpolyfillがあるので、計測内容を知ることができる。
polifyllによればFIDは以下の流れで計測している。
-
mousedown
,keydown
,touchstart
,pointerdown
のイベントにフック - 上記のイベントが初めて発火したら、
event.timeStamp
とperformance.now()
の値の差をとり、FIDとする
event.timeStamp
はOSがイベントを拾ったときのタイムスタンプで、performance.now()
はJSに処理が渡ったときのタイムスタンプなので、その差をとれば初回入力が実行されるまでの遅延時間が取れるということのようだ。
参考: web-vitals
CLS: Cumulative Layout Shift
ページの表示中、ユーザー操作を伴わないレイアウトシフトが発生するごとにレイアウトシフトスコアを計算し、最大のレイアウトシフトが発生したときのスコア。
要は、ページ表示後に、どれくらいの大きさの要素が、どれだけガタついたかの指標。値が少ないほどガタついていないことを示す。
フィールドデータはどうやって集められるのか
Chromeユーザーで、「Chromeの機能と動作の改善に協力する」と「検索とブラウジングを改善する」をOnにしていて、パスワード同期を有効にしてない人の履歴データから集められる。
集められたデータはChrome User Experience Reportという名前で公開されている。BigQueryで検索もできる。
参考: Methodology - Chrome User Experience Report
緑/オレンジ/黄色はどうやって決まるのか
- 緑=良好, オレンジ=改善が必要, 黄色=低速
- LCP, FID, CLSごとに、計測値がどこに分類されるかをGoogleが決めたしきい値がある
- フィールドデータの75%がどこに分類されるかで決まる
ラボデータに出てくる指標
PageSpeed InsightsやLighthouseでは、LCP, CLSに加えて以下の指標も表示される。
これらの数値を改善するとLCP, FID, CLSも改善されることが多いが、検索順位の判定には使われていない。
これらの指標が検索順位の判定に利用されない理由
- FCP: 最初に表示される要素が、ローディング表示などユーザーにとってあまり意味がない場合がある
- SI: 複雑で説明が難しく、間違っている場合も多かった
- TTI: フィールドデータの計測が難しい
- TBT: ユーザーの操作が影響を与え、レポートに多数のばらつきが出てしまう可能性がある
Discussion