benchmark

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