網站優化前後怎麼測速？網站效能對比測試方法詳解
網站優化後怎麼測速才準確？本文詳解網站效能對比測試的正確方法。教你如何排除快取與網路波動干擾，控制測試節點與環境變數，透過對比 DNS、TCP、TTFB 及 Core Web Vitals 等關鍵指標，精準評估後端伺服器、CDN 及前端優化的真實效果。
網站做完優化以後，很多人的第一反應都是重新打開頁面，看看速度有沒有變快。如果感覺比之前順暢一些，或者測速工具裡的分數提高了，就會認為這次優化有效。但實際做網站效能排查時，這種判斷並不可靠。
網路本身會波動，本地瀏覽器可能已經快取了圖片和指令碼，不同地區、不同電信業者的存取線路也不一樣。比如優化前是在上海電信環境下測試，優化後換成廣州移動；第一次測試沒有快取，第二次瀏覽器已經載入過頁面，這樣即使數據發生變化，也很難判斷到底是網站優化起了作用，還是測試條件變了。
所以網站優化前後測速，真正重要的不是「分別測一次」，而是盡量保證測試環境一致，再對比 DNS、TCP、TLS、TTFB、頁面載入時間、資源大小以及 Core Web Vitals 等數據。只有前後測試具有可比性，最終得到的優化結論才有參考價值。
一、網站優化前後測速，為什麼一定要保證條件一致？
網站效能數據很容易受到外部環境影響：同一個網站，在不同時間測試，結果可能差幾百毫秒；同一個頁面，北京電信存取和廣州移動存取的延遲也可能完全不同。如果前後兩次測試條件變化太大，那麼最後得到的數據其實沒有太多比較意義。
例如：
優化前
上海電信
桌面端
無快取
上午 10 點測試
優化後
廣州移動
行動端
已有快取
晚上 8 點測試即使優化後的載入時間從 3 秒降到 2 秒，也不能直接說明優化帶來了 1 秒提升，因為節點、網路、裝置和快取條件全部發生了變化。
更合理的做法，是盡量固定以下條件：
測試條件 | 優化前 | 優化後 |
|---|---|---|
測試 URL | 相同 | 相同 |
測試地區 | 相同 | 相同 |
電信業者 | 相同 | 相同 |
裝置類型 | 相同 | 相同 |
快取狀態 | 相同 | 相同 |
測試次數 | 多次 | 多次 |
頁面版本 | 記錄目前版本 | 對比優化版本 |
如果使用線上測速工具，前後最好選擇相同節點；如果是瀏覽器本地測試，也要盡量保持網路環境一致，並明確這次測的是首次存取還是快取後的重複存取。網站優化前後對比，測試環境越穩定，數據越有價值。
二、優化之前應該先記錄哪些數據？
網站優化之前最好先做一組基準測試，也就是先記錄網站目前的真實表現。沒有這組數據，後面即使網站感覺變快了，也很難說清楚具體快在哪裡。一般不需要把所有效能指標都記錄下來，先關注幾個對實際存取影響比較大的數據就夠了。
首先是 DNS 解析時間。DNS 發生在網站建立連線之前，如果網站剛更換 DNS、CDN 或者解析服務，可以觀察這一階段有沒有變化。
接下來是 TCP 和 TLS。TCP 連線時間能夠反映網路線路和伺服器距離，TLS 則和 HTTPS 建連有關。對於跨地區、跨境或者剛接入 CDN 的網站，這兩項通常比較有參考價值。
TTFB 也很重要。
如果這次優化涉及伺服器、資料庫、PHP、頁面快取、CDN 回源或者動態介面，TTFB 往往是最容易發生變化的指標之一。
除此之外，還可以記錄：
頁面載入時間
請求數量
頁面總大小
LCP
INP
CLS例如優化前記錄：
TTFB：620 ms
頁面載入：3.8 s
請求數量：126
頁面大小：4.6 MB
LCP：3.1 s這些數據後面就可以直接作為對比基準。
三、網站優化前後應該怎麼測速？
真正做對比時，我更建議按照「先測基準，再優化，再用同樣條件複測」的順序來做，而不是先把網站改完，再回頭找以前的數據。
優化前可以先使用固定 URL 做多次測試。
如果網站主要面向國內使用者，可以透過 Chahu 的網站測速查看不同地區和電信業者的存取表現，如果想繼續觀察網路延遲，也可以結合 Chahu 的線上 Ping進行測試。
第一次測試時不要只保存一個「總載入時間」，最好把 DNS、連線時間、TTFB、頁面載入以及不同地區結果一起記錄下來。
例如同一個節點連續測試五次：
1.82 s
1.76 s
1.91 s
1.79 s
1.84 s這種情況下，比起只拿最快的 1.76 秒，更適合看中位數或者整體區間。這樣可以盡量減少單次網路波動對結果的影響。完成基準測試以後，再進行網站優化。
比如：
啟用 CDN
開啟頁面快取
壓縮圖片
合併或減少 JS
啟用 Brotli
優化資料庫
升級伺服器
調整 DNS優化完成後，再使用原來的 URL、相同節點和相同測試條件重新測試。如果優化前使用北京電信節點、桌面端、無快取、連續測試五次，那麼優化後也盡量保持一致。這樣前後兩組數據才真正具有對比意義。
四、網站優化前後重點應該看哪些指標？
不同類型的優化，需要關注的指標並不完全一樣。
比如一組完整的前後數據可能是：
指標 | 優化前 | 優化後 | 變化 |
|---|---|---|---|
DNS | 48 ms | 22 ms | -54% |
TCP | 105 ms | 42 ms | -60% |
TLS | 148 ms | 68 ms | -54% |
TTFB | 620 ms | 210 ms | -66% |
頁面載入時間 | 3.8 s | 1.9 s | -50% |
請求數量 | 126 | 82 | -35% |
頁面大小 | 4.6 MB | 2.7 MB | -41% |
從這種表裡就能比較直觀地看出，效能提升到底發生在哪個階段。
如果優化的是伺服器或者後端，重點可以看：
TTFB
伺服器回應時間
動態介面回應如果優化的是 CDN，更適合觀察：
RTT
TCP
TLS
TTFB
快取 HIT
不同地區節點表現如果做的是前端優化，可以重點看：
頁面大小
請求數量
LCP
頁面載入時間如果只是壓縮圖片，則應該重點看資源大小、下載時間以及 LCP 有沒有改善。
網站效能優化並不是所有項目都只盯著一個「載入用了幾秒」。優化目標不同，對應的判斷指標也應該不同。
五、為什麼網站優化後測速反而變慢？
這種情況其實很常見。有時候剛做完優化，重新測試後反而發現頁面慢了幾百毫秒，並不代表這次優化一定失敗。
首先要檢查前後測試節點有沒有變化。
比如優化前使用上海電信，優化後使用廣州移動，本身就可能出現幾十甚至上百毫秒差異。
瀏覽器快取狀態也會影響結果。
第一次存取時需要重新下載資源，後續存取則可能直接讀取瀏覽器快取。如果前後兩次快取狀態不同，最終載入時間自然不能直接比較。
CDN 場景下還要考慮快取是否已經建立。
剛剛切換 CDN 或重新整理快取以後，第一次存取某個節點時可能出現 MISS，需要回源取得資源。等快取建立以後，後面的請求才會真正體現邊緣快取效果。
DNS 也一樣：剛修改 DNS 或 CNAME 後，不同地區遞迴 DNS 的快取更新時間可能不同，短時間內前後結果出現波動很正常。
另外還要留意第三方資源，比如：統計程式碼、廣告、線上客服、地圖、第三方字型、影片、第三方 JS 等等，這些資源不由自己的網站完全控制，如果某一次測速時第三方服務回應變慢，也會拖高頁面整體載入時間。所以網站優化前後最好不要只看一次結果。一次測試變慢，不能直接等於優化失敗；更有參考價值的是多次測試以後看整體趨勢。
六、不要只看「總載入時間」
網站優化前後對比時，最容易出現的迷思就是只看一個數字。
例如：
優化前：3.2 秒
優化後：2.4 秒這個結果當然說明頁面整體快了一些，但它並不能告訴你到底哪裡發生了變化。
如果進一步拆開：
優化前
DNS：20 ms
TTFB：850 ms
頁面載入：3.5 s
優化後
DNS：21 ms
TTFB：220 ms
頁面載入：2.3 s這裡很明顯，DNS 基本上沒有變化，真正提升的是伺服器回應。
如果數據變成：
優化前
TTFB：180 ms
頁面大小：5.2 MB
載入時間：4.1 s
優化後
TTFB：175 ms
頁面大小：2.8 MB
載入時間：2.0 s那就說明伺服器速度幾乎沒變化，主要效能提升來自圖片、CSS、JS 等前端資源優化。
再比如：
優化前
TCP：130 ms
TLS：190 ms
TTFB：350 ms
優化後
TCP：42 ms
TLS：65 ms
TTFB：140 ms如果這次剛好是接入 CDN，那麼優化效果很可能主要來自使用者距離邊緣節點更近，以及網路連線鏈路縮短。這也是為什麼網站優化前後測速時，最好把存取鏈路拆開來看，而不是只看最後一個「總時間」。
結語
網站優化前後測速，真正重要的不是優化以後分數提高了多少，而是能不能在相同條件下確認哪些指標確實發生了變化。如果前後使用不同節點、不同裝置或者不同快取狀態，即使數字看起來差距很大，結果也未必具有參考意義。更穩妥的做法，是在優化之前先保存一組基準數據，再使用相同 URL、相同地區和相同測試方式完成複測。
測試時可以把 DNS、TCP、TLS、TTFB、頁面載入時間、資源大小和 Core Web Vitals 放在一起看，再根據這次優化的目標判斷哪些數據最值得關注。這樣不僅能知道「網站有沒有變快」，還可以繼續判斷這次效能提升到底來自伺服器、CDN、快取、網路線路，還是前端資源優化。對於長期營運的網站來說，這種可重複、可對比的測速方式，也比單純憑感覺判斷「頁面好像更快了」更有實際價值。
相關問答
1. 動態渲染網站（如 React/Vue SSR）和靜態網頁（HTML）在測速指標上有何本質區別？
靜態 HTML 頁面由於不涉及複雜的伺服器端邏輯計算，其 TTFB 通常極短，效能瓶頸主要集中在 CDN 傳輸和前端資源體積上。而 SSR（伺服器端渲染）網站的 TTFB 包含了資料庫查詢、模板拼接和 API 介面呼叫的時間，因此 TTFB 波動通常較大。此外，SSR 頁面即便 HTML 渲染極快（LCP 表現優異），在客戶端 JavaScript 完成 Hydration（水合）之前，頁面仍然無法回應互動，需要格外關注 INP（Interaction to Next Paint）指標。
2. 在做全球多節點測速時，測試節點的網路頻寬會影響延遲數據嗎？
會。測速節點本身的出口頻寬和並行處理能力直接決定了下載大體積資源時的吞吐上限。如果測速服務商使用的邊緣節點頻寬較窄（例如限制為 10 Mbps），在下載幾兆大小的圖片或 JS 包時，耗時就會被人為拉長，導致頁面完成載入（Fully Loaded）指標失真。因此，在評估跨國網路效能時，應優先參考 Ping、RTT 和 TTFB 等受頻寬干擾較小的指標，或選用具備獨享高頻寬測試節點的專業工具。
3. 為什麼網站在做完圖片 WebP 格式轉換後，LCP 指標並沒有明顯提升？
圖片體積變小並不等同於 LCP 渲染變快。影響 LCP 的關鍵因素除了檔案大小外，還有 載入優先級 和 渲染阻塞。如果 WebP 圖片被設定了 loading="lazy"（懶載入），或者排在大量的渲染阻塞 CSS/JS 腳本之後載入，瀏覽器依然無法提前預載該資源。要真正改善 LCP，需要在壓縮體積的同時，對首屏關鍵圖片使用<link rel="preload">進行預載，並取消首屏圖片的懶載入屬性。
4. 大流量網站在進行效能評估時，單點並行測試和壓力測試應該如何配合？
單節點測速（如 Lighthouse/WebPageTest）主要針對的是「單次請求的渲染與傳輸鏈優化」，適用於前端資源和 CDN 配置排查；而壓力測試（如 k6、JMeter）模擬的是「多使用者並行存取下伺服器的吞吐與回應能力」。如果在低並行下網站速度很快，但在線人數上升後 TTFB 劇增甚至出現 504 報錯，說明瓶頸在於後端的資料庫連線池、CPU 瓶頸或 PHP-FPM 行程數限制。效能評估必須將兩者結合：先透過壓測找出伺服器承載極限，再在穩定負載下進行前端效能測速。