パフォーマンスがいかに重要かは誰もが耳にしたことがあるでしょう。では、パフォーマンスやウェブサイトの「高速」化とは具体的にどういうことでしょうか。
実際には、パフォーマンスは相対的なものです。
- あるユーザーにとっては速いサイト（強力なデバイスの高速ネットワーク上）でも、別のユーザーにとっては遅いかもしれません（ローエンド デバイスの遅いネットワーク上）。
- 2 つのサイトがまったく同じ時間で読み込みを完了することもできますが、一方のサイトではコンテンツの読み込みが終わるまで待たずに、読み込みが速くなるように見えます。
- サイトの読み込みが速いように見えても、ユーザーの操作に対する応答が遅くなったり、まったく反応しなくなったりすることもあります。
パフォーマンスについて述べるときは、正確であることが重要です。指標とは、定量的に測定できる客観的な基準です。metricsただし、測定する指標が有用であることを確認することも重要です。
指標
これまで、ウェブ パフォーマンスは load イベントで測定されてきました。ただし、load はページのライフサイクルの中で明確に定義されたタイミングであっても、その瞬間は必ずしもユーザーが関心を持っているものに対応するとは限りません。
たとえば、サーバーは最小限のページですぐに「読み込み」というレスポンスを返し、load イベントが発生した後数秒間はコンテンツの取得やページ上での表示を遅らせることができます。このようなページの読み込み時間は技術的には速くなりますが、ページの読み込み時間はユーザー エクスペリエンスとは一致しません。
ここ数年、Chrome チームのメンバーは W3C Web Performance Working Group と協力して、ウェブページのパフォーマンスに関するユーザー エクスペリエンスをより正確に測定する一連の新しい API と指標の標準化に取り組んできました。
ユーザーに関連性の高い指標が表示されるように、いくつかの重要な質問に基づいて指標を構成します。
| 移行は進んでいますか？ | ナビゲーションは正常に開始されましたか？サーバーは応答しましたか？ |
| お役に立ちましたか？ | レンダリングされたコンテンツが十分で、ユーザーの操作に役立っているか。 |
| 使用できるか | ユーザーはページで操作できますか？それともビジー状態ですか？ |
| 楽しいですか？ | インタラクションはスムーズかつ自然で、遅延やジャンクがないかどうか。 |
指標の測定方法
パフォーマンス指標は通常、次の 2 つの方法のいずれかで測定されます。
- ラボ: ツールを使用して、一貫性のある管理された環境でページ読み込みをシミュレートする
- 使用現場: 実際にページを読み込んで操作する実際のユーザー
これらのオプションは、必ずしも他方より優れているとも悪くもなりません。実際、良好なパフォーマンスを確保するために、通常は両方を使用します。
実験室
新しい機能を開発する際は、ラボでパフォーマンスをテストすることが不可欠です。機能を本番環境にリリースする前に、実際のユーザーでパフォーマンス特性を測定することはできません。そのため、パフォーマンスの低下を防ぐには、リリース前にラボで機能をテストすることをおすすめします。
業務の現場
ラボでのテストは、パフォーマンスを考慮した妥当な手段ですが、必ずしもすべてのユーザーがサイトをどのように体験しているかを反映しているとは限りません。
サイトのパフォーマンスは、ユーザーのデバイスの機能やネットワーク状態によって大幅に変化することがあります。また、ユーザーがページを操作しているかどうか（またはその方法）によっても異なります。
また、ページ読み込みは必ずしも決定的ではありません。たとえば、パーソナライズされたコンテンツや広告を読み込むサイトでは、ユーザーごとにパフォーマンス特性が大きく異なる場合があります。臨床試験ではこのような違いは把握できません
ユーザーに対するサイトのパフォーマンスを正確に把握する唯一の方法は、ユーザーがサイトを読み、操作する際のパフォーマンスを実際に測定することです。このタイプの測定は一般に Real User Monitoring（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 は無関係な場合があります。
このようなケースに対応するため、ウェブ パフォーマンス ワーキング グループは、独自のカスタム指標の実装に役立つ低レベルの API も標準化しました。
- User Timing API
- Long Tasks API
- Element Timing API
- Navigation Timing API
- Resource Timing API
- サーバーのタイミング
これらの API を使用してサイト固有のパフォーマンス特性を測定する方法については、カスタム指標ガイドをご覧ください。