Source entity

陳柏翰與
SpeedPark 效能實驗室。

網站效能不是「感覺快一點」的問題。它是有條件、有量測、有可重現結果的工程問題。SpeedPark 從 2020 年開始公開記錄這個過程：先寫下條件，再讀 trace，最後用資料來源驗證每一個結論。

陳柏翰

網站效能工程師 · SpeedPark 創辦人

Who is writing this

2013 年的一張 DevTools waterfall，改變了我看待前端工作的方式。

我 2011 年從中興大學資工系畢業，第一份工作是在新創公司做 React 前端。那時候我就發現自己寫出來的 app 常常「跑起來很慢」，但說不清楚慢在哪裡。直到 2013 年，一個客戶打來說他們的手機網站很慢，我才第一次認真打開 Chrome DevTools。waterfall 一拉開，問題顯而易見：一張沒有壓縮過的首屏圖片，在 3G 網路下造成了 6 秒的 LCP。那個下午我把圖片格式換掉、加上尺寸限制，重新測了幾次確認數字穩定。一週後客戶回報行動版轉換率成長了 23%。那是我第一次理解到：效能問題有可量測的原因，也有可量測的結果。

先量測，再建議

這是我在數位代理商做了六年之後留下來的唯一鐵律。我曾花兩週測試 font-display: swap 對特定客戶的影響，結果 LCP 改善了，CLS 卻變差了。那種細節不量測就不會知道。

單一變數

每次實驗只改一件事，並明確記錄沒有改動的條件。沒有這個前提，所謂的「優化效果」只是巧合。

Lab 數據≠真實用戶

Lighthouse 桌面版 90 分的網站，RUM 數據可能慘不忍睹。我把這叫做「效能劇場」——最常發生在測試條件和真實用戶環境差距最大的時候。

Career record

從 Lighthouse 35 分到 87 分，這段路我走了幾百次。

2014 年到 2019 年，我在一家中型數位代理商擔任網站效能工程師。那六年我做的事非常單一：接手客戶網站，找出效能瓶頸，把 Lighthouse 分數從 30–40 分拉到 85 分以上。我替自己立了一個規矩：每一次優化都要記錄改了什麼、改之前的數字、改之後的數字、花了多少時間。這份筆記累積到 2018 年，變成了一個內部儀表板，追蹤我手上所有客戶的 Core Web Vitals 指標——那時 Google 連 CWV 這個名字都還沒公開。2020 年 Google 宣佈 Page Experience 更新時，我已經用那套框架跑了兩年資料。

Input

可識別的症狀

URL、使用者回報的行為、DevTools trace、waterfall 截圖、裝置類型、網路條件與 Chrome 版本。

Hypothesis

可被資料推翻的機制

從 trace 和 Field RUM 提出假設，要求假設有明確的反例條件——如果量測結果是 X，就代表這個假設是錯的。

Output

單次可回退的變更

一次只動一個變數，記錄預期的觀察方向，寫下回退步驟，以及下一個需要量測的資料點。

Boundary

不擴張結論範圍

同一次 run 的結論不套用在不同框架、地區、裝置或流量組成的情境。一個 case 就是一個 case。

What SpeedPark covers

SpeedPark 能拆解什麼，哪些問題必須交給別人判斷。

可以先拆解

LCP、CLS、INP、TTFB、FCP、資源載入順序、主執行緒阻塞、渲染路徑與 Lab／Field 數據落差。這些問題有明確的量測方法和可操作的修正方向。

需要產品與工程共同判斷

功能取捨、第三方腳本的商業必要性、發版風險與可靠性。效能數字只是輸入，不能替代這些決策。

需要其他資料才能判斷

SEO 排名成效、轉換率、使用者滿意度與商業結果。沒有配套的研究設計，我不會用效能指標去代替這些答案。

Correction policy

數字更新時，一起更新推論，不是只換掉數字。

如果新的 run、版本資訊或 RUM 資料推翻了已公開的判讀，更新說明會寫清楚：哪個主張受到影響、測試條件是什麼、還有哪些干擾因素尚未排除。資料不夠充分的時候，結論回退為工作假設，不硬撐成結論。

Self-check before publishing

測試條件和原始輸出能不能重建？
資料有沒有支撐頁面上說的每一句話？
有沒有把 Lab 數據和 Field／RUM 混在同一個結論裡？
反例和限制有沒有留在可見的內容裡？

FAQ

幾個常被問到的問題

為什麼你這麼在意 Lab 數據和 Field 數據的差距？

因為 Lighthouse 是在受控環境下跑的，而你的用戶不住在受控環境裡。我見過太多網站在 Lighthouse 桌面版拿到 92 分，但 CrUX 的 LCP P75 超過 4 秒。分數好看不代表用戶體驗好——這個落差才是問題所在。我把這種情況叫做「效能劇場」，SpeedPark 有不少文章專門在記錄和拆解它。

你說「先量測再建議」，那如果量測結果和直覺相反怎麼辦？

那就跟著資料走，不是跟著直覺走。我有一次花了兩週測試 font-display: swap 對一個特定客戶的影響。結果 LCP 確實變好了，但 CLS 變差了，原因是換字時的佈局位移比預期更明顯。最後的建議是：這個設定在這個情境下不適合，原因是 X，如果要改善字體載入可以考慮改用預載入策略。這就是為什麼每個建議都要附條件。

SpeedPark 的文章能保證改善之後 SEO 排名就會上升嗎？

不能。Core Web Vitals 是 Google 排名訊號之一，但排名是多因素的結果。SpeedPark 記錄的是效能指標在特定條件下的變化，以及合理的改善方向。如果你的目標是排名，效能只是其中一塊，需要搭配內容品質、連結訊號和其他因素一起看。

陳柏翰與SpeedPark 效能實驗室。