基準測試 — 效能基線與回歸偵測
使用時機
- 在 PR 前後測量效能影響
- 為專案建立效能基線
- 當使用者回報「感覺變慢了」
- 在發布前，確保達到效能目標
- 比較自家技術方案與其他替代方案的優劣
運作方式
模式 1：網頁效能
透過瀏覽器 MCP 測量真實瀏覽器指標：
1. 導覽至每個目標 URL
2. 測量核心網頁指標：
- LCP (最大內容繪製) — 目標 < 2.5 秒
- CLS (累計版面配置位移) — 目標 < 0.1
- INP (與下一次繪製的互動) — 目標 < 200 毫秒
- FCP (首次內容繪製) — 目標 < 1.8 秒
- TTFB (第一個位元組的時間) — 目標 < 800 毫秒
3. 測量資源大小：
- 總頁面重量 (目標 < 1 MB)
- JS 套件大小 (目標 < 200 KB 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 | 警告：需注意 |
| Bundle | 180KB | 175KB | -5KB | ✓ 改善 |
| Build | 12s | 14s | +2s | 警告：需注意 |
輸出
將基線儲存在 .ecc/benchmarks/ 目錄下的 JSON 檔案中。這些檔案會被 Git 追蹤，以便團隊共享基線。
整合
- CI：在每個 PR 上執行
/benchmark compare - 搭配
/canary-watch使用：進行部署後的監控 - 搭配
/browser-qa使用：完成完整的發布前檢查清單