パフォーマンスはユーザー エクスペリエンスの重要な要素であり、ビジネス指標に影響します。優れたデベロッパーであれば、最終的にサイトのパフォーマンスは高くなると考えたくなりますが、実際には、優れたパフォーマンスが副作用になることはほとんどありません。他のほとんどの要素と同様に、目標を達成するには、それを明確に定義する必要があります。まず、パフォーマンス バジェットを設定します。
定義
パフォーマンス バジェットとは、サイトのパフォーマンスに影響する指標に適用される一連の制限です。ページの合計サイズ、モバイル ネットワークでの読み込み時間、送信された HTTP リクエストの数などです。予算を定義することで、ウェブ パフォーマンスに関する話し合いを始めることができます。設計、テクノロジー、機能の追加に関する意思決定を行う際の基準となります。
デザイナーは予算を確保することで、高解像度の画像の効果や選択するウェブフォントの数を検討できます。また、デベロッパーは問題に対するさまざまなアプローチを比較したり、サイズと解析コストに基づいてフレームワークとライブラリを評価したりすることもできます。
指標を選択
量ベースの指標 ⚖️
これらの指標は、サイズの大きい画像やスクリプトを含めることの影響を強調するため、開発の初期段階で有用です。また、デザイナーとデベロッパーの両方と簡単にコミュニケーションを取ることができます。
ここまで、ページ ウェイトや HTTP リクエスト数など、パフォーマンス バジェットに含めることができる項目をいくつか説明しましたが、これらは次のような詳細な制限に分割できます。
- 画像の最大サイズ
- ウェブフォントの最大数
- フレームワークを含むスクリプトの最大サイズ
- サードパーティ スクリプトなどの外部リソースの合計数
ただし、これらの数値はユーザー エクスペリエンスについてあまりわかりません。同じリクエスト数または同じ重みの 2 つのページは、リソースがリクエストされる順序によってレンダリングが異なる場合があります。一方のページにあるヒーロー画像やスタイルシートなどの重要なリソースがプロセスの後半で読み込まれると、ユーザーは有用な情報が表示されるのを待つ時間が長くなり、ページの読み込みが遅いと感じます。他のページで最も重要な部分がすぐに読み込まれると、ページの他の部分が読み込まれなくても気づかない可能性があります。
そのため、別のタイプの指標を追跡することが重要です。
マイルストーンのタイミング 🛍?️
マイルストーンのタイミングは、DOMContentLoaded や load イベントなど、ページの読み込み中に発生するイベントを示します。最も有益なタイミングは、ページの読み込み操作についてのなんらかの情報を示すユーザー中心のパフォーマンス指標です。これらの指標は、ブラウザ API を介して、または Lighthouse レポートの一部として参照できます。
First Contentful Paint（FCP）は、ブラウザが DOM からのコンテンツの最初の部分（テキストや画像など）を表示する時間を測定します。
操作可能になるまでの時間（TTI）は、ページが完全に操作可能になり、ユーザー入力に確実に応答するまでの時間を測定します。リンク、ボタン、入力、フォーム要素の使用など、ページでなんらかのユーザー操作が予想される場合は、トラッキングすることが非常に重要な指標です。
ルールベースの指標 🗣?
Lighthouse と WebPageTest は、一般的なベスト プラクティスのルールに基づいてパフォーマンス スコアを計算します。これらのルールをガイドラインとしてご活用ください。Lighthouse では、簡単な最適化のヒントも提供されています。
最良の結果を得るには、数量ベースのパフォーマンス指標とユーザー中心のパフォーマンス指標を組み合わせて使用します。プロジェクトの初期段階ではアセットのサイズに重点を置き、できるだけ早く FCP と TTI のトラッキングを開始します。
ベースラインを確立する
サイトにとって何が最適かを知る唯一の方法は、実際に試してみることです。そして、調査結果をテストすることです。競合状況を分析して、自社の状況を確認しましょう。🕵️
時間がなければ、以下のデフォルトの数値を参考にして作業を開始してください。
- 操作可能になるまでの時間: 5 秒未満
- 170 KB 未満のクリティカル パス リソース（圧縮/圧縮）
これらの数値は、実際の基準となるデバイスと 3G ネットワーク速度に基づいて計算されています。今日、インターネット トラフィックの半分以上はモバイル ネットワーク上で発生しているため、まずは 3G ネットワーク速度から始めるとよいでしょう。
予算の例
コンテンツは多種多様であるため、サイト内のページの種類に応じて予算を用意する必要があります。次に例を示します。
- Google の商品ページは、モバイルで 170 KB 未満の JavaScript を提供する必要があります
- 検索ページの画像は、パソコンで 2 MB 未満にする必要があります
- Moto G4 スマートフォンでは、低速の 3G を使用しても、ホームページは 5 秒未満で読み込まれ、インタラクティブになる必要があります。
- ブログが Lighthouse のパフォーマンス監査で 80 点を超えている
ビルドプロセスにパフォーマンス バジェットを追加する
そのためのツールの選択は、プロジェクトの規模やタスクに割けるリソースによって大きく異なります。構築プロセスに予算を追加する場合に役立つオープンソース ツールがいくつかあります。
定義済みのしきい値を超えた場合は、次のいずれかを行うことができます。
- 既存の機能やアセットを最適化 🛠?️
- 既存の機能またはアセットを削除する 🗑?️
- 新機能やアセットを追加しない 🛍?⛔
パフォーマンスのトラッキング
サイトの速度が十分であることを確認するには、初回リリース後も測定を続ける必要があります。これらの指標を経時的にモニタリングし、実際のユーザーからデータを取得することで、パフォーマンスの変化が主要なビジネス指標にどのように影響するかがわかります。
まとめ
パフォーマンス バジェットの目的は、プロジェクト全体を通してパフォーマンスに焦点を合わせることであり、早期に設定することで後戻りを防ぐのに役立ちます。ウェブサイトに何を掲載するかを検討する際の参考にしてください。主な考え方は、機能やユーザーエクスペリエンスを損なうことなく、パフォーマンスのバランスを取ることができるように目標を設定することです。
次のガイドでは、最初のパフォーマンス バジェットをいくつかの簡単なステップで設定する方法を説明します。