バンドルサイズの監視とリグレッション検出
JavaScriptとCSSのバンドルサイズを経時的に監視してパフォーマンスリグレッションを検出。webpack-bundle-analyzer、source-map-explorer、サイズ追跡ダッシュボードの使用方法。
Tooling
詳細な説明
バンドルサイズの監視
パフォーマンスバジェットは制限を定義しますが、監視はその制限にどれだけ近づいているかを経時的に追跡します。監視なしでは、機能追加に伴いページウェイトが徐々に増加します — パフォーマンスリグレッションまたはバンドル肥大化と呼ばれる現象です。
よくある監視ツール
| ツール | 目的 | 出力 |
|---|---|---|
| webpack-bundle-analyzer | バンドル内容の可視化 | インタラクティブツリーマップ |
| source-map-explorer | ソースマップサイズの分析 | ソースマップからのツリーマップ |
| size-limit | CIでのサイズ追跡 | CLI/CIレポート |
| bundlephobia | npmパッケージサイズの確認 | Webインターフェース |
| Import Cost (VS Code) | インポートサイズのインライン表示 | エディタヒント |
注意すべき点
一般的なバンドルサイズリグレッション：
- ライブラリ全体の誤ったインポート —
import _ from 'lodash'（70 KB）vsimport debounce from 'lodash/debounce'（1 KB） - 重複依存 — 推移的依存による同じライブラリの2つのバージョン
- デッドコード — フィーチャーフラグは削除されたが機能コードがバンドルに残る
- 不要なポリフィル — ターゲットブラウザがすべてサポートしている機能のcore-jsポリフィル
- 開発専用コード — プロダクションビルドに残ったロガー、デバッグツール
自動アラート
以下についてアラートを設定：
- 単一PRでバンドルサイズが10 KB以上増加
- リリースごとにバンドルサイズが5%以上増加
- 新しいnpm依存の追加（正当化が必要）
- 重複パッケージバージョンの検出
ユースケース
バンドルサイズ監視は、複数チームがコードに貢献する長寿命アプリケーションにとって重要です。50人の開発者がいるSaaS製品は、誰もトレンドに気づかないまま、1年でJSバンドルが200 KBから500 KBに成長する可能性があります。エンジニアリングリードへの週次バンドルサイズレポートが説明責任を生み出します。バンドルがバジェット制限に近づいたとき、チームはパフォーマンスが劣化する前に未使用コードの削除やリファクタリングを先回りして行えます。