ベンチマーク — パフォーマンスベースラインと回帰検出
使用時期
- 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とペアリングして完全な出荷前チェックリスト

