Web Performance Evidence Lab
把效能症狀，
變成可驗證的修復實驗。
從 trace 找到瓶頸；用 lab、field 或 RUM 判斷修復是否真的有效。這裡不替你的網址跑隱藏掃描，也不把單次分數包裝成結論。
陳柏翰在 2013 年把一張圖片壓縮後，客戶的手機轉換率隔週跳了 23%。那次之後，他決定每一個效能建議都要有修前和修後的測量數字，而不是預測。
Experiment planner
建立測試計畫
輸入你已量到的資料，取得透明的第一個實驗步驟。所有規則與門檻都在結果中說明。
你的下一步
Transparent decision rules
規劃器只排測試順序，不替資料下判決。
輸入值會決定第一個要保存的證據與測試類型；它不會量測你的網址，也不會把門檻當成 SEO、轉換或營收結論。
Rule 01
資料來源決定下一份證據
只有 Lab 時，先補可重複 trace；只有 Field／RUM 時，先用 Lab 界定機制；兩者都有時，先把兩種資料的問題分開。
Rule 02
症狀決定第一個實驗
載入、互動、layout、伺服器等待各有不同的第一組輸出。未選定症狀時，工具只建立可比較基線，不猜根因。
Rule 03
門檻只做優先標記
LCP、INP、CLS 門檻會在輸出中被標記，方便排程；它們不是網站健康分數，也不表示所有使用者都受到同一影響。
Method
一個修復，要經過四個可回查步驟
01
記錄基線
記下資料來源、裝置、網路、頁面版本與觀測日期。
02
讀 trace
確認是資源、主執行緒、layout 還是伺服器等待造成瓶頸。
03
控制變數
一次只改變一個可以說明的因素，保留回退方式。
04
交叉驗證
Lab 用來定位；Field／RUM 用來檢驗真實使用情況。
Scenario split
同樣是「慢」，第一個可驗證路徑可能完全不同。
Lab only
固定條件下 LCP 偏高
先取：LCP element、waterfall、TTFB、render delay 與同版本 trace。
先不說：所有真實使用者都很慢。
Field or RUM only
真實使用者的互動變差
先取：裝置／頁面／時間切片與慢互動樣本，再補可重複的互動 trace。
先不說：bundle 大小就是唯一原因。
Conflicting signals
Lab 好看，Field 卻沒有改善
先查：版本、cache、裝置、地區、流量組成與測量期間。
先不說：修復失敗或任一資料來源不可信。
Evidence policy
沒有 evidence pack，就不是可比較的 benchmark。
任何公開比較都應能回查測試版本、環境、樣本數、原始結果與限制。未具備這些資料時，頁面只做方法教學，不稱為實測結論。陳柏翰見過太多「Lighthouse 桌面版 90 分」的網站，真實使用者資料卻沒有任何改善——他把這種現象稱為「效能劇場」：為測試條件優化，不是為真實使用者優化。這個政策存在，就是為了讓這裡的每一份比較都能逃脫那個陷阱。
Publish
可以比較
樣本、版本、環境、原始 run、比較方式與限制都能被讀者回查。
Working note
只能當工作紀錄
已有觀察或 trace，但缺少可重建條件、資料範圍，或還有未排除的干擾。
Hold
不要發布結論
資料彼此衝突、樣本無法識別，或一次測試被寫成普遍結果時，先回到測試設計。
Focused FAQ
測試計畫常見的三個誤用
門檻被標記，是否代表一定要立刻改？
不是。門檻只把需要進一步觀察的訊號排到前面；優先順序仍要看受影響範圍、可重現性、使用者情境與變更風險。
為什麼 Lab 和 Field／RUM 可能給出不同答案？
它們描述的條件不同。Lab 適合定位機制；Field／RUM 描述一段時間內的真實使用者分布。差異需要被解釋，而不是被平均成一個分數。
修復後何時可以稱為有效？
先確認指定條件下的測試輸出改變，再依資料來源觀察實際環境。任何結論都要同時保留未量到的裝置、地區與期間限制。
Experiment records
實驗紀錄
文章是方法與證據的延伸，不取代首頁的測試規劃。只有 server-only CMS 憑證可用時，才顯示最近發佈紀錄。
cls-optimization
SPA 路由切換 CLS 修復：從 0.38 到 0.05 的實驗報告
深入探討單頁應用程式（SPA）路由切換時引發 CLS 的根本原因，並提供 React、Vue、Next.js 等框架的具體修復方案、Chrome DevTools 監測技巧與實驗數據對比。解決你的頁面跳動問題。
2026-08-20 →
wordpress-performance
WordPress 網站 LCP 達標失敗？帶你從後台查到伺服器的完整診斷路徑
WordPress 網站 LCP 超標？本指南提供從後台工具到伺服器配置的完整診斷步驟，帶你找出是哪個插件、主題或圖片設定拖慢了載入速度，並給出可立即執行的修復優先路徑。
2026-08-18 →
cache-cdn
Cache-Control 指令與 CDN 快取命中率：從 max-age 到 s-maxage 的完整指南
深入解析 Cache-Control 標頭（s-maxage、max-age、public 等）如何影響 CDN 快取命中率。
2026-08-11 →
Lab Engineer
陳柏翰
效能工程師 / Web Performance Lab
陳柏翰畢業於中興大學資工所，畢業後在新創公司做前端，2013 年遇到一個轉折點：一張未優化的 hero image 讓某支手機頁面的 LCP 停在六秒。他花了一個下午壓縮並設定正確的載入優先順序，客戶的手機轉換率隔週成長了 23%。那次讓他從「開發者」變成「效能工程師」——他意識到效能數字和商業結果之間有直接且可測量的連結。
2018 年他建立了一套私有的 Core Web Vitals 監測儀表板，那時 Google 還沒有正式宣布 CWV 將成為排名因素（那是 2021 年的事）。他用那套儀表板追蹤了三年，建立了修前/修後比對的系統性方法論。
他用「效能劇場」這個詞描述一種常見現象：Lighthouse 桌面分數 90 分以上，但真實使用者資料毫無改善——因為優化對象是測試條件，不是真實使用者。SpeedPark 是他把這套方法論公開化的地方。
「小糠（Koinoura）」來自日文，意指細小的糠——他在研究日本網頁效能文獻時找到這個詞，用來比喻那些微小但會累積成效的優化動作。