TTFB 優化怎麼做？從 PageSpeed 警告到伺服器回應速度修復

PageSpeed Insights 跑出「減少初始伺服器回應時間」的警告，TTFB 顯示 2.4 秒。很多人看到這行，第一個反應是升級主機方案，每個月多花幾千塊。等主機換完，TTFB 降到 1.9 秒，但 Google 建議的目標是 0.8 秒以下，問題還是在。這是因為主機速度只是 TTFB 的其中一個因素，而不是全部。TTFB 的等待時間可能分散在 DNS 查詢、TCP 連線、TLS 握手、伺服器處理或重導向鏈的任何一段，換主機只能解決其中一類問題。本文從 TTFB 的構成拆解開始，帶你用 PSI、DevTools、WebPageTest 找出真正的卡點，再對症下藥。

TTFB 紅燈怎麼看：從 PageSpeed Insights 警告定位問題根源

在 PageSpeed Insights 報告中，「伺服器回應時間長」這項診斷直接指向 TTFB 問題。點擊展開後，你會看到「減少伺服器回應時間 (TTFB)」的建議，這就是修復的起點。下一步不是亂改，而是要判斷問題在 DNS、伺服器本身，還是傳輸。TTFB 的等待時間由最多五個子階段組成，包括重導向、DNS 查詢、TCP 連線、TLS 握手與伺服器處理，每個階段出現瓶頸時的修復方向都不同。

根源診斷四步法：你的 TTFB 慢在哪個環節？

TTFB = DNS 解析時間 + TCP 連線時間 + 伺服器處理時間 + 首個位元組傳輸時間。你需要用工具拆解這四段，找出佔比最長的「病灶」。常見在台灣環境，問題多出在伺服器處理時間過長，或 DNS 解析指向了距離較遠的伺服器。這不是猜測，而是要靠數據確認，判斷是「Server-side TTFB」問題（伺服器處理慢）還是「Network-side TTFB」問題（傳輸路徑慢）。

先判斷是哪一類 TTFB 問題。如果 Chrome DevTools 的 Waiting 高但 DNS/SSL 正常，優先查伺服器端；如果跨地區測試差距大，先查 CDN 與主機位置。具體來說，Server-side TTFB 的特徵是 PSI 或 DevTools 中的 Waiting 數值很高，但 DNS Lookup 和 Initial Connection 正常，常見原因包括未啟用頁面快取、PHP 版本舊、資料庫查詢慢。Network-side TTFB 則表現為 DNS 很長、Initial Connection 很長，或用 WebPageTest 從不同地點測試時，亞洲地點比美國地點慢非常多，原因可能是主機機房在美國但目標用戶在台灣。

用哪些工具診斷 TTFB？先用 PSI 確認警告，再用 DevTools 查單次請求的 timing 拆解，最後用 WebPageTest 驗證多地區與快取命中差異。在 WebPageTest 設定時，務必在「Testing Location」選擇「Asia (Taiwan)」或類似的亞洲節點，測試結果中的「Connection: Cable」或「4G」代表模擬的用戶網路類型，其下的 TTFB 數據才更接近真實情況。

修復實戰一：主機與伺服器端優化（共享主機 vs VPS/雲主機）

若診斷結果顯示伺服器處理時間（Server Processing Time）過長，表示主機本身回應慢。共享主機受鄰居效應影響最大，解法是升級方案或優化 WordPress 等應用。對於可控制伺服器的 VPS 或雲主機，則需檢查 PHP 版本、資料庫查詢效率與伺服器軟體設定。這是解決 Server-side TTFB 的核心戰場。

修復實戰二：CDN 與全球快取配置

CDN 是降低 TTFB 的最有效手段，尤其對於全球或亞洲訪客。核心是將靜態資源甚至動態內容的快取副本，放在離用戶最近的節點。對台灣訪客而言，選擇有台灣或亞洲節點的 CDN 服務商至關重要。這直接解決了 Network-side TTFB 中的地理延遲問題。

以 Cloudflare 為例，設定不只在於開啟，關鍵在於針對不同類型的資源制定精確的快取規則。進入 Cloudflare 控制台後，首先前往「規則」→「頁面規則」（或較新的「緩存規則」）。為靜態資源（如 `https://yourdomain.com/wp-content/uploads/*`）建立一條規則，將「緩存級別」設為「緩存所有內容」，並設定一個合理的「邊緣緩存 TTL」（例如 1 個月）。接著，為關鍵的動態 HTML 頁面（如首頁、產品頁）建立另一條規則，嘗試設定「緩存級別」為「標準」，並開啟「瀏覽器緩存 TTL」。如果網站使用 WordPress，可考慮啟用 Cloudflare APO（Automatic Platform Optimization），它會自動為 WordPress 站點快取 HTML 頁面。

