Measurement sources
工具名稱不是證據；
資料條件才是。
這頁不列「我們使用了什麼工具」來製造權威感，而是說明不同資料型態能回答的問題與限制。
如果你只看 Lighthouse，你可能正在優化一個不存在的用戶的體驗。我見過 Lighthouse 桌面版 92 分的網站，RUM 數據顯示真實用戶 LCP 中位數是 5.8 秒。分數沒有說謊，但測試條件和真實用戶之間的距離讓那個分數變成了一種效能劇場——看起來很好，但對使用者沒有意義。這頁要說的，就是每一種資料能回答什麼、不能替代什麼。—— 陳柏翰
Lab 測試
可以回答：在固定條件下定位載入、主執行緒與 layout 機制。
限制：不能直接代表所有裝置、地區或真實使用者。
常見誤用：我見過最常見的誤用：把 Lighthouse 分數當成用戶體驗報告給客戶。Lab 分數告訴你在一台固定設備、固定網路、固定 cache 條件下的機制行為。它不告訴你你的用戶在哪裡、用什麼裝置、在什麼時段遇到了什麼。
Field／RUM
可以回答：觀察真實使用者在一段時間內的體驗分布與變化。
限制：不會自動指出是哪一段程式或資源造成問題。
常見誤用：常見錯誤是拿 RUM 的 P75 LCP 直接去找「哪行程式碼造成的」。RUM 告訴你有多少用戶受影響、分布怎樣，但它沒有 trace，無法定位機制。要回答「為什麼」，需要配合 Lab trace。
Trace／waterfall
可以回答：拆解資源、CPU、事件與時間順序，形成可檢驗的根因假設。
限制：一次 trace 只能代表該次條件與流程。
常見誤用：一次 trace 是一次快照。如果你的問題只在特定網路條件或特定地區出現，用辦公室 WiFi 跑一次 trace 不會讓那個問題現身。我處理過一個只在東南亞用戶端出現的 LCP 問題，就是因為把本地 trace 當全局答案才拖了三週。
部署與版本紀錄
可以回答：把變更與觀察時間線連起來，排除不相關改動。
限制：相關不等於歸因，仍須回測。
常見誤用：「問題從這次部署之後開始」是一個有用的線索，不是一個結論。我遇過兩次部署同天的情況，RUM 的下滑可以歸因到其中任何一個。版本紀錄縮小了搜尋範圍；縮小不等於確認。
Source pairing
先問問題，再配對資料來源。
一項資料不必回答所有問題。把互補來源並列，才能避免用方便取得的數字替代真正需要的證據。
我在 2015 年有一個案子讓我確立了「先問問題、再選來源」這個順序。當時我直接拉了 RUM 數據，看到某個頁面的 LCP 比其他頁高出一倍，就去調整了圖片大小和快取設定。兩週後 RUM 沒有改變。後來我重新問問題：「這個 LCP 是在哪種裝置上出現的？」打開分裝置的 RUM 切片，發現問題集中在低階 Android，原因是主執行緒阻塞——完全不是圖片的問題。這個失誤教會我：先問問題，才知道你需要哪一種資料組合。—— 陳柏翰
| 想判斷的問題 | 優先資料組合 | 下一個可驗證動作 |
|---|---|---|
| 為何指定流程載入較晚？ | Lab trace／waterfall + 部署紀錄 | 拆開 TTFB、資源、主執行緒與 render delay，再測一個因素。 |
| 修復是否影響真實使用者？ | Field／RUM + 同條件 Lab | 確認版本與觀察期間，再分裝置、頁面或流程比對。 |
| 為何只有某地區或某次發版異常？ | RUM／日誌 + edge／origin／版本時間線 | 先確認資料切片與交付路徑，不把相關時間點直接當成因果。 |
| 哪個改動值得優先做？ | 受影響範圍 + 可重現測試 + 變更風險 | 寫明預期訊號、回退方式與需要哪一種資料驗證。 |
量測必備欄位
來源、日期、URL／流程、裝置、網路、版本與 cache 條件。
比較前先確認
兩次測量是否真的在同一條件下？若不同，要把差異寫出來。
結果如何發布
帶著原始輸出與限制；沒有 evidence pack 時只作教學，不稱 benchmark。
Correction and freshness
資料失效時，不讓舊輸出繼續支撐新結論。
版本、設備、資料期間或交付路徑改變時，舊 run 必須標出適用範圍；若無法比對條件，結論回退為待驗證，而不是被新敘述覆蓋。
Preflight
比較前的四個問題
資料描述的是誰？時間是什麼？環境是否一致？這份輸出究竟能否推翻目前的假設？四項有一項不明，先補資料而不是挑結論。
工具名稱相同，結果就可比較嗎？
不一定。仍需確認版本、URL／流程、裝置、網路、cache、地點與執行日期；同一工具可以在不同條件下回答不同問題。
沒有一種工具能同時回答機制與真實使用者嗎？
不同資料各有角色。若問題同時要求機制與使用者範圍，應明示需要配對資料，而不是把任一輸出延伸到它不能證明的地方。
客戶說「Lighthouse 說 90 分，為什麼還要做優化？」怎麼回？
這是我最常被問到的問題。我的回答是：「那個 90 分是在一台模擬的高階設備、快速 WiFi、已暖 cache 的條件下測出來的。你的用戶不住在那個條件裡。」然後我會打開他們站的 CrUX 數據，讓他們看真實用戶的 P75 LCP——通常那個數字很不一樣。Lighthouse 是診斷工具，不是用戶體驗報告。分數高不等於真實用戶滿意。