ユーザー中心のパフォーマンス指標

Philip Walton （Philip Walton）

パフォーマンスの重要性は誰もが耳にしたことがあるでしょう。では、パフォーマンス、つまりウェブサイトの「高速化」とは、具体的にどういう意味でしょうか。

実際、パフォーマンスは相対的なものです。

• あるユーザーにとっては速いサイト（強力なデバイスの高速ネットワーク上）でも、別のユーザーにとっては遅いかもしれません（ローエンド デバイスの遅いネットワーク上）。
• 2 つのサイトの読み込みがまったく同じ時間で完了する場合でも、一方のサイトの読み込みが速いように見える場合があります（コンテンツの読み込みが終わるまで待つのではなく、徐々に読み込む場合）。
• サイトの読み込みは速いように見えても、ユーザーの操作に対する反応が遅い（またはまったく反応しない）場合があります。

したがって、パフォーマンスについて述べるときは、正確であること、定量的に測定できる客観的な基準の観点からパフォーマンスを指すことが重要です。これらの基準は指標と呼ばれます。metrics

ただし、指標が客観的な基準に基づいて定量的に測定できるからといって、必ずしもそれらの測定値が有用であるとは限りません。

指標の定義

これまで、ウェブのパフォーマンスは load イベントで測定されていました。ただし、load はページのライフサイクルの中で明確に定義されたタイミングであっても、その瞬間は必ずしもユーザーが関心を持っているものに対応するとは限りません。

たとえば、サーバーは最小限のページですぐに「読み込み」というレスポンスを返し、その後、load イベントの発生から数秒までコンテンツの取得とページへの表示を遅らせます。このようなページの読み込み時間は技術的には速くても、ユーザーが実際にページの読み込みを体験するまでの時間とは一致しません。

過去数年間、Chrome チームのメンバーは、W3C Web Performance Working Group と協力して、ウェブページのパフォーマンスに関するユーザー エクスペリエンスをより正確に測定する、一連の新しい API と指標の標準化に取り組んできました。

ユーザーに関連性の高い指標が表示されるように、いくつかの重要な質問に基づいて指標を構成します。

指標の測定方法

パフォーマンス指標は通常、次の 2 つの方法のいずれかで測定されます。

• ラボ: ツールを使用して、一貫性のある管理された環境でページ読み込みをシミュレートする
• 使用現場: 実際にページを読み込んで操作する実際のユーザー

これらのオプションは必ずしも他方よりも優れているとも悪くもないため、通常は、優れたパフォーマンスを確保するために両方を使用することが推奨されます。

実験室

新しい機能を開発する際は、ラボでパフォーマンスをテストすることが不可欠です。機能を本番環境にリリースする前に、実際のユーザーでパフォーマンス特性を測定することはできません。そのため、パフォーマンスの低下を防ぐには、リリース前にラボで機能をテストすることをおすすめします。

業務の現場

ラボでのテストはパフォーマンスを考慮したもので、必ずしもすべてのユーザーが実際にサイトをどのように体験しているかを反映しているわけではありません。

サイトのパフォーマンスは、ユーザーのデバイスの機能やネットワーク状態によって大幅に変化することがあります。また、ユーザーがページを操作しているかどうか（どのように操作しているか）によっても異なります。

さらに、ページ読み込みが確定的でない場合もあります。たとえば、パーソナライズされたコンテンツや広告を読み込むサイトでは、ユーザーごとにパフォーマンス特性が大きく異なる場合があります。臨床試験ではこのような違いは把握できません

ユーザーに対するサイトのパフォーマンスを正確に把握する唯一の方法は、ユーザーがサイトを読み込んで操作する中でのパフォーマンスを実際に測定することです。このタイプの測定は、一般にリアルユーザー モニタリング（RUM）と呼ばれます。

指標タイプ

ユーザーがパフォーマンスを感じる方法に関連する指標には、他にもいくつかの種類があります。

• 認識された読み込み速度: ページがすべての視覚要素を読み込んで画面にレンダリングするまでの時間。
• 読み込みの応答性: コンポーネントがユーザーの操作にすばやく応答するために必要な JavaScript コードの読み込みと実行にかかる時間
• ランタイムの応答性: ページ読み込み後、ページがユーザー操作にどれだけ速く応答するか。
• 視覚的な安定性: ページ上の要素が、ユーザーが予期しない方法で移動していないか、操作の妨げになる可能性があるか。
• スムーズさ: 遷移やアニメーションは一貫したフレームレートでレンダリングされ、ある状態から次の状態へスムーズに流れるか。

上述のようなパフォーマンス指標をすべて考慮すると、1 つの指標だけではページのパフォーマンス特性をすべて把握できるとは言えません。

重要な測定指標

• First Contentful Paint（FCP）: ページの読み込みを開始してから、ページのコンテンツの一部が画面にレンダリングされるまでの時間を測定します。（ラボ、フィールド）
• Largest Contentful Paint（LCP）: ページの読み込みを開始してから、最大のテキスト ブロックまたは画像要素が画面にレンダリングされるまでの時間を測定します。（ラボ、フィールド）
• First Input Delay（FID）: ユーザーが初めてサイトを操作（リンクのクリック、ボタンのタップ、カスタムの JavaScript コントロールの使用など）してから、ブラウザが実際にその操作に応答できるまでの時間を測定します。（フィールド）
• 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 を使用してサイト固有のパフォーマンス特性を測定する方法については、カスタム指標に関するガイドをご覧ください。