パフォーマンスの重要性については誰もが耳にしてきました。しかし、パフォーマンスやウェブサイトの「高速」化という言葉には、具体的にどういう意味があるのでしょうか？
実際のところ、パフォーマンスは相対的です。
- あるユーザー（高性能なデバイスを搭載した高速ネットワークを使用）では速度が速く、別のユーザー（低速ネットワークではローエンドのデバイス）では速度が遅いサイトもあります。
- 2 つのサイトの読み込み時間がまったく同じ時間で終了しても、1 つのサイトの読み込みが速く見える場合があります（最後まで待たずに順を追ってコンテンツを読み込んだ場合）。
- サイトの読み込みが早いように見えるにもかかわらず、ユーザー操作への反応が遅い（またはまったく反応しない）場合があります。
パフォーマンスについて語るときは、正確に表現し、 指標の観点から見たパフォーマンス。定量的に測定できる客観的な基準 重要ですが、測定する指標が 便利です。
指標の定義
これまでウェブ パフォーマンスは load イベントで測定されていました。ただし、load はページのライフサイクルにおいて明確に定義されたタイミングですが、そのタイミングは必ずしもユーザーが関心を持っているものに対応しているわけではありません。
たとえば、サーバーは「読み込まれる」最小限のページで応答できます。ただし、コンテンツの取得やページ上のコンテンツの表示を、load イベント発生の数秒後まで延期します。このようなページの読み込みは技術的には高速ですが、その時間はユーザーがページを読み込む方法とは関係ありません。
過去数年間、Chrome チームのメンバーは W3C Web Performance Working Group と協力して、ユーザーがウェブページのパフォーマンスをどのように評価しているかをより正確に測定する一連の新しい API と指標の標準化に取り組んできました。
ユーザーにとって関連性が高い指標を確保するために、次のような重要なポイントを軸に据えています。
| 今、発生しているのか？ | ナビゲーションは正常に開始しましたか？サーバーは応答しましたか？ |
| お役に立ちましたか？ | ユーザーが操作できるほどの十分なコンテンツがレンダリングされているか？ |
| 使用可能か？ | ユーザーはページを操作できますか？それとも混雑していますか？ |
| 楽しいですか？ | やり取りはスムーズかつ自然で、ラグが発生していないか？ |
指標の測定方法
パフォーマンス指標は通常、次の 2 つの方法のいずれかで測定されます。
- ラボの内容: 制御された一貫性のある環境で、ツールを使用してページ読み込みをシミュレートする
- フィールド: 実際のユーザーがページを読み込んで操作した場合
これらのオプションが他方よりも必ずしも優れているとは限りません。実際には、優れたパフォーマンスを確保するために、一般的に両方を使用する必要があります。
実験室
新機能を開発するときは、ラボでパフォーマンスをテストすることが不可欠です。機能を本番環境にリリースする前に、実際のユーザーでパフォーマンス特性を測定することは不可能です。パフォーマンスの低下を防ぐには、機能のリリース前にラボでテストするのが最善の方法です。
業務の現場
一方、このラボでのテストはパフォーマンスの目安として妥当ですが、必ずしも実際のユーザーのサイト エクスペリエンスを反映しているわけではありません。
サイトのパフォーマンスは、ユーザーのデバイスの機能やネットワークの状態によって大きく変動します。また、ユーザーがページを操作しているかどうか（またはどのように操作しているか）によっても異なる場合があります。
また、ページの読み込みは必ずしも決定的ではありません。たとえば、パーソナライズされたコンテンツや広告を読み込むサイトでは、ユーザーごとにパフォーマンス特性が大きく異なる場合があります。ラボテストではこのような違いは捉えられません。
ユーザーに対するサイトのパフォーマンスを正確に把握する唯一の方法は、ユーザーがサイトを読み込んで操作した際のパフォーマンスを実際に測定することです。この種の測定は一般的に Real User Monitoring（RUM）と呼ばれます。
指標タイプ
ユーザーがパフォーマンスをどのように認識しているかに関連する指標は他にもいくつかあります。
- 認識される読み込み速度: ページですべての視覚要素を読み込んで画面にレンダリングする速度。
- 読み込みの応答性: コンポーネントがユーザー操作にすばやく反応するために必要な JavaScript コードを、ページの読み込みと実行にどれだけ早く実行できるか。
- 実行時の応答性: ページの読み込み後に、ページがユーザー操作にどれだけ早く反応するかを示します。
- 視覚的な安定性: ユーザーが予期しない方法でページの要素を変えたり、操作の妨げになったりしていないか。
- スムーズさ:遷移やアニメーションは一貫したフレームレートでレンダリングされ、ある状態から次の状態に滑らかに流れますか？
これらすべての種類のパフォーマンス指標を考慮すると、1 つの指標でページのすべてのパフォーマンス特性を把握することは十分にできないことは明らかです。
測定すべき重要な指標
- First Contentful Paint（FCP）: ページの読み込みを開始してから、ページのコンテンツの一部が画面に表示されるまでの時間を測定します。(lab, field)
- Largest Contentful Paint（LCP）: ページの読み込みを開始してから、最大のテキスト ブロックまたは画像要素が画面に表示されるまでの時間を測定します。(lab, field)
- Interaction to Next Paint（INP）: ページで行われるすべてのタップ、クリック、キーボード操作のレイテンシを測定し、操作の数に基づいて、ページの全体的な応答性を表す単一の代表値として最も低いインタラクション レイテンシ（または最高のインタラクション レイテンシに近いもの）を選択します。(lab, field)
- 合計ブロック時間（TBT）: FCP から TTI までの間に、メインスレッドが入力の応答を妨げるのに十分な時間ブロックされていた合計時間を測定します。（ラボ）
- Cumulative Layout Shift（CLS）: ページの読み込みを開始してからライフサイクルの状態が非表示になるまでの間に発生した予期しないレイアウト シフトの累積スコアを測定します。(lab, field)
- Time to First Byte（TTFB）: ネットワークがリソースの最初のバイトでユーザー リクエストに応答するまでにかかる時間を測定します。(lab, field)
場合によっては、欠落している領域をカバーするために新しい指標が導入されることもありますが、最適な指標がサイトに合わせて調整されたものになることもあります。
カスタム指標
これまでに取り上げたパフォーマンス指標は、ウェブ上のほとんどのサイトのパフォーマンス特性を大まかに把握するのに役立ちます。また、サイトのパフォーマンスを競合他社と比較するための共通の指標を持つことも有効です。
ただし、特定のサイトがなんらかの形でユニークであり、パフォーマンスの全体像を把握するために追加の指標が必要になる場合もあります。たとえば、LCP の指標は、ページのメイン コンテンツの読み込みが完了したタイミングを測定することを目的としていますが、最も大きな要素がページのメイン コンテンツの一部ではないため、LCP との関連性がない場合もあります。
このようなケースに対処するために、Web Performance Working Group は低レベル API も標準化しています。この API は独自のカスタム指標の実装に便利です。
これらの API を使用してサイト固有のパフォーマンス特性を測定する方法については、カスタム指標に関するガイドをご覧ください。