基準測試 — 效能基線與回歸檢測 是做什麼的？
使用時機
- PR 前後測量效能影響
- 為專案設定效能基線
- 當使用者回報「感覺很慢」時
- 上線前確保達到效能目標
- 比較你的技術方案與替代方案
運作方式
模式 1：頁面效能
透過瀏覽器 MCP 測量真實瀏覽器指標：
1. 瀏覽每個目標 URL
2. 測量 Core Web Vitals：
- LCP（最大內容繪製）— 目標 < 2.5 秒
- CLS（累計版面配置位移）— 目標 < 0.1
- INP（與下一次繪製的互動）— 目標 < 200 毫秒
- FCP（首次內容繪製）— 目標 < 1.8 秒
- TTFB（第一位元組時間）— 目標 < 800 毫秒
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.2 秒 | 1.4 秒 | +200 毫秒 | 警告：注意 |
| 套件 | 180KB | 175KB | -5KB | ✓ 改善 |
| 建置 | 12 秒 | 14 秒 | +2 秒 | 警告：注意 |
輸出
將基線儲存在 .ecc/benchmarks/ 目錄下，格式為 JSON。這些檔案會透過 Git 追蹤，以便團隊共享基線。
整合
- CI：在每個 PR 上執行
/benchmark compare - 搭配
/canary-watch進行部署後監控 - 搭配
/browser-qa作為完整的上線前檢查清單