ベンチマーク — パフォーマンスベースラインとリグレッション検出
使用するタイミング
- PRの前後でパフォーマンスへの影響を計測する場合
- プロジェクトのパフォーマンスベースラインを設定する場合
- ユーザーが「動作が遅い」と報告した場合
- リリース前 — パフォーマンス目標を達成していることを確認する場合
- 現在のスタックを代替案と比較する場合
動作の仕組み
モード1: ページパフォーマンス
ブラウザMCP経由で実際のブラウザメトリクスを計測します:
1. 各ターゲットURLに移動
2. Core Web Vitalsを計測:
- LCP (Largest Contentful Paint) — 目標 < 2.5秒
- CLS (Cumulative Layout Shift) — 目標 < 0.1
- INP (Interaction to Next Paint) — 目標 < 200ms
- FCP (First Contentful Paint) — 目標 < 1.8秒
- TTFB (Time to First Byte) — 目標 < 800ms
3. リソースサイズを計測:
- 総ページ重量 (目標 < 1MB)
- JSバンドルサイズ (目標 < 200KB gzip圧縮)
- CSSサイズ
- 画像重量
- サードパーティスクリプトの重量
4. ネットワークリクエスト数をカウント
5. レンダリングブロックリソースの有無を確認
モード2: APIパフォーマンス
APIエンドポイントをベンチマーク:
1. 各エンドポイントに100回リクエスト
2. 計測: p50, p95, p99 レイテンシ
3. 追跡: レスポンスサイズ、ステータスコード
4. 負荷テスト: 10の同時リクエスト
5. SLA目標との比較
モード3: ビルドパフォーマンス
開発フィードバックループを計測:
1. コールドビルド時間
2. ホットリロード時間 (HMR)
3. テストスイートの実行時間
4. TypeScriptチェック時間
5. リント時間
6. Dockerビルド時間
モード4: Before/After比較
変更の前後で計測して影響を測定:
/benchmark baseline # 現在のメトリクスを保存
# ... 変更を加える ...
/benchmark compare # ベースラインと比較
出力:
| メトリクス | Before | After | 差分 | 判定 |
|------------|--------|-------|------|------|
| LCP | 1.2秒 | 1.4秒 | +200ms | 警告: WARN |
| バンドル | 180KB | 175KB | -5KB | ✓ 改善 |
| ビルド | 12秒 | 14秒 | +2秒 | 警告: WARN |
出力
ベースラインは .ecc/benchmarks/ にJSONとして保存されます。Gitで追跡されるため、チーム全体でベースラインを共有できます。
統合
- CI: すべてのPRで
/benchmark compareを実行 /canary-watchと組み合わせてデプロイ後の監視を実施/browser-qaと組み合わせて出荷前の完全チェックリストを実行