Web パフォーマンス指標
パフォーマンスの重要性はすでにわかっていますが、パフォーマンスについて話すとき、Web ページを高速化するとはどういう意味でしょうか?
実際、パフォーマンスは相対的なものです。
- サイトは、あるユーザーにとっては速くても (強力なデバイスを備えた高速ネットワーク上では)、別のユーザーにとっては遅くなる場合もあります (ローエンド デバイスを備えた低速ネットワーク上では)。
- 2 つのサイトはまったく同じ時間で読み込まれる可能性がありますが、(すべてを表示するために最後まで待つのではなく、コンテンツを段階的に読み込む場合は) 1 つのサイトの読み込みが速くなったように見えます。
- Web サイトの読み込みは速くても、その後のユーザー操作では遅くなる場合があります。
したがって、パフォーマンスについて議論する場合、正確で定量化可能な指標が非常に重要です。
ただし、指標は客観的な基準に基づいており、定量的に測定できるため、指標が良いか悪いかだけで必ずしも有用であるとは限りません。
Web 開発者にとって、Web ページのパフォーマンスをどのように測定するかは常に難しい問題です。
当初、ドキュメントの読み込みの進行状況を測定するために TTFB (Time to First Byte)、DomContentLoaded、および Load を使用しましたが、これらはユーザーの視覚エクスペリエンスを直接反映することはできません。
ユーザーの視覚エクスペリエンスを測定するために、Web 標準でいくつかのパフォーマンス指標が定義されており、これらのパフォーマンス指標は、First ペイント(最初の描画) やファースト コンテンツフル ペイント(最初のコンテンツ描画) などの主要なブラウザーによって標準化されています。Web Incubator Community Group (WICG) によって提案されているいくつかのパフォーマンス指標もあります。たとえば、Largest Contentful Paint (最大コンテンツ描画)、Time to Interactive (持続可能なインタラクティブ時間)、First input late (最初の入力遅延)、First CPU idle (最初の CPU はアイドル状態です)。このほか、 Googleが提案するFirst Meaningful Paint (最初の意味のある描画)やSpeed Index (速度指数)、 Baiduが提案するFirst Screen Paint (最初の画面表示時間)などがあります。
これらの指標は無関係ではありませんが、ユーザー中心の目標に向かって常に進化しています。推奨されなくなったものもあれば、さまざまなテスト ツールで実装されているものもあり、一般的な標準として使用できるものもあります。主要なブラウザーが提供する API があります。実稼働環境での測定に使用されます。
主に次の 3 つのレベルで紹介されます。
- RAIL パフォーマンス モデル- ユーザー エクスペリエンスの観点から与えられたエクスペリエンス基準 (応答、アニメーション、アイドル、ロード)
- ユーザー エクスペリエンスに基づくコア インジケーター- RAIL に基づく特定のインジケーター スキームに基づく
- 新世代のパフォーマンス指標: Web Vitals - LCP (最大コンテンツフル ペイント)、FID (最初の入力遅延)、および CLS (累積レイアウト シフト) に焦点を当てた、上記の指標スキームの簡素化。
RAILパフォーマンスモデル
RAILは、 Response、Animation、IdleおよびLoadの頭字語で、ブラウザーのユーザー エクスペリエンスとパフォーマンスを向上させるために 2015 年に Google Chrome チームによって提案されたパフォーマンス モデルです。
RAIL モデルの哲学は「ユーザー中心であり、最終的な目標は、Web サイトを特定のデバイスで高速に実行することではなく、ユーザーを満足させることです」です。
RAIL という名前の由来は、次の 4 つの英語の単語の最初の文字です。
- 応答: ユーザーにできるだけ早く応答する必要があり、ユーザー入力には 100 ミリ秒以内に応答する必要があります。
- いわゆる応答は結果を返すことではなく、ユーザーが認識できる状態のインタラクションを与えることです。
- アニメーション: アニメーションを表示するときは、アニメーション効果の一貫性を維持し、途切れを避けるために、各フレームを 16 ミリ秒でレンダリングする必要があります。
- 1秒あたり約60フレーム
- アイドル: JavaScript メイン スレッドを使用する場合、タスクは実行時間が 50 ミリ秒未満のフラグメントに分割して、スレッドをユーザー操作のために解放できるようにする必要があります。
- 50ms を超える実行タスクは、JS では **「長いタスク」** と呼ばれます。長いタスクは実行中にユーザーの操作に応答できないため、避けるようにしてください。
- ロード (ロード): Web サイトは 1 秒以内にロードされ、ユーザーの操作が可能になる必要があります。
ネットワークの状態とハードウェアに応じて、パフォーマンスの遅延に対するユーザーの認識は異なります。
1s は、より優れたパフォーマンスと良好なネットワーク環境を備えた PC に基づいた指標であり、ユーザーはそれに慣れています。
また、3G 接続が遅いモバイル デバイスではネットワークのロードに時間がかかるため、モバイル ユーザーは一般に忍耐強く、モバイルで5 秒でロードすることがより現実的な目標となります。
これら 4 つの単語は、さまざまな方法で Web サイト全体のパフォーマンスに影響を与える、Web サイトまたはアプリケーションのライフサイクルに関連する 4 つの側面を表します。
遅延に対するユーザーの認識
今後のパフォーマンス最適化の中心はユーザーであると考えており、まず遅延に対するユーザーの反応を理解する必要があります。
次の表に示すように、ユーザーが遅延を認識する時間。
| 遅れ | ユーザーの認識 |
|---|---|
| 0～16ms | 人間の目はアニメーションを 1 秒あたり 60 フレーム、つまり 1 フレームあたり 16 ミリ秒で認識できます。ブラウザが画面にフレームを描画する時間を除き、Web サイト アプリケーションがフレームを生成するのに約 10 ミリ秒かかります。 |
| 0～100ms | この時間枠内でユーザーのアクションに応答すると、スムーズなエクスペリエンスが得られます。 |
| 100～1000ms | 顕著な遅延 |
| > 1秒 | ユーザーの注意はタスクの実行に集中できなくなります。 |
| > 10代 | ユーザーは失望し、タスクを放棄する可能性があります |
応答
メトリクス: ユーザーにできるだけ早く応答する必要があり、ユーザー入力には 100 ミリ秒以内に応答する必要があります。
Web サイトのパフォーマンスの応答性の側面は、ユーザーが遅延を感じる前にアクションに関するフィードバックを受け取ることです。例えば、ユーザーが文字入力、ボタンクリック、フォーム切り替え、起動アニメーションなどの操作を行った後、100ms以内にフィードバックを受信する必要があり、100msを超えるとユーザーは遅延を感じてしまいます。
一見基本的なユーザー操作の背後には、複雑なビジネス ロジック処理、ネットワーク リクエスト、データ計算が隠されている場合があります。これには注意し、比較的高価な作業をバックグラウンドで非同期に実行する必要があります。また、操作を完了するまでにバックグラウンドで数百ミリ秒の処理が必要な場合でも、ユーザーにタイムリーなフィードバックを提供する必要があります。
たとえば、ボタンをクリックして特定の業務処理要求をバックグラウンドで開始すると、最初に処理を開始するためのプロンプトがユーザーに表示され、次に処理を完了するためのプロンプトが処理完了のコールバックでフィードバックされます。
アニメーション アニメーション
インジケーター: アニメーションを表示するときは、アニメーション効果の一貫性を維持し、途切れを避けるために、各フレームを 10 ミリ秒でレンダリングする必要があります。
フロントエンドに関わるアニメーションには、クールな UI 特殊効果だけでなく、スクロール、タッチ、ドラッグなどのインタラクティブな効果も含まれており、この面でのパフォーマンス要件は滑らかさです。周知のとおり、人間の目は視覚の持続性という特性を持っています。つまり、網膜上の光によって生成された視覚は、光の作用が停止した後も一定期間保持されます。
研究によると、これは1/24秒という視神経の反応速度によって引き起こされることがわかっています。つまり、私たちが見ている物体が取り除かれると、その物体は私たちの目の中ですぐに消えるのではなく、1秒間存在し続けるのです。 /24秒。アニメーションの場合、アニメーションのフレーム レートがどんなに高くても、最終的には 30 フレームしか区別できませんが、フレーム レートが高いほどスムーズな体験が得られるため、アニメーションは 60 fps のフレーム レートを達成するために最善を尽くす必要があります。
現在、ほとんどのデバイスの画面リフレッシュ レートは 1 秒あたり 60 回であるため、ブラウザがアニメーションまたはページの各フレームをレンダリングするレートは、デバイス画面のリフレッシュ レートと一致している必要があります。したがって、60fps のフレーム レートの計算によると、各フレームの生成にはいくつかのステップを経る必要があり、フレーム画像の生成にかかる予算は、ブラウザーの時間を除いて 16ms (1000ms / 60 ≈ 16.66ms) となります。新しいフレームを描画するには、実行コードが残ります。時間はわずか 10ms 程度です。この予算を満たせない場合、フレーム レートが低下し、画面上でコンテンツが不安定になります。この現象は一般にスタッタリングと呼ばれ、ユーザー エクスペリエンスに悪影響を与える可能性があります。
Chrome が提供するサンプル ページを開いて効果を確認し、青い四角の転送速度が大幅に遅くなるまで [追加 10] をクリックし続けます: Janky アニメーション
アイドル状態
メトリクス: JavaScript メイン スレッドを使用する場合は、タスクを実行時間が 50 ミリ秒未満のフラグメントに分割する必要があります。これにより、スレッドがユーザー操作のために解放されます。
通常、Web サイトを迅速に応答させ、アニメーションをスムーズにするには長い処理時間がかかりますが、ユーザー中心の観点からパフォーマンスの問題を見ると、応答フェーズと読み込みフェーズですべての作業を完了する必要がないことがわかります。ユーザーが遅延を感じない限り、時間は遅延する可能性のあるタスクを処理します。アイドル時間を利用して遅延を処理すると、プリロードされたデータのサイズが削減され、Web サイトまたはアプリが迅速に読み込まれるようになります。
ブラウザのアイドル時間をより合理的に使用するには、処理タスクを 50 ミリ秒単位でグループ化するのが最善です。これは、操作の発生後、ユーザーが 100 ミリ秒以内に応答するようにするために行われます。
負荷 負荷
メトリクス: 最初の読み込みは 5 秒以内に完了し、ユーザーの操作が可能になる必要があります。以降のロードについては、2 秒以内に完了することをお勧めします。
ユーザーの認識では、ページの読み込みを 5 秒以内に完了するために最善を尽くす必要がありますが、それが完了しない場合、ユーザーの注意は他のことに集中し、現在の処理タスクが中断されたように感じられます。ページの読み込みとレンダリングを 5 秒以内に完了するという要件は、すべてのページ リソースの読み込みを完了することではないことに注意してください。ユーザーの知覚エクスペリエンスの観点から、主要なレンダリング パスが完了している限り、ユーザーはすべてのロードが完了したと考えてください。
ブラウザがアイドル状態になるまで、他の重要ではないリソースの読み込みを遅らせるのは、一般的な漸進的最適化戦略です。画像の遅延読み込み、コード分割、その他の最適化方法など。
ユーザーエクスペリエンスに基づいたパフォーマンス指標
ユーザーエクスペリエンスに基づくコア指標は、 Google によって web.dev で提案されました。
ファーストコンテンツフルペイント（FCP）
FCP (First Contentful Paint) の最初のコンテンツ描画。ブラウザーが初めて DOM からコンテンツを描画するとき。コンテンツは、テキスト、画像 (背景画像を含む)、白以外のキャンバス、または SVG (Web フォントを含む) である必要があります。読み込まれたテキスト。
ユーザーがページ コンテンツを見始めるのはこれが初めてですが、コンテンツがあるからといって、それが有用なコンテンツ (ヘッダー、ナビゲーション バーなど) であるとは限りませんし、ユーザーがコンテンツを消費したいとも限りません。
速度インジケーター
| FCP 時間 (秒) | カラーコーディング | FCP スコア (HTTP アーカイブ パーセンタイル) |
|---|---|---|
| 0-2 | 緑（速い） | 75-100 |
| 2-4 | オレンジ（中） | 50-74 |
| >4 | 赤（遅い） | 0-49 |
最適化
https://web.dev/fcp/#how-to-improve-fcp
最大のコンテンツフルペイント（LCP）
LCP (Largest Contentful Paint)最大コンテンツ描画、表示領域内の最大のコンテンツ要素が画面上にレンダリングされる時間。ページのメイン コンテンツがユーザーに表示される時間を推定するために使用されます。
LCP で考慮される要素:
<img>エレメント<svg>要素内の<image>要素<video>エレメント（表紙画像）- 関数を介して
url()背景画像を読み込む要素 - テキスト ノードまたは他のインライン レベルのテキスト要素の子を含むブロック レベルの要素
優れたユーザー エクスペリエンスを提供するには、サイトでは 2.5 秒以下の「最大コンテンツ ペイント」を使用するように努める必要があります。大多数のユーザーがこの目標を達成していることを確認するには、モバイル デバイスとデスクトップ デバイスのページ読み込みの 75 パーセンタイルを測定することが適切な尺度です。
ここではいくつかの例を示します。
上記の両方のタイムラインでは、コンテンツが読み込まれるにつれて最大の要素が変化します。最初の例では、新しいコンテンツが DOM に追加され、最大の要素が変更されます。2 番目の例では、レイアウトが変更され、以前の最大のコンテンツがビューポートから削除されます。
遅延読み込みされたコンテンツは、ページ上に既に存在するコンテンツよりも大きいことがよくありますが、必ずしもそうである必要はありません。次の 2 つの例は、ページが完全に読み込まれる前に発生する最大のコンテンツ ペイントを示しています。
最初の例では、Instagram ロゴは比較的早い段階で読み込まれ、他のコンテンツが徐々に明らかになったとしても、依然として最大の要素です。2 番目の Google 検索結果ページのサンプル例では、最大の要素は、画像やロゴの読み込みが完了する前に表示されるテキストです。個々の画像はすべてこのセグメントより小さいため、読み込みプロセス全体を通じて常に最大の要素になります。
Instagram タイムラインの最初のフレームでは、カメラのロゴが最大の要素として扱われていないことに気づくかもしれません (周囲に緑色のフレームがありません)。これは、これは
<svg>要素であり、<svg>要素は現在 LCP の候補とみなされないためです。
速度インジケーター
| LCP 時間 (秒) | カラーコーディング |
|---|---|
| 0～2.5 | 緑（速い） |
| 2.5-4 | オレンジ（中） |
| >4 | 赤（遅い） |
最適化
https://web.dev/optimize-lcp/
最初の入力遅延（FID）
FID (初回入力遅延)は、ユーザーによるページとの最初のインタラクション (リンクをクリックする、ボタンをクリックするなど) から、ブラウザーが実際にインタラクションに応答できるようになるまでの最初の入力遅延です。
入力ラグは、ブラウザのメインスレッドが他の処理でビジー状態でユーザーに応答できないために発生します。この問題が発生する一般的な理由は、ブラウザーが、アプリケーションによって読み込まれた計算量の多い JavaScript の解析と実行で忙しいことです。
通常、最初の入力ラグは、最初のコンテンツ ペイント (FCP) と持続可能なインタラクション時間 (TTI) の間に発生します。これは、ページが一部のコンテンツをレンダリングしたが、まだ確実に操作できないためです。
上の図に示すように、ブラウザがユーザー入力を受け取ると、メインスレッドは長時間かかるタスクの実行でビジー状態になり、そのタスクが完了して初めてブラウザがユーザー入力に応答できるようになります。待機する必要がある時間は、このページ上のそのユーザーの FID 値です。
たとえば、次の HTML 要素はすべて、ユーザーの操作に応答する前に、メイン スレッドで進行中のタスクが完了するまで待機する必要があります。
- テキスト入力ボックス、チェックボックス、ラジオボタン（
<input>、<textarea>） - ドロップダウン メニューを選択します (
<select>) - リンク(
<a>)
速度インジケーター
| FID 時間 (ミリ秒) | カラーコーディング |
|---|---|
| 0～100 | 緑（速い） |
| 100-300 | オレンジ（中） |
| >300 | 赤（遅い） |
最適化
- https://web.dev/fid/#how-to-improve-fid
- https://web.dev/optimize-fid/
インタラクティブ化までの時間（TTI）
TTI (Time to Interactive) は、 Web ページが初めて完全にインタラクティブ状態に達し、ブラウザがユーザーの入力に継続的に応答できる時点を示します。完全な対話型状態に達する時点は、最後の長いタスク (長いタスク) が完了し、ネットワークとメイン スレッドが次の 5 秒間アイドル状態になるときです (長いタスクではありません)。
定義の観点からは、中国語名は「持続可能なインタラクションタイム」または「流暢なインタラクションタイム」の方が適切です。
完了までに 50 ミリ秒を超えるタスクは、長いタスクと呼ばれます。
速度インジケーター
| TTI時間（秒） | カラーコーディング |
|---|---|
| 0～3.8 | 緑（速い） |
| 3.9-7.3 | オレンジ（中） |
| >7.3 | 赤（遅い） |
最適化
https://web.dev/tti/#how-to-improve-tti
総ブロック時間（TBT）
TBT (合計ブロック時間) は、 FCP と TTI の間の、受信応答を妨げるほどメインスレッドがブロックされる合計時間を測定します。
長いタスクがある限り (タスクがメイン スレッドで 50 ミリ秒を超えて実行されている場合)、メイン スレッドは「ブロックされている」とみなされます。ブラウザは進行中のタスクを中断できないため、メインスレッドが「ブロック」されていると言えます。したがって、ユーザーが長いタスクの途中でページを操作した場合、ブラウザーは応答する前にタスクが完了するまで待つ必要があります。
タスクが十分に長い場合 (たとえば、50 ミリ秒を超えるもの)、ユーザーは遅延に気づき、ページが遅いか古いと感じる可能性があります。
長いタスクのブロック時間は、その期間のうち 50 ミリ秒を超える部分です。ページの合計ブロック時間は、FCP と TTI の間に発生した各長いタスクのブロック時間の合計です。
たとえば、ページ読み込み中のブラウザのメイン スレッドを示す次の図を考えてみましょう。
上のタイムラインには 5 つのタスクがあり、そのうち 3 つは 50 ミリ秒を超える長いタスクです。
次のグラフは、各長いタスクのブロック時間を示しています。
したがって、メインスレッドでタスクの実行に費やされる合計時間は 560 ミリ秒ですが、ブロック時間とみなされるのは 345 ミリ秒だけです。
速度インジケーター
| TBT時間（ミリ秒） | カラーコーディング |
|---|---|
| 0-30 | 緑（速い） |
| 300-600 | オレンジ（中） |
| >600 | 赤（遅い） |
最適化
https://web.dev/tbt/#how-to-improve-tbt
累積レイアウトシフト（CLS）
CLS (Cumulative Layout Shift)累積レイアウト シフト。CLS は、ページのライフ サイクル全体における各要素の予期しないレイアウト シフト スコアの合計を測定します。2 つのレンダリング フレーム内でビジュアル要素の開始位置が異なるたびに、LS (Layout Shift) が発生したと見なされます。
リンクまたはボタンをクリックしたいのに、指を離した瞬間にリンクが移動し、別のものをクリックしてしまうというシナリオを想像してください。
ページ コンテンツの予期しない移動は、リソースの非同期読み込みや既存のコンテンツへの DOM 要素の動的追加が原因でよく発生します。原因は、サイズが不明な画像やビデオ、または動的にサイズを変更するサードパーティの広告やウィジェットなどである可能性があります。
速度インジケーター
| CLS 時間 (ミリ秒) | カラーコーディング |
|---|---|
| 0-0.1 | 緑（速い） |
| 0.1～0.25 | オレンジ（中） |
| >0.25 | 赤（遅い） |
最適化
- https://web.dev/cls/#how-to-improve-cls
- https://web.dev/optimize-cls/
スピードインデックス（SI）
Speed Index (SI) は、ページの可視領域にコンテンツが表示される速度を示す指標で、コンテンツがページの可視領域に表示されるまでの平均時間を計算することで測定できます。ページ。
測定方法
このような曲線は、ページを読み込むブラウザのビデオをキャプチャし、ページの 100 ミリ秒間隔のスクリーンショットごとにページ コンテンツが占める割合を計算することで取得できます。
途中の例 1 と例 2 はどちらも 10 秒で埋められていますが、例 1 は 2 秒ですでに内容の 80% が埋められており、例 2 は 8 秒で 80% しか埋められていません。
図の斜線部分 (つまり、時間-コンテンツ充填率曲線の上の部分) の面積は、表示領域におけるページ コンテンツの充填速度を表すことができ、面積が小さいほど充填速度は速くなります。 。
速度インジケーター
| 速度メトリック (秒単位) | カラーコーディング | スピードインデックススコア |
|---|---|---|
| 0-4.3 | 緑（速い） | 75-100 |
| 4.4-5.8 | オレンジ（中） | 50-74 |
| >5.8 | 赤（遅い） | 0-49 |
最適化
https://web.dev/speed-index/#how-to-improve-your-speed-index-score
ウェブバイタル
Google は、ユーザー エクスペリエンスと品質を測定して最適化の機会を明らかにするのに役立つ多くの有用な指標とツールを開発してきました。Web Vitals と呼ばれる取り組みは、学習曲線を短縮し、Web サイト エクスペリエンスのための統一された一連の品質基準である Core Web Vitals を提供します。これには、ページ コンテンツの読み込みエクスペリエンス、インタラクティブ性、視覚的な安定性が含まれます。
Web サイトのユーザー エクスペリエンスを最適化する方法はたくさんあります。最適な最適化手段を事前に把握しておくと、時間と費用を大幅に節約できます。
2020 年 5 月 5 日、Google は、Web サイトのユーザー エクスペリエンスを測定し、その測定値をランキング アルゴリズムの一部として使用するための新しいユーザー エクスペリエンス定量化手法である Web Vitals を提案しました。
コア ウェブ バイタルとウェブ バイタル
Web Vitals とは、Google が定義した定義で、良好な Web サイトの基本的な指標 (健全なサイトの必須指標)です。
以前は、Web サイトの品質を測定するには指標が多すぎましたが、Web Vitals を使用すると、指標の学習曲線が簡素化され、Web Vitals 指標のパフォーマンスだけに集中する必要があります。
これらの Web Vitals のうち、Google は、すべての種類の Web サイトに共通する 3 つの主要な指標、つまり Core Web Vitals を特定しました。
コア Web バイタルは、すべての Web ページに適用される Web バイタルのサブセットであり、Web ページの最も重要なコアです。
| 索引 | 説明 | 良い | 貧しい | パーセンタイル |
|---|---|---|---|---|
| ローディングパフォーマンス (LCP) | 最大のコンテンツ要素を表示するのに必要な時間 | ≤2500ms | ＞4000ms | 75 |
| インタラクティブ性 (FID) | 最初のエントリー遅延時間 | ≤100ms | >300ミリ秒 | 75 |
| 視覚安定化 (CLS) | 累積レイアウトオフセット | ≤0.1 | >0.25 | 75 |
ウェブバイタルの測定
- Lighthouse などのパフォーマンス テスト ツール
- Web-Vitalsライブラリの使用
- ブラウザプラグインWeb Vitalsの使用