TTFB 指標解讀：排查 WordPress 回應慢的原因

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

TTFB 是收到第一個回應位元組前的等待時間；WordPress 回應慢時，先看工具從哪裡開始計時，再判斷要查網路、快取或後端。TTFB 低不代表畫面已經出現，也不能保證網站排名提升。

如果你在 Chrome DevTools 看見很長的 Waiting，先別急著換主機。DNS、連線、伺服器處理與後續圖片下載，是不同的等待階段；把它們分開，才知道下一個調整有沒有對準問題。

TTFB 與 DevTools 的 Waiting，計時起點不同

在 web.dev 的導覽請求定義中，TTFB 從開始導覽網頁算到第一個回應位元組抵達，可能包含轉址、Service Worker 啟動、DNS 查詢、連線及 TLS 協商，再到送出請求與等待回應。因此，TTFB 不是純粹的 PHP 執行時間。

Pin

Chrome DevTools 的 Timing 說明則把 DNS Lookup、Initial connection、Request sent 與 Waiting 分開列出。其中 Waiting（TTFB）包含網路往返延遲與伺服器準備回應的時間。比較兩份報告前，要確認看的是這一小段，還是整次導覽開始後的等待總和。

第一個位元組也不等於主要內容已完成。網站可以先送回標頭或部分 HTML；使用 103 Early Hints 時，工具計算的第一個回應與最終文件回應還可能不同。數字看起來很短時，仍要確認工具定義，以及使用者何時真正看見內容。

800ms 是粗略參考，200ms 不是所有網站的合格線

截至 2026 年 9 月，web.dev 對導覽 TTFB 的粗略建議是 0.8 秒以內良好，超過 1.8 秒不佳。這不是依主機價格分出的保證範圍，也不應拿來直接判定某家主機是否值得買。

TTFB 不是 Core Web Vitals。Google 列出的 Core Web Vitals是 LCP、INP 與 CLS；FCP 也不是其中之一。TTFB 過長可能延後內容開始呈現，但把 TTFB 壓低，並不能保證 LCP 同幅改善。

例如，HTML 很快送到，後面卻還要執行大量 JavaScript 才畫出內容，或主要圖片很晚才被發現與下載，使用者仍會等。反過來，伺服器先完成較多工作、直接送出可呈現的 HTML，也可能在稍高的 TTFB 下有較好的內容呈現體驗。應把 TTFB 與實際畫面一起看。

先固定測試條件，再比較快與慢

Chrome DevTools 適合檢查當次請求：開啟 Network，重新載入頁面，找到目標頁面的 Document 請求，再查看 Timing 與回應標頭。不要只憑「列表第一筆」認定它就是最後的 HTML，因為轉址、保留紀錄與其他請求可能混在一起。

記下測試網址、時間、地點、網路、是否登入，以及是否使用瀏覽器快取。相同條件下重複測幾次，保留一般結果與異常結果；不要用最快的一次代表所有讀者，也不要把登入後的動態頁面拿去對照未登入且命中快取的頁面。

DevTools 的 Disable cache 主要控制瀏覽器端 HTTP 快取，並不會自動停用 CDN 或主機快取。要比較未命中與命中快取的行為，還得看該服務的快取狀態、規則與回應標頭。任意加上查詢參數，也未必會繞過所有快取。

web.dev 的 TTFB 排查指南區分實驗室測量與真實使用者資料。單次測速工具適合重現條件；CrUX 或自行蒐集的真實使用者資料，則能幫助觀察不同網路與地區的分布。兩者不同不一定是工具壞掉，可能是取樣、轉址或快取情境不同。

若看到 0ms，先檢查測量的是哪種請求、快取與資料可見性。Resource Timing 的跨來源資料若缺少適當的 Timing-Allow-Origin，部分欄位可能為 0；這不能直接證明伺服器瞬間完成，也不能直接判定網站故障。

等待集中在哪裡，就先查哪一段

