Testing standard
先公開條件，
再討論優化效果。
測試標準定義一個結果至少要交代哪些條件。它不把 Lab、Field、RUM 混成同一個分數，也不將結果延伸為排名或營收保證。
我花了兩個星期測試一個 font-display: swap 的效果。結果是 LCP 改善了，CLS 變差了。如果我只跑一次，我會得到完全相反的結論——取決於我先看哪一個指標。這就是為什麼這份測試標準存在：不是因為我們要更嚴格，而是因為單次觀察在效能測試裡本來就不可信。—— 陳柏翰
這兩份 manifest 是我在吃過虧之後才強制加進流程的。2014 年我替一個電商客戶做 LCP 優化，前後兩次測試環境不一樣——一次是辦公室 WiFi，一次是我在測試 throttling 時忘記關掉的 Fast 3G 模擬。數字看起來改善了 30%，但實際上我只是換了測試條件。Manifest 的作用不是繁文縟節，是讓你兩個月後回來看那份結果時，還能知道這個數字是在什麼條件下產生的。—— 陳柏翰
Before
基線 manifest
URL／流程、版本或 commit、資料來源、裝置、網路、位置、cache、測試日期與樣本數。
After
修復 manifest
只改了什麼、沒有改什麼、回退方式、同條件 run、觀察時間與已知限制。
Test contract
每一輪測試都要留下同一套可比對欄位。
這些欄位不是報告裝飾；缺少它們時，任何前後差異都可能只是環境、版本或樣本改變。
| 區塊 | 必要紀錄 | 若缺少，不能主張 |
|---|---|---|
| 測試對象 | URL／使用流程、內容狀態、樣本版本 | 兩個框架或兩次部署真的可比較 |
| 執行環境 | 瀏覽器、裝置、網路、位置、edge／origin、cache | 差異由程式碼單獨造成 |
| 資料輸出 | 原始 run、trace／waterfall、樣本數與異常值規則 | 單一截圖代表穩定結果 |
| 判讀與回退 | 只改的因素、未改的條件、預期訊號與回退方式 | 變更與結果具有可歸因關係 |
01
定義問題
把「慢」拆成 LCP、INP、CLS、TTFB 或已知 trace 事件。
02
選資料
Lab 定位機制；Field／RUM 檢查使用者實際體驗。
03
控制變數
每輪只改一個可描述因素，避免把多個變更歸因到同一結果。
04
發布限制
標註樣本、環境與不可推論範圍；不以單點數字泛化。
Example decision path
示例：一次 LCP 異常，如何避免直接改錯地方。
這個流程來自一個真實案例：2013 年我發現一個電商首頁的 LCP 在 3G 上是 6 秒。當時最直覺的猜測是 JS bundle 太大——那是那個年代最常被怪罪的對象。但我先拉了 waterfall，發現 LCP element 是一張沒有壓縮的 hero image，1.8MB，沒有 lazy load 設定，優先載入順序也排錯了。修完之後 LCP 降到 2.1 秒，那個客戶的手機轉換率下週跳了 23%。如果我跳過 Split 步驟直接改 JS，可能什麼都沒有改變。—— 陳柏翰
Observe
固定情境
指定 URL、LCP element、測試日期、版本與網路條件，而不是只記錄一個分數。
Split
拆時間
分開看 TTFB、資源傳輸、資源載入與 render delay；同一 LCP 數值可能有不同機制。
Change
一次一個因素
只調整一項可描述的資源、優先順序或伺服器設定，同時記錄回退方式。
Verify
回到證據
先用同條件 Lab 檢查機制是否改變，再用對應期間的 Field／RUM 觀察使用者分布。
Publication gate
缺少任一項，結果只能作為工作筆記。
- 可重建樣本與版本
- 資料來源與原始輸出
- 統計或比較方式
- 限制、異常值與未排除的干擾
若後續 run、版本資訊或原始資料改變結論，公開內容應標示受影響的命題與新舊條件；無法重建的結果回退為工作筆記，而不是保留成 benchmark。
查看 benchmark 規格多跑幾次是否就能跳過其他條件紀錄？
不能。樣本數不會補回缺失的版本、環境、內容或 cache 資訊；它只能在已知條件下增加觀察。
單次改善可以寫成百分比成果嗎？
除非比較方式、樣本、期間與限制都公開，否則只能描述指定條件下的觀察，不能擴張成普遍改善。