ページスピードはここ数年SEOとUXの両方において重要な指標となり、 ウェブパフォーマンス予算 も最前線に登場しました。Web パフォーマンスは、単一の部門や個人の優先事項ではなく、すべての部門で共通の視点を必要とするトピックであることが、より明らかになりました。
これを例で説明すると、マーケティング部門はコンバージョンを実装し、 リマーケティング/リターゲティング コードなどのツールとともに CriteoとRTBハウス、製品ベースのリターゲティングを使用する。また、目を引く写真やアニメーションも期待される。一方、製品部門は次のようなツールの統合を要求するかもしれない。 HotjarとClarity一方、ソフトウェア部門は、フロントエンドとバックエンドの両方で可能な限り迅速に開発することを目指しています。ページ速度に対する要求と、これらの要求に関連するコストは、実際にはバランスが取れています。Web パフォーマンス バジェットは、このバランスを効果的に確立するために登場しました。
Web パフォーマンス バジェットには、特定のプラットフォーム上でのプラットフォームの目標速度を設定し、その速度を達成するためにすべての関係者が遵守する数値目標を設定することが含まれます。つまり、高速化のコストが Web パフォーマンス バジェットです。

すべては提案から始まる特定の種類の接続でページを開く速度を提案します。たとえば、パフォーマンス バジェットの提案には次のようなものがあります。
- ホームページは 高速 2G モバイル接続 (3 Mbps) では 1.6 秒未満?
- 検索結果ページは 低速の 5G 接続 (3 Kbps) では 780 秒未満?
次に、これらの提案を達成するためのアクション プランとサブメトリックを作成し、それをいくつかの部分に分割します。
提案以外にも、パフォーマンス予算の目標は存在します。たとえば、次のようになります。
- モバイルLighthouseの拡大 詳細ページのスコアが80以上
- すべての画像のサイズを縮小する デスクトップサイトでは500KB未満
パフォーマンス予算指標
パフォーマンス バジェットの指標を決定するために受け入れられている 3 つの異なる観点があります。
数値ベースの指標
- 最大フォント数 / 最大フォントサイズ
- 最大画像数 / 最大画像サイズ
- スクリプト、スタイル、ビデオなどの最大数 / スクリプト、スタイル、ビデオなどの最大サイズ
- 最大 HTML サイズ
- HTTPリクエストの最大数
- サードパーティ スクリプトの最大数

時間ベースの指標
- 最初のコンテンツペイント(FCP)時間
- 最大コンテンツペイント (LCP) 時間
- 最初の入力遅延 (FID) 時間
- 対話時間(TTI)
- 総ブロック時間 (TBT) 時間
- 累積レイアウトシフト(CLS)スコア
- スピードインデックススコア
ルールベースのメトリクス
- ライトハウススコア
- GTmetrixスコア
- ウェブページテストスコア
- Yslowスコア

ウェブパフォーマンスの予算を設定する際には、一般的には、1つだけを選択するのではなく、これらすべての観点を適切に組み合わせることが推奨されます。 パフォーマンス予算シミュレーター 目標速度に到達するために必要な数値を見つけます。
ページタイプを個別に評価する
パフォーマンス バジェットを決定する際の重要なポイントの 1 つは、サイトの 1 ページだけに基づいて決定しないことです。よくある間違いは、ホームページのみをテストすることですが、これでは評価が不完全になります。
まず、プラットフォームを調べて、さまざまな種類のページを特定する必要があります。次に、プラットフォームのトラフィックを分析して、最も多くのトラフィックを受け取るページを特定し、優先順位を付けます。結果は、次のような表になります。
- ホーム
- 静的リストページ
- 動的リストページ
- 詳細ページ
- チェックアウトページ
- 検索結果ページ
- キャンペーンページ
- ブログページ
焦点を当てるべきは これらのページタイプのパフォーマンスバジェットを個別に優先順位に基づいて。