設定後，如何確認 CDN 是否生效？最直接的方法是使用命令列工具。在終端機輸入 `curl -I https://yourdomain.com/some-page`，查看回應標頭中是否有 `cf-cache-status: HIT` 或 `cf-cache-status: DYNAMIC`。如果是 `HIT`，代表該頁面已從 Cloudflare 的邊緣節點快取返回，TTFB 應大幅降低。如果始終是 `MISS` 或 `DYNAMIC`，則需要檢查你的 Cache Rules 設定是否有排除條款（例如特定 Cookie 或 URL 參數）導致快取被繞過。

修復實戰三：應用層級與快取策略（WordPress 案例）

即使有 CDN 和快速主機，如果每次請求都到原始伺服器執行 PHP 程式碼，TTFB 依然會高。因此必須實施「全頁快取」或「物件快取」，讓伺服器直接返回已生成好的 HTML 或數據，跳過繁重的處理過程。這是將 Server-side TTFB 降至 800ms 以內的關鍵一步。

以 WordPress 為例，三種快取的分工完全不同。頁面快取（Page Cache）將動態頁面結果存為 HTML 檔案在伺服器磁碟，效果最直接，適合所有內容型網站。物件快取（Object Cache）將資料庫查詢結果暫存在記憶體（如 Redis），適合 WooCommerce 或會員站等動態查詢多的網站。HTTP 快取（Cache-Control）則控制瀏覽器和 CDN 的快取行為，主要用於靜態資源。你需要根據網站類型選擇組合：純內容站啟用頁面快取即可；電商站則需頁面快取（排除購物車等頁面）加上 Redis 物件快取。

具體操作上，若主機是 LiteSpeed 架構，安裝 LiteSpeed Cache 外掛並啟用「Page Cache」功能通常效果最佳。若主機使用 Nginx，可能需要設定 FastCGI Cache 或與主機商配合。物件快取的設定需要主機支援 Redis 服務，安裝 Redis Object Cache 後，在 WordPress 的 `wp-config.php` 中添加相關常數來連線。最後，務必透過 WebPageTest 測試修復前後的 TTFB 變化，並檢查快取命中率。

驗證與監控：確認 TTFB 改善並維持

修復後，必須用工具驗證效果，並建立監控機制。不僅要看一次測試結果，更要關注真實用戶在不同時段、地區的 TTFB 表現。這是一個持續的過程，而非一次性的任務。

第一步：使用實驗室數據快速驗證（Lab Data）。在完成優化後，立即回到 PageSpeed Insights，使用「移動裝置」重新測試。重點觀察「Lab Data」中的 TTFB 數值是否已降至 800ms 以下（良好）。同時，在 WebPageTest 中從「Asia (Taiwan)」節點執行測試，確認在模擬的台灣用戶環境下，TTFB 也有明顯改善。這能快速確認你的技術修改（如啟用快取、設定 CDN 規則）是否已生效。

第二步：監控真實用戶數據（Field Data）。實驗室數據是模擬，真實用戶體驗才是最終標準。在 Google Search Console 的「核心 Web Vitals」報告中，查看「手機」與「電腦」版的 TTFB（在 CWV 報告中，TTFB 體現在 LCP 的改善上）。CrUX（Chrome 使用者體驗報告）的資料有 28 天的滾動窗口，因此你需要耐心等待 4 到 6 週，讓足夠的真實台灣用戶數據累積。在此期間，你可以定期使用 PSI 檢查「欄位資料」部分，確認真實用戶的體驗趨勢正在改善。若想深入了解如何解讀這些數據，可參閱Core Web Vitals 欄位資料的詳細說明。

第三步：建立長期監控計畫。建議設定一個定期（如每週）的簡單監控計畫。在固定時間（如週二早上），使用相同的工具設定（例如 WebPageTest from Taiwan，Connection: Cable）記錄主要頁面的 TTFB 數值，並存檔比較。這有助於長期觀察穩定性，並及時發現因主機商調整或網站內容增加而可能回彈的性能問題。對於持續性的重要網站，可考慮使用 UptimeRobot 等工具設定 Uptime 監控，確保伺服器隨時可達。

需要完整的技術 SEO 診斷？免費網站健檢可以幫你找出 TTFB、LCP 與其他技術問題的根本原因。更多關於如何解讀 PageSpeed Insights 資料，可參考PageSpeed Insights 報告解讀。針對 WordPress 站點的深度優化，請查閱WordPress 速度優化完整指南。