以下順序用來縮小問題範圍，不能取代伺服器紀錄。若尚未確認瓶頸，先保留測量結果，避免同時更換 DNS、主機和多個外掛，最後反而不知道哪個變更有效。

• 轉址、DNS 或連線階段長：查看是否有多餘轉址、解析延遲，或特定地區的連線較慢。比較相同地區的重複結果；換較近的節點可能有幫助，但不是只看地圖距離就能保證。
• Waiting 長，靜態資源也慢：連線、主機負載、CDN 回源或其他共通環節都值得查。先確認是不是經過相同路徑與快取狀態，別立刻歸咎於 WordPress。
• 未快取的 WordPress 頁面特別慢：請主機或開發者檢查 PHP、資料庫查詢、外部 API 等待及資源使用量。Server-Timing 或 APM 可協助區分後端時間，單看外掛數量不夠。
• TTFB 已短，內容仍很晚出現：改查 LCP 元素、CSS、JavaScript 與主要圖片載入順序。繼續追更低的第一個位元組數字，未必是最有用的調整。

比較靜態 HTML 與動態頁面可以提供線索，但兩者 TTFB 的差值不等於 WordPress 或 PHP 花費的精確時間。測試可能經過不同快取、轉址或處理路徑，主機當下負載也會變。要把延遲歸因到特定程式，應補上後端量測。

WordPress 快取有效的前提，是請求真的能共用內容

WordPress 官方效能指南將快取列為改善方向。頁面快取可重用已產生的回應，減少重複組合頁面的工作；實際能省下多少時間，要看命中率、快取層與原本的瓶頸，沒有通用的下降百分比。

要區分頁面快取、物件快取與 OPcache。頁面快取重用輸出；物件快取重用可快取的資料物件；OPcache 減少 PHP 重複編譯的工作。開了其中一個，不代表每次請求都跳過 PHP 與資料庫，也不代表其他層都已啟用。

CDN 同樣要看快取了什麼。Cloudflare 官方文件指出，預設不快取 HTML 與 JSON。因此，把網站接上 CDN，不等於 WordPress 的 HTML 已由邊緣節點直接提供。先確認文件請求的實際快取狀態，再討論全頁快取是否適合。

購物車、結帳、會員與其他個人化頁面，不能直接套用所有訪客共用的快取規則。使用WordPress 快取外掛或主機快取時，先按產品文件確認排除條件，再測試不同帳號與未登入訪客看到的內容；速度變快但顯示錯誤資料，不算優化成功。

若未快取的頁面仍慢，再於測試環境逐一停用疑似外掛或調整程式，配合測量找出影響。PHP 版本也應選仍受支援且與佈景主題、外掛相容的版本。不要為了少一個外掛就直接改動佈景主題檔案，或在正式站一次刪掉多個功能。

一次驗證一個變更，最後看讀者真的有沒有變快

每次調整前保存設定與可還原的備份；涉及 PHP、外掛或快取規則時，先在WordPress 測試環境確認。調整後用原本的網址、登入狀態、地區與網路條件重測，並檢查登入、表單、購物等關鍵流程。若數字惡化或功能出錯，先回復該次變更再查原因。

若 Waiting 沒有改善，不要只因換了較貴的主機或啟用了新服務就認定有效。把結果交給主機支援或開發者，對照當時的錯誤、慢查詢與資源紀錄。需要了解網站整體速度時，可再用網站測速工具查看其他載入階段；GZIP 壓縮主要減少傳輸大小，不能當成後端處理慢的通用解法。

SEO 也要分開驗證。降低 TTFB 不保證排名上升；Google 的抓取預算指南主要針對大型、頻繁變動或大量網址未被抓取的網站，不能從一次測速就推論一般網站的索引量受限。效能、索引狀態與搜尋成效，各自需要對應資料。

先完成一輪可比較的測量，找出最長的等待階段，只調整對應的一件事。驗收時同時看回應時間、內容呈現與功能是否正確，才知道這次改動對讀者有沒有幫助。