パフォーマンスの重要性は誰もが知っています。しかし、パフォーマンスやウェブサイトを「高速」にすることについて、具体的に何を意味するのでしょうか。
実際のところ、パフォーマンスは相対的なものであり、
- あるユーザー（高速ネットワークで高性能デバイスを使用している）にとっては高速なサイトでも、別のユーザー（低速ネットワークで低価格デバイスを使用している）にとっては遅いサイトになる可能性があります。
- 2 つのサイトの読み込みがまったく同じ時間で完了しても、一方が速く読み込まれるように見えることがあります（コンテンツを最後まで読み込んでから表示するのではなく、段階的に読み込む場合）。
- サイトの読み込みは速く見えるものの、ユーザー操作に対する応答が遅い（またはまったく応答しない）場合があります。
パフォーマンスについて話すときは、正確に表現し、指標でパフォーマンスを参照することが重要です。定量的に測定できる客観的な基準ですが、測定している指標が有用であることを確認することも重要です。
指標の定義
これまで、ウェブのパフォーマンスは load イベントで測定されていました。ただし、load はページのライフサイクルにおける明確なタイミングですが、そのタイミングがユーザーの関心事と必ずしも一致するとは限りません。
たとえば、サーバーはすぐに「読み込まれる」最小限のページで応答し、load イベントが発生してから数秒後にコンテンツの取得やページ上の表示を遅らせることができます。このようなページは技術的には読み込み時間が短いですが、ユーザーがページの読み込みをどのように感じるかは別の問題です。
過去数年間、Chrome チームのメンバーは W3C ウェブ パフォーマンス ワーキング グループと連携して、ユーザーがウェブページのパフォーマンスをどのように認識しているかをより正確に測定する一連の新しい API と指標の標準化に取り組んできました。
指標がユーザーに関連するものになるよう、Google では以下の重要な質問を念頭に置いています。
| この機能は利用できますか？ | 正常に処理が開始されたか？サーバーは応答したか？ |
| お役に立ちましたか？ | ユーザーが操作できる十分なコンテンツが表示されたか？ |
| 使用可能か | ユーザーはページを操作できるか？それとも読み込み中か？ |
| 快適か | ストレスなくスムーズに操作でき、遅延はないか？ |
指標の測定方法
パフォーマンス指標は通常、次の 2 つの方法のいずれかで測定されます。
- ラボ環境: ツールを使用して、一貫した制御された環境でページ読み込みをシミュレートする
- 現場: 実際のユーザーがページを読み込んで操作している場合
どちらのオプションも、必ずしも他方よりも優れているわけではありません。通常は、パフォーマンスを高めるために両方を使用することをおすすめします。
実験室
新機能を開発する際は、ラボでパフォーマンスをテストすることが不可欠です。本番環境で機能がリリースされる前に、実際のユーザーでパフォーマンス特性を測定することはできません。そのため、機能がリリースされる前にラボでテストすることが、パフォーマンスの低下を防ぐ最善の方法です。
業務の現場
一方、ラボでのテストはパフォーマンスの妥当な代用手段ですが、必ずしも実際のユーザーがサイトをどのように利用しているかを反映しているとは限りません。
サイトのパフォーマンスは、ユーザーのデバイスの機能やネットワークの状態によって大きく異なる場合があります。また、ユーザーがページを操作しているかどうか（またはどのように操作しているか）によっても異なります。
また、ページの読み込みは必ずしも確定的ではありません。たとえば、パーソナライズされたコンテンツや広告を読み込むサイトでは、ユーザーによってパフォーマンス特性が大きく異なる場合があります。ラボテストでは、こうした違いは検出できません。
サイトのユーザーに対するパフォーマンスを正確に把握するには、ユーザーがサイトを読み込んで操作する際にパフォーマンスを実際に測定するしかありません。このタイプの測定は、一般にリアルユーザー モニタリング（RUM）と呼ばれます。
指標タイプ
ユーザーがパフォーマンスをどのように認識しているかに関連する指標は他にもあります。
- 読み込み速度の感じ方: ページが読み込まれ、すべてのビジュアル要素が画面にレンダリングされるまでの時間。
- 読み込みの応答性: コンポーネントがユーザー操作に迅速に応答できるように、ページが必要な JavaScript コードを読み込み、実行するまでの時間
- 実行時の応答性: ページの読み込み後、ユーザーの操作に対してページがどれだけ迅速に応答できるか。
- 視覚的な安定性: ページ上の要素がユーザーが想定しない方法で移動し、操作の妨げになる可能性がありますか？
- スムーズさ: 遷移とアニメーションは一定のフレームレートでレンダリングされ、状態から状態へとスムーズに遷移しますか？
このようなさまざまな種類のパフォーマンス指標があることから、1 つの指標ではページのパフォーマンス特性をすべて把握できないことは明らかです。
測定すべき重要な指標
- First Contentful Paint（FCP）: ページの読み込みを開始してから、ページのコンテンツのいずれかの部分が画面上にレンダリングされるまでの時間を測定します。（ラボ、フィールド）
- Largest Contentful Paint（LCP）: ページの読み込みを開始してから、最大のテキスト ブロックまたは画像要素が画面上にレンダリングされるまでの時間を測定します。（ラボ、フィールド）
- Interaction to Next Paint（INP）: ページで行われたタップ、クリック、キーボード操作のレイテンシを測定し、インタラクションの数に基づいて、ページの全体的な応答性を示す単一の代表値として、ページの最も遅いインタラクション レイテンシ（または最も高いレイテンシに近い値）を選択します。（ラボ、フィールド）
- Total Blocking Time（TBT）: FCP から TTI の間でメインスレッドが入力に応答できないほど長くブロックされた合計時間を測定します。（ラボ）
- Cumulative Layout Shift（CLS）: ページの読み込みが開始されてから、ライフサイクル ステータスが非表示に変更されるまでに発生した、予期しないレイアウト シフトの合計スコアを測定します。（ラボ、フィールド）
- 最初のバイトまでの時間（TTFB）: ネットワークがユーザー リクエストに応答してリソースの最初のバイトを返すまでにかかる時間を測定します。（ラボ、フィールド）
不足している分野をカバーするために新しい指標が導入される場合もありますが、サイトに固有の指標が最適な場合もあります。
カスタム指標
前述のパフォーマンス指標は、ウェブ上のほとんどのサイトのパフォーマンス特性を一般に把握するのに適しています。また、サイトのパフォーマンスを競合他社と比較するための共通の指標セットとしても使用できます。
ただし、特定のサイトが何らかの点で独自であるため、パフォーマンス全体を把握するために追加の指標が必要になる場合があります。たとえば、LCP 指標はページのメイン コンテンツの読み込みが完了した時点を測定することを目的としていますが、最大の要素がページのメイン コンテンツの一部ではない場合、LCP は関連性が低くなる可能性があります。
このようなケースに対処するため、Web Performance Working Group は、独自のカスタム指標の実装に役立つ下位レベルの API も標準化しました。
- User Timing API
- Long Tasks API
- Long Animation Frames API
- Element Timing API
- Navigation Timing API
- Resource Timing API
- サーバーのタイミング
これらの API を使用してサイト固有のパフォーマンス特性を測定する方法については、カスタム指標のガイドをご覧ください。