TTFB 優化實戰：六階段診斷與 Server Timing 完全指南

第一階段：搞懂 TTFB，它到底量測什麼？

第二階段：診斷你的 TTFB，瓶頸在哪裡？

使用 Chrome 開發者工具的 Network 面板，觀察頁面載入瀑布圖（Waterfall）中每個請求的時間組成。點選任一請求，查看「Timing」分頁，這裡會清楚列出 TTFB（在舊版瀏覽器或特定設定下可能標示為「Waiting for server response」）的時間。如果 TTFB 數值很長，進一步觀察其前方的細項：如果「DNS Lookup」或「Initial connection」佔比很高，表示瓶頸在第一階段的網絡解析或連線建立，問題可能出在 DNS 伺服器速度、伺服器地理位置過遠或網絡路由不佳。如果「DNS Lookup」和「Initial connection」都很快，但「TTFB」或「Waiting」本身時間很長，這直接指向伺服器處理延遲，應用程式代碼、資料庫查詢或伺服器配置需要優化。這個初步定位是有效優化的第一步，詳細的工具使用教學可參考Chrome DevTools 效能面板深度解析。

第三階段：基礎網絡優化，壓縮不必要的延遲

針對網絡傳輸延遲，最有效的手段是縮短用戶與伺服器之間的網絡距離。使用內容遞送網絡（CDN）是核心策略。CDN 將你的靜態資源甚至部分 HTML 快取至全球邊緣節點，讓用戶從最近的節點獲取內容，大幅減少 TCP 和 TLS 連線所需的往返時間（RTT）。對於主要面向台灣訪客的網站，選擇在台灣或鄰近地區（如香港、新加坡）有邊緣節點的 CDN 服務商至關重要。此外，確保伺服器支援 HTTP/2 或 HTTP/3（QUIC）協議。這些現代協議透過多工傳輸（Multiplexing）和減少連線建立的阻塞，能更有效地利用網絡連接，尤其在 TLS 協商階段能節省時間。這些基礎網絡層面的優化，是降低 TTFB 中「網絡部分」的基石，更多 CDN 細節可參閱CDN 優化 LCP 的機制與實測。

第四階段：Server Timing 深度分析，看穿伺服器內部

當診斷指向伺服器處理時間過長，我們就需要打開伺服器內部的黑盒子。Server Timing API 正是為此而生。它允許伺服器在 HTTP 回應標頭（Header）中，精確標示出處理請求時各個內部步驟的耗時，例如資料庫查詢時間、快取命中時間、模板渲染時間等。瀏覽器接收後，會在 DevTools 的 Network 面板中呈現這些自訂指標。實作上，你需要在後端程式碼（如 PHP、Node.js、Python）中，使用計時函數記錄關鍵操作的耗時，然後將結果透過「Server-Timing」標頭回傳。例如，一個簡單的 PHP 實作可以是：$db_time = round(($db_end_time - $db_start_time) * 1000); header("Server-Timing: db;dur={$db_time};desc=\"資料庫查詢\"");。這讓你能將模糊的「伺服器慢 800ms」具體化為「資料庫查詢佔 700ms、PHP 模板渲染佔 80ms」，從而精準打擊瓶頸。MDN 的Server-Timing 標頭文件有詳細規格。

第五階段：WordPress 實戰案例：從 2.5 秒壓到 0.8 秒

讓我們以一個典型的台灣中小企業 WordPress 電商網站為例。該網站反映其 LCP 在 3.5 秒左右，PageSpeed Insights 報告顯示其 TTFB 高達 2.5 秒。透過六階段診斷流程：首先，使用 WebPageTest 從台北節點測試，發現 TTFB 的「Waiting」時間極長，確認問題核心在伺服器處理。接著，在 WordPress 後端加入 Server-Timing 標頭，測得單一商品頁面的 SQL 查詢總耗時高達 1200 毫秒，且未使用物件快取。優化措施分三步：1. 使用 Query Monitor 和 MySQL 慢查詢日誌，找出並優化了幾個未加索引的查詢，並將一個 N+1 查詢問題改為批量查詢。2. 安裝 Redis 並整合 WP Object Cache，將頻繁查詢的產品分類、庫存數據納入快取。3. 啟用頁面快取插件（如 WP Super Cache），對非會員的產品列表頁實施全頁快取。優化後，同一頁面在相同測試環境下，Server-Timing 顯示資料庫查詢時間降至 150 毫秒，整體伺服器回應時間降至約 150 毫秒（因有頁面快取，部分頁面從邊緣節點回傳），總 TTFB 壓縮到 0.8 秒以內。更多框架相關的優化，可參考WordPress 效能優化實戰。

