パフォーマンスバジェット vs Real User Metrics (RUM)
パフォーマンスバジェット（合成的な制限）とReal User Monitoring（RUM）データの違いを理解。完全なパフォーマンス戦略のために両方を併用する方法を解説。
Tooling
詳細な説明
パフォーマンスバジェット vs Real User Metrics
パフォーマンスバジェットとReal User Monitoring（RUM）は補完的な目的を持ちます。バジェットはプロアクティブ — デプロイ前にリグレッションを防止。RUMはリアクティブ — デプロイ後に実際のユーザーが体験するパフォーマンスを測定。
主な違い
| 側面 | パフォーマンスバジェット | RUM |
|---|---|---|
| タイミング | デプロイ前（CI/CD） | デプロイ後（本番） |
| データソース | 合成（ラボ） | 実ユーザー（フィールド） |
| 一貫性 | 決定論的 | 可変（デバイス、ネットワーク） |
| 指標タイプ | ファイルサイズ、リクエスト数 | LCP、FID、CLS、TTFB |
| フィードバック速度 | 即座（PRチェック） | 遅延（収集に数時間/数日） |
両方が必要な理由
バジェットだけでは不十分：
- 500 KBのページでもすべてのリソースがレンダーブロッキングなら遅くなる
- サードパーティスクリプトがファイルサイズチェックでは捕捉されないレイテンシを追加する可能性
- サーバーレスポンスタイム（TTFB）はページウェイトバジェットの一部ではない
RUMだけでも不十分：
- RUMがリグレッションを示す頃には、すでにユーザーに影響している
- RUMデータは統計的に有意になるのに十分なトラフィックが必要
- RUMは悪いデプロイを防止できない — 事後検出のみ
両方を併用する
理想的なワークフロー：
- マージ前: CIでのパフォーマンスバジェットチェック（size-limit、Lighthouse CI）
- ステージングデプロイ後: ステージングに対する合成Lighthouse実行
- 本番デプロイ後: RUM収集（Web Vitals、カスタム指標）
- 週次レビュー: バジェット閾値に対するRUMトレンドの比較
ユースケース
バジェットとRUMの組み合わせは完全なパフォーマンス戦略を生み出します。プロダクトチームはCIで強制される500 KBのページウェイトバジェットを設定し、本番環境でweb-vitals経由のp75 LCPを追跡するかもしれません。バジェットはパスするがRUMが遅いLCPを示す場合、チームはサーバーレスポンスタイムやリソース読み込み順序を調査します — バジェットでは捕捉できない問題です。逆に、開発者のPRがバジェットを超えると、実ユーザーに影響を与える前にブロックされます。