ベンチマーク — パフォーマンスベースラインと回帰検出

使用時期

• PR前後にパフォーマンスへの影響を測定
• プロジェクトのパフォーマンスベースラインを設定
• ユーザーが「遅く感じる」と報告したとき
• ローンチ前 — パフォーマンスターゲットを満たしていることを確認
• スタックを代替案と比較

動作方法

モード1：ページパフォーマンス

ブラウザMCPを介してリアルブラウザメトリクスを測定：

1. 各ターゲットURLに移動
2. Core Web Vitalsを測定：
   - LCP (Largest Contentful Paint) — ターゲット < 2.5s
   - CLS (Cumulative Layout Shift) — ターゲット < 0.1
   - INP (Interaction to Next Paint) — ターゲット < 200ms
   - FCP (First Contentful Paint) — ターゲット < 1.8s
   - TTFB (Time to First Byte) — ターゲット < 800ms
3. リソースサイズを測定：
   - 合計ページウェイト（ターゲット < 1MB）
   - JSバンドルサイズ（ターゲット < 200KBgzipped）
   - 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. Lint時間
6. Dockerビルド時間

モード4：前後の比較

変更前後に実行して影響を測定：

/benchmark baseline    # 現在のメトリクスを保存
# ... 変更を加える ...
/benchmark compare     # ベースラインと比較

出力：

| Metric | Before | After | Delta | Verdict |
|--------|--------|-------|-------|---------|
| LCP | 1.2s | 1.4s | +200ms | WARNING: WARN |
| Bundle | 180KB | 175KB | -5KB | ✓ BETTER |
| Build | 12s | 14s | +2s | WARNING: WARN |

出力

.ecc/benchmarks/にJSONとしてベースラインを保存。Gitで追跡されるため、チームはベースラインを共有します。

統合

• CI：すべてのPRで/benchmark compareを実行
• /canary-watchとペアリングしてデプロイ後の監視
• /browser-qaとペアリングして完全な出荷前チェックリスト