第六階段：持續監控與進階技巧

TTFB 優化並非一次性工作。你需要持續監控真實用戶的 TTFB 分佈，以評估優化效果並捕捉回歸。使用 Google Analytics 4 的「網站體驗」報告或第三方 Real User Monitoring（RUM）工具，可以觀察不同地區、設備和瀏覽器下的 TTFB 表現。同時，定期使用 PageSpeed Insights 查看 CrUX 報告中的 75 百分位 TTFB 數據，因為這是 Google 評估排名時使用的現場數據。在進階技巧方面，可以考慮使用 Early Hints（HTTP 103 狀態碼）。在伺服器產生最終 HTML 回應前，先傳送一個包含關鍵資源（如 LCP 圖片）Link: rel=preload 的 103 回應，讓瀏覽器能提前開始連接和預載入，從而重疊網絡與伺服器處理時間。此外，結合 Preload 和 Preconnect 提示，管理好關鍵資源的優先順序。關於場景數據的深入解讀，如何查詢與解讀 CrUX 數據一文提供了實用方法。

我該優先使用哪個工具來測量 TTFB？

建議結合實驗室工具與現場數據。先用 PageSpeed Insights 查看基於 CrUX 的真實用戶 TTFB（75 百分位），這代表你的網站整體表現。若數值不理想，再使用 WebPageTest 或 Chrome DevTools Network 面板在受控環境下進行診斷，分析是網絡延遲還是伺服器處理問題。WebPageTest 允許你選擇測試節點（如台灣），更貼近目標用戶情境。

我的伺服器在台灣，TTFB 一定要低於 50ms 嗎？

不一定。50ms 通常是同機房內靜態頁面的理想值。Google 定義的「良好」TTFB 是 ≤800ms（基於真實用戶的 75 百分位）。對於動態網站，伺服器處理需要時間，300ms-500ms 在台灣本地環境已屬合理範圍。關鍵是設定一個基於自身技術棧（如 WordPress + MySQL）的實際目標，並透過 Server-Timing 不斷識別瓶頸進行優化。

如果 TTFB 很高，是不是加了 CDN 就能解決？

不完全是。CDN 主要解決 TTFB 中「網絡傳輸延遲」的部分（如 TCP/TLS 連線時間），對於「伺服器處理時間」的延遲無能為力。如果你的 TTFB 瓶頸主要在資料庫查詢慢或 PHP 執行效率低，CDN 只能帶來有限改善。正確的流程是先診斷瓶頸階段：若網絡延遲是主因，CDN 效果顯著；若伺服器處理是主因，則需優化後端代碼、資料庫或加入快取層。

WordPress 網站優化 TTFB，最該先做哪幾件事？

依優先順序建議：1. 加入頁面快取：這是對動態生成的 WordPress 頁面降 TTFB 最直接有效的方法，可將伺服器處理時間從數百毫秒降至幾十毫秒。2. 使用物件快取（如 Redis）：緩存頻繁執行的資料庫查詢結果，減輕資料庫壓力。3. 檢查與優化外掛：移除不用的外掛，對必要外掛檢查其效能影響。4. 審查主機與 PHP 版本：確保使用較新的 PHP 版本（如 8.0+）並選擇性能足夠的主機方案。這些步驟完成後，再使用 Server-Timing 針對個別慢查詢進行深度優化。

優化 TTFB 之後，如何驗證對 LCP 的實際幫助？

優化後，繼續監控 LCP 的變化。使用 PageSpeed Insights 的 CrUX 報告查看真實用戶的 LCP 75 百分位數值是否下降。同時，在實驗室環境（如 Lighthouse）中測試，對比優化前後的 LCP 數值。由於 LCP 受多因素影響（如圖片大小、渲染阻塞資源），TTFB 的改善會為 LCP 創造更多時間預算，但最終 LCP 的提升幅度仍取決於後續步驟（HTML 解析、資源下載、渲染）是否也得到了相應優化。