JavaScriptバンドルサイズバジェット戦略
JavaScriptバンドルサイズバジェットの定義と実施。分割戦略、ツリーシェイキング、コード分割チャンクとサードパーティスクリプト間のJSサイズのパフォーマンスバジェット追跡方法。
Asset Budgets
詳細な説明
JavaScriptバンドルサイズバジェット
JavaScriptは通常、Webページで最もコストの高いアセットです。ダウンロードコスト以外に、JSにはパース、コンパイル、実行コストがあり、Time to Interactive（TTI）とTotal Blocking Time（TBT）に直接影響します。
推奨JSバジェット範囲
| サイトタイプ | JSバジェット |
|---|---|
| ブログ/コンテンツ | 50-80 KB |
| ランディングページ | 60-100 KB |
| Eコマース | 150-300 KB |
| SPA | 200-400 KB |
| ダッシュボード | 300-500 KB |
これらは転送サイズ（圧縮済み）です。非圧縮サイズは通常3-4倍大きくなります。
JSバジェットの内訳
JSバジェットはカテゴリ間で分割すべきです：
- フレームワーク/ランタイム — React（約40 KB gzip）、Vue（約30 KB）、Svelte（約2 KB）
- ファーストパーティコード — アプリケーションロジック
- サードパーティスクリプト — アナリティクス、広告、チャットウィジェット、A/Bテスト
- ポリフィル — 必要なブラウザにのみ配信
追跡戦略
パフォーマンスバジェットトラッカーにリソースを追加する際：
- 各コード分割チャンクを個別のエントリとして追加（例：
vendor.js、app.js、page-home.js） - サードパーティスクリプトを実際の転送サイズで含める
- HTML内のインラインスクリプトを考慮
バンドルサイズの削減
- ツリーシェイキング — モダンなバンドラー（webpack、Rollup、esbuild）で未使用コードを削除
- コード分割 — ダイナミックインポートで必要時のみJSを読み込み
- 圧縮 — 本番環境でBrotli（gzipより30%小さい）を使用
- バンドル分析 — webpack-bundle-analyzerのようなツールで肥大化を特定
- インポートコスト意識 — 依存関係追加前にパッケージサイズを確認
サードパーティの問題
サードパーティスクリプトはJSバジェット違反の主要原因です。1つのアナリティクススクリプトで50-100 KB追加される可能性があります。各サードパーティスクリプトを個別のリソースエントリとして追跡し、各スクリプトがコストに見合うかどうかを定期的に監査します。
ユースケース
JavaScriptバジェット追跡は、SPAや複雑なWebアプリケーションに取り組むチームにとって重要です。よくあるシナリオ：初期ビルドはバジェット内で出荷されますが、数ヶ月の機能開発で誰も気づかないうちにバンドルが2-3倍に成長します。パフォーマンスバジェットトラッカーでの継続的な追跡により、このドリフトを早期にキャッチできます。