benchmark

Benchmark — 效能基準與回歸偵測

使用時機

• 在 PR 前後測量效能影響
• 為專案建立效能基準
• 當使用者回報「感覺很慢」時
• 上線前 — 確保達到效能目標
• 比較你的技術方案與其他替代方案

運作方式

模式 1：頁面效能

透過瀏覽器 MCP 測量真實瀏覽器指標：

1. 導航至每個目標 URL
2. 測量 Core Web Vitals：
   - LCP (最大內容繪製) — 目標 < 2.5s
   - CLS (累計版面配置位移) — 目標 < 0.1
   - INP (與下一次繪製的互動) — 目標 < 200ms
   - FCP (首次內容繪製) — 目標 < 1.8s
   - TTFB (第一個位元組的時間) — 目標 < 800ms
3. 測量資源大小：
   - 頁面總重量 (目標 < 1MB)
   - JS 套件大小 (目標 < 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. Lint 時間
6. Docker 建置時間

模式 4：前後比較

在變更前後執行以測量影響：

/benchmark baseline    # 儲存當前指標
# ... 進行變更 ...
/benchmark compare     # 與基準比較

輸出：

| 指標 | 之前 | 之後 | 差異 | 結果 |
|--------|--------|-------|-------|---------|
| LCP | 1.2s | 1.4s | +200ms | 警告：WARN |
| Bundle | 180KB | 175KB | -5KB | ✓ 更好 |
| Build | 12s | 14s | +2s | 警告：WARN |

輸出

將基準儲存在 .ecc/benchmarks/ 目錄下，格式為 JSON。這些檔案會納入 Git 版本控制，以便團隊共享基準。

整合

• CI：在每個 PR 上執行 /benchmark compare
• 搭配 /canary-watch 進行部署後監控
• 搭配 /browser-qa 完成完整的出貨前檢查清單