ベンチマーク — パフォーマンスベースラインと回帰検出 は何をしますか？
使用タイミング
- PRの前後でパフォーマンス影響を測定する場合
- プロジェクトのパフォーマンスベースラインを設定する場合
- ユーザーが「動作が遅い」と報告した場合
- リリース前 — パフォーマンス目標を達成していることを確認する場合
- 自スタックと代替案を比較する場合
仕組み
モード1: ページパフォーマンス
ブラウザMCPを介して実際のブラウザメトリクスを測定:
1. 各ターゲットURLに移動
2. Core Web Vitalsを測定:
- LCP (Largest Contentful Paint) — target < 2.5s
- CLS (Cumulative Layout Shift) — target < 0.1
- INP (Interaction to Next Paint) — target < 200ms
- FCP (First Contentful Paint) — target < 1.8s
- TTFB (Time to First Byte) — target < 800ms
3. リソースサイズを測定:
- 合計ページ重量 (target < 1MB)
- JSバンドルサイズ (target < 200KB gzipped)
- 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: 変更前後比較
変更の前後で実行して影響を測定:
/benchmark baseline # 現在のメトリクスを保存
# ... 変更を加える ...
/benchmark compare # ベースラインと比較
出力:
| メトリクス | 変更前 | 変更後 | 差分 | 判定 |
|------------|--------|--------|------|------|
| LCP | 1.2s | 1.4s | +200ms | WARNING: WARN |
| バンドル | 180KB | 175KB | -5KB | ✓ BETTER |
| ビルド | 12s | 14s | +2s | WARNING: WARN |
出力
ベースラインを.ecc/benchmarks/にJSONとして保存。Gitで追跡されるため、チーム全体でベースラインを共有できます。
統合
- CI: すべてのPRで
/benchmark compareを実行 /canary-watchと組み合わせてデプロイ後の監視に利用/browser-qaと組み合わせてリリース前の完全チェックリストに活用