フロントエンドパフォーマンス関連用語カンニングペーパー
はじめに
チーム内でWebページのパフォーマンススコアを確認している際、「この指標ってどういう意味だっけ？」と思ったことはありませんか？私はあります。
あるいは、非エンジニアの方とコミュニケーションを取っている際、「この用語について簡単に説明できない！」と思ったことはありませんか？私はあります。
そういった状況に遭遇した際にさっと確認できるものがあると会話が円滑に進んでいい感じになる気がしたので、改めてまとめることにしました。
記事の構成
上記モチベーションから、本記事ではよく話題に挙がる（気がする）フロントエンドパフォーマンス用語について
- 概要：正確性を著しく損ねない範囲で簡略化したもの
- 参考：概要の出典・あとはここを読めばなんとかなると思うリンク
を記載しています。
ただし、当該用語についてコミュニケーションを重ねる中で疑問として浮かび上がりやすい内容についてはやや追加して記載しています。
以下用語
Core Web Vitals
Googleが提唱している、ユーザー体験(UX)を測定する指標群。
2024年1月現在は以下の3つの指標によって構成されています（各指標については後述）。
- LCP(Largest Contentful Paint)
- FID(First Input Delay)
- CLS(Commulative Layout Shift)
また、2024年3月以降はFIDに代わりINP(Interaction to Next Paint)がCore Web Vitalsとなることが予定されています。
参考: Understanding Core Web Vitals and Google search results
PSI(PageSpeed Insights)
Googleが提供している、Webパフォーマンス測定ツール。
指定したサイトのパフォーマンスに関するレポートと、改善方法を確認することができます。
PSIはLighthouseによる分析結果を基にしたラボデータと、CrUXのデータを基にしたフィールドデータを提供しています。
参考1: PageSpeed Insights
参考2: About PageSpeed Insights
Lighthouse
Googleが提供している、ウェブアプリケーションの品質を向上させるためのオープンソースの自動化ツール。
URLを渡すとそのページに対して一連の監査(audit)を実行した後、結果をレポートとして返却します。開発者はこの結果を頼りにWebパフォーマンスを改善していけば良いということになります。
2024年1月現在、PSIでは以下の5つの指標が分析対象として表示されています。
- FCP(First Contentful Paint)
- LCP(Largest Contentful Paint)
- TBT(Total Blocking Time)
- CLS(Commulative Layout Shift)
- SI(Speed Index)
"lighthouse"の日本語訳は"灯台"。なのでロゴも灯台です。
LighthouseはPSIやChromeの検証ツール等様々な方法で実行できますが、特に理由がない限りChrome拡張機能からの使用は推奨されていません（検証ツールの方を使う方が好ましい）。
参考: Lighthouse
CrUX(Chrome User Experience Report)
Googleが提供している、実際のユーザーパフォーマンスデータのデータセット。
2023年11月現在、PSIでは以下の6つの指標が分析対象として表示されています。
- LCP(Largest Contentful Paint)
- FID(First Input Delay)
- CLS(Comulative Layout Shift)
- FCP(First Contentful Paint)
- INP(Interaction to Next Paint)
- TTFB(Time To First Byte)
参考: Chrome UX Report
ラボデータ
あらかじめ定義された条件でシミュレート、収集されたデータを指す名称。
シミュレートされたデータであることから再現性を確保できる一方で、実際の結果と乖離する可能性があります。
labの他にsynthetic(合成)という表現が用いられることもあります。
PSIでは、Lighthouseによる分析結果がラボデータとして表示されています。
ページ上で「Diagnose Performance issues（パフォーマンスの問題を診断する）」として表示されているデータがこれにあたります。結果の下に記載されている内容がシミュレート条件です。
参考1: Lab data - How To Think About Speed Tools
参考2: Lab data - Why lab and field data can be different (and what to do about it)
フィールドデータ
実際のユーザーから匿名で収集したパフォーマンスデータを指す名称。
様々な端末やネットワーク条件を使用している実際のユーザーデータを取得できる一方で、Webパフォーマンスを改善してもフィールドデータに反映されるまでにある程度の時間を要します。
たとえば、PSIがフィールドデータとして使用しているCrUXは過去28日間にChromeユーザーから収集したデータを元に算出されているので、Webパフォーマンスの改善がフィールドデータに完全に反映されるのは更新から28日後になります。
RUM(Real User Monitoring)という表現が用いられることもあります。
PSIでは、CrUXのデータがフィールドデータとして表示されています。
ページ上で「Discover what your real users are experiencing（実際のユーザーの環境で評価する）」として表示されているデータがこれにあたります。
ラボデータが単一のデータであるのに対して、フィールドデータはデータ群です。つまり、フィールドデータには読み込みが非常に速い人のデータも、読み込みが非常に遅い人のデータも含まれています。
PSIでは、75パーセンタイル（スコアを降順にソートした場合の上位75%に位置する値。100人中75位のイメージ）のスコアをフィールドデータのスコアとして表示しています。
また、ラボデータとフィールドデータとで計測指標に違いがあるのは、測定条件が異なるためです。
たとえば、ユーザーの操作に対する応答性の指標であるFID(First Input Delay)はラボデータの指標には存在しませんし、ページが読み込まれる様子を動画でキャプチャし、フレーム間の視覚的な進行を計算することでスコアを算出するSI(Speed Index)はフィールドデータの指標には存在しません。
参考1: Field data - How To Think About Speed Tools
参考2: Field data - Why lab and field data can be different (and what to do about it)
LCP(Largest Contentful Paint)
ビューポート（表示領域）内に表示される、最も表示面積が大きい画像(orテキストブロック)のレンダリングが完了するまでの時間。
「画面内に表示される最も大きい要素のレンダリングが完了するまでの時間が短いほど、ユーザーが知覚する読み込み速度は速くなるよね」という考えに基づいた指標です。
参考: Largest Contentful Paint (LCP)
CLS(Comulative Layout Shift)
累積レイアウトシフト。
「ユーザーの操作を妨げ得る予期しないレイアウトシフトは少ない方が良いよね」という考えに基づいた指標です。
レイアウトシフトとは、リソースが非同期的に読み込まれたり、既に表示されているコンテンツの上側にDOM要素が動的に追加された場合等に発生するレイアウトの変化のことです。web.devの例がわかりやすいと思います。
ちなみに、CLSは2021年6月に定義が「ページに滞在している間に発生したすべてのレイアウトシフトの累積」から「レイアウトシフトの発生に応じて最長5秒のセッションウィンドウを開始、その中で発生したレイアウトシフトの累積をスコアとし、全セッションウィンドウの中で最大のスコアを持つもの」に変更されています。
セッションウィンドウについてもweb.devの図を見た方がわかりやすいので、是非そちらをご確認ください。
この変更を行った理由として、web.devでは「集計期間をセッションウィンドウに制限することで、滞在時間に関係なくCLSを一貫して測定できるようになるため（変更前の定義だと、SPAや無限スクロールといった滞在時間が長いページは時間経過とともにCLSが増加してしまう）」と述べられています。
参考: Cumulative Layout Shift (CLS)
FID(First Input Delay)
初回入力までの遅延時間。
「ユーザーが操作した時の入力遅延は少ない方が良いよね」という考えに基づいた指標です。そのうち初回入力の遅延を測定するので"First" Input Delay。なぜ初回の入力遅延のみを考慮するかについて、web.devでは3つの理由が述べられています（原文のニュアンスを上手く表現できなかったのでここでは省略します。興味があれば是非原文をご確認ください）。
注意点として、FIDはクリックやタップなど「ユーザーが最初にページを操作したタイミングからブラウザが実際に応答してイベントハンドラの処理を開始できるようになるまでの時間」の指標であり、「操作可能になるまでの時間」ではありません。そちらはTTI(Time To Interactive)という別の指標です。両者の違いについても、web.devの図がわかりやすいと思います。
また、FIDはロード中のページの応答性を測定する指標なので、クリック、タップ、キー入力などの離散的なアクションからの入力イベントのみに焦点を当てています。スクロールやズームのような連続的なアクションを持つ操作は異なるパフォーマンスの制約があることから、FIDを測定する際の対象とはされていません。
INP(Interaction to Next Paint)
ユーザーがページに滞在している間に行ったすべての操作の中で最長のレイテンシ（外れ値は無視）。
先述の通り、INPは2024年3月以降FIDに代わってCore Web Vitalsとなることが予定されています。変更の理由として、web.devでは以下の2つの理由が述べられています。
-
FIDが表す"初回"の入力遅延は確かに第一印象を決定する上で重要だけど、これは必ずしもページに滞在している間に発生するすべてのインタラクションを表すわけではないよね
-
FIDは初回の"入力遅延"、つまり「メインスレッドがビジー状態のためインタラクションの処理を開始するまでにブラウザが待機しなければならなかった時間」を表すけど、実行時間や描画遅延といった要素もあるよね
INPはページの全期間におけるすべてのインタラクションの中で最も遅かったものを表す指標であるため、FIDよりも包括的な指標となっています。
遅延部分を測定するだけでなく、インタラクションの開始からイベントハンドラを経て、ブラウザが次のフレームを描画できるようになるまでのすべての時間を測定するのでInteraction to Next Paint。
余談として、FIDの改善案については2021年の時点で既に述べられていたりするので（INPが発表され、有効性が検証され始めたのは2022年）、こちらも合わせて読んでみると面白いかもしれません。
参考: Interaction to Next Paint (INP)
FCP(First Contentful Paint)
ビューポートに何らかのコンテンツがレンダリングされるまでの時間。
「最初の要素がレンダリングされるまでの速度が速いほど、ユーザーが知覚する読み込み速度は速くなるよね」という考えに基づいています。
参考: First Contentful Paint (FCP)
TBT(Total Blocking Time)
合計ブロック時間。
「メインスレッドがブロックされる時間は少ない方が、ユーザーにとって使いやすいよね」という考えに基づいています。
ここでいう「ブロックされる」とは、「ブラウザが進行中のタスクを中断できないことで、ユーザーがページを操作した際、タスクの終了を待たなければいけない状態」のことを指します。
SI(Speed Index)
コンテンツがどれだけ速く視覚的に表示されるか。
同じ"レンダリング完了までに10秒かかるコンテンツ"であったとしても、
- 毎秒10%ずつレンダリングが進むコンテンツ
- 最初の1秒で90%のレンダリングが完了し、残りの10%に9秒かかるコンテンツ
の両者では、後者の方がユーザーが知覚する読み込み速度は速いよねという考えに基づいています。
参考: Speed Index
TTFB(Time To First Byte)
リソースのリクエストから、レスポンスの1バイト目が届き始めるまでの時間。具体的には、以下の時間の合計です。
- リダイレクト時間
- Service Worker の起動時間 ※該当する場合
- DNS ルックアップ
- 接続と TLS ネゴシエーション
- リクエスト（レスポンスの最初のバイトが到着する時点まで）
FCI(First CPU Idle) ※lighthouse6.0にて非推奨
ページが最小限のインタラクティブ性を持つようになるまでの時間。
以下のような場合、"ページが最小限のインタラクティブ性を持つ"と判断されます。
- 画面上のほとんどのUI要素がインタラクティブである場合
- ページが平均して、ほとんどのユーザー入力に対して合理的な時間で応答する場合
参考: First CPU Idle
FMP(First Meaningful Paint) ※lighthouse6.0にて非推奨
ユーザーがページの読み込みを開始してから、主要なコンテンツが表示されるまでの時間。
サードパーティ製のパフォーマンスツールなんかでは今でもたまに目にしますが、実は非推奨です。
TTI(Time to Interactive) ※lighthouse10.0にて廃止
ページが完全にインタラクティブになる（ページの読み込みが開始されてから、メインのサブリソースが読み込まれるまでの時間）までの時間。
廃止されたのが直近なので今でも割と目にしますが、実は廃止されています。
Discussion