TTFB 優化實戰——五大根因逐一排查伺服器回應速度

你以為網站慢是圖片太大、JavaScript 太肥，於是壓圖、延遲載入、裝了一輪外掛——結果速度分數還是上不去。問題很可能根本不在前端。如果伺服器要花半秒、甚至一秒才開始吐出第一個位元組，後面你怎麼優化都是在跟一個已經輸在起跑點的數字賽跑。

這個「伺服器多快開始回應」的數字，就是 TTFB（Time to First Byte，首位元組時間），指的是瀏覽器送出請求後，到收到伺服器回傳的第一個位元組為止所經過的時間。Google 在 PageSpeed Insights 裡建議伺服器回應時間控制在 200ms 以內，而它是 LCP（最大內容繪製）的天花板——TTFB 慢半秒，LCP 幾乎不可能補回來。

TTFB 偏高的麻煩在於，它不是單一原因造成的，而是一連串環節任一卡住都會反映在這個數字上。先從怎麼判斷它到底慢在哪一段講起，再一個根因一個根因往下拆，每一刀都告訴你該用哪個工具去查、又該怎麼改。

TTFB 是什麼？為什麼它是 LCP 的天花板

TTFB 量的是一件很單純的事——從瀏覽器發出 HTTP 請求，到它收到伺服器回傳的第一個位元組，中間經過多久。注意它跟整體頁面載入速度不一樣——頁面載入速度涵蓋 HTML、CSS、JavaScript、圖片全部下載渲染完成的總時間，TTFB 只看伺服器「多快能開始回應」，後面的下載快不快不算在內。

一個完整的 TTFB 可以拆成三段：瀏覽器先找到伺服器並連上線（含 DNS 查詢、TCP 連線、TLS 握手），接著伺服器處理請求、產生回應，最後把第一個位元組送回瀏覽器。動態網站的 TTFB 偏高，問題幾乎都出在中間那段——伺服器要跑程式、查資料庫、組好 HTML 才開始回應，這也是為什麼優化 TTFB 的重心在伺服器端，而不是你一直在弄的前端。

說它是 LCP 的天花板，是因為渲染這件事有先後順序。瀏覽器要先收到第一批資料，才能開始解析、下載資源、畫出最大那塊內容。TTFB 就是這條時間軸的起跑線，它往後挪多少，FCP（首次內容繪製）和 LCP 就整段跟著往後挪多少。換句話說，你的 LCP 永遠不可能比 TTFB 快——假設 TTFB 是 800ms，那不管前端怎麼優化，LCP 都不可能低於 0.8 秒。先把這條起跑線往前拉，後面所有努力才有意義。

TTFB 本身不是 Google 直接拿來排名的因子，但它透過 LCP 和 FCP 間接影響 Core Web Vitals，而這些指標確實在排名考量內。它還有個容易被忽略的副作用——爬蟲在有限的抓取預算裡，碰到回應慢的頁面就會少抓幾頁，連帶影響索引量。所以這不只是使用者體驗問題，也是 SEO 的根基。

怎麼測出自己的 TTFB？幾毫秒算慢？

要動手優化前，得先有一個基準數字，而且要知道這個數字落在哪個區間才算需要處理。

最快的測法是用 Chrome 內建的開發者工具。在頁面上按右鍵選「檢查」，切到 Network 標籤頁，重新整理後點第一個請求（通常就是你的網址），在 Timing 區塊裡找到「Waiting for server response」那一欄，那個時間就是 TTFB。這方法零安裝、即時，缺點是只反映你當下這條網路的狀況，不具備全球代表性。

如果想知道世界各地的使用者體驗到的 TTFB，就得用能多點測試的線上工具。KeyCDN 的效能測試工具可以同時從全球十幾個地點量你的 TTFB，WebPageTest 能跑出完整的瀑布流、看清楚每一段花了多久，GTmetrix 裡 TTFB 被標成「wait time」，把滑鼠移到 Waterfall 的網址那列就會跳出來。挑一個順手的，固定用它當基準就好，因為不同工具的量法略有差異，數字不能互相比較。

至於幾毫秒算慢，可以對著這張表抓自己的位置：

Google 的理想目標是 200ms 以內，web.dev 的建議則是整體 TTFB 壓在 800ms 以下算良好。同時也參考一下你用的主機等級——共用主機的合理範圍大概落在 300ms 到 800ms，VPS 或雲端主機大約 100ms 到 300ms，專屬主機或代管型 WordPress 主機可以做到 50ms 到 200ms。先知道自己這台主機「物理上能多快」，後面的目標才設得務實。

第一刀先切，問題出在主機還是 WordPress 自己？

知道 TTFB 慢沒有用，真正能省時間的是先判斷它慢在「主機本身」還是「網站程式」——這兩個方向的修法完全不同，搞錯方向會白忙一場。

有個很簡單的分界測試，做法是在網站根目錄放一個純靜態的 HTML 檔案（裡面隨便寫幾行字就好，重點是它完全不經過 PHP 和資料庫），然後用前面說的線上工具去量這個靜態頁的 TTFB。這個數字代表的是你這台主機「不做任何運算、純粹回應一個檔案」的理論最短時間。

接著拿它跟你 WordPress 動態頁的 TTFB 對照，就能切出問題在哪一邊：

1. 靜態頁本身就慢（超過 200ms）：問題出在主機或網路層——可能是主機效能不夠、機房離讀者太遠、或 DNS 解析太慢。這時候動 WordPress 設定沒用，要往主機方向查。
2. 靜態頁很快、動態頁卻很慢：假設靜態頁量出來 60ms，但 WordPress 頁面是 500ms，那中間這 440ms 就是 WordPress 自己的處理吃掉的——PHP 版本太舊、外掛太多、沒裝快取、或資料庫查詢太慢。問題在程式層面，跟主機沒關係。

切完這一刀，你就知道接下來該往哪幾個根因查。下面五個根因，前兩個偏主機與網路、後三個偏 WordPress 程式層，照你剛剛切出來的方向挑著看。

根因一，主機離讀者太遠，TTFB 先輸在物理距離

如果你的讀者主要在台灣，主機卻擺在美國，那每一次請求都要橫跨整個太平洋，光海底光纖的來回傳輸就要多花一兩百毫秒——這還沒算伺服器處理的時間。網路再快，物理距離造成的延遲是消不掉的。

這也解釋了一個常見的困惑——為什麼自己在公司測很快，全球測速工具卻顯示很慢？因為你本地測的時候，瀏覽器和伺服器可能就在同一個城市，網路延遲極低；而全球工具是從美國、歐洲等地發請求，跨越半個地球本身就會加上一兩百毫秒。一台放在新加坡的主機，新加坡本地量起來 TTFB 很低，到了其他洲就明顯拉高——這純粹是距離問題。

怎麼查：用 KeyCDN 那類能多點測速的工具，看不同地區量出來的 TTFB 落差。如果離主機越近的測試點數字越低、越遠越高，而且差距有一兩百毫秒以上，那很可能就是地理距離在作怪。

怎麼改：選一個離目標讀者近的機房。台灣或亞洲為主的網站，優先挑亞太區資料中心（東京、新加坡是常見選擇），不要因為國外主機便宜就把站放在歐美，那省下的主機費會用使用者的等待時間還回來。換機房聽起來工程浩大，但多數代管商支援搬遷協助，這是 CP 值最高的一刀。

根因二，沒有 CDN 或邊緣快取，動態頁每次都繞回原站

主機位置固定了，但如果你的讀者來自四面八方，總有一群人離主機很遠。這就是 CDN（內容傳遞網路）要解決的事——它在全球各地部署邊緣節點，讓使用者從離自己最近的節點拿到內容，不必每次都連回你那台主機。

不過這裡有個多數人沒搞清楚的細節：一般的 CDN 只加速 CSS、JavaScript、圖片這類靜態資源，對 HTML 頁面的 TTFB 直接幫助有限。因為 HTML 是動態產生的，CDN 預設不會幫你快取，使用者要看頁面內容，請求還是得一路繞回原站，由 PHP 重新跑一遍。所以你裝了 CDN 卻發現 TTFB 沒怎麼降，往往就是這個原因。

真正能把動態頁 TTFB 壓下來的，是邊緣運算（Edge Computing）這一層。它的概念是把運算和快取從原站往外推到邊緣節點——透過全頁面邊緣快取，連 HTML 都能直接快取在離使用者最近的節點，使用者拿到的是邊緣節點上的成品，完全不用回原站、不用等 PHP 重跑；原站只在第一次產生快取、或內容更新時才被碰一次。更進階的服務會提供「邊緣函式」（edge worker），能在節點上攔截請求、即時改寫回應、甚至處理一部分原本要在原站做的邏輯。對主機和讀者分處不同洲的網站來說，這是把動態頁 TTFB 從幾百毫秒拉進百毫秒內最有效的一招。

怎麼查：在開發者工具的 Network 裡看回應標頭，找有沒有命中快取的標記（不同 CDN 的標頭名稱不一，常見的是 cache 命中與否的欄位）。如果你的 HTML 文件請求每次都顯示未命中、每次都回原站，那邊緣快取就沒生效。

怎麼改：第一步先確認 CDN 有沒有開啟針對 HTML 的全頁面快取（很多人只開了靜態資源那層）。這裡還有一個台灣特有的狀況要注意，部分 CDN 的免費或基礎方案在台灣沒有在地節點，請求反而會繞道日本或美國節點再回台灣，這種情況下 TTFB 可能不降反升。設定前先用多點測速工具量一下開啟前後的差異，確認真的有省到再保留。

根因三：PHP 版本舊、外掛太多，伺服器算太久

切到 WordPress 這一側，最先該查的是 PHP。WordPress 是用 PHP 寫的，每次有人開頁面，伺服器都要跑一輪 PHP 才能組出 HTML，而 PHP 不同版本之間的執行效能差很多。根據代管型 WordPress 主機商 Kinsta 的 PHP 基準測試，PHP 8.x 相比 PHP 7.4 的處理速度提升大約 20% 到 30%，其中最大的躍進來自 7.x 升級到 8.0。版本越新，伺服器算同一件事花的時間就越短。

怎麼查 PHP 版本：進 WordPress 後台的「工具」→「網站狀態」→「資訊」，在「伺服器」區塊就能看到目前跑的是哪個 PHP 版本。多數現代主機商的後台都支援一鍵切換。升級前先確認佈景主題和外掛都相容你要升上去的版本，免得換完出現白屏。

第二個藏在這一段的隱形殺手是外掛。每多裝一個啟用中的外掛，頁面載入時就多一份 PHP 處理和資料庫查詢的負擔。尤其是那種每次請求都要跑一輪的外掛——社交分享按鈕、相關文章推薦、即時統計分析——影響特別明顯。裝了三四十個外掛的網站和只裝個位數的網站，TTFB 可以差到兩三倍。

怎麼查外掛影響：可以用查詢監控類的外掛（例如 Query Monitor）看每個頁面實際跑了多少查詢、哪些外掛吃掉最多執行時間。一裝上去就能看到誰是拖油瓶。

怎麼改：把版本拉到目前主機支援的最新穩定 PHP；外掛則逐一檢視「這個功能是不是非外掛不可」，能用佈景主題內建功能或一段簡單程式碼解決的就停用外掛，功能重疊的留一個。精簡到只剩真正需要的，伺服器的運算負擔會立刻輕下來。

根因四，沒裝頁面快取，每次都重跑一輪 PHP

這是對動態網站來說，降 TTFB 最立竿見影的一招。正常情況下，每次有人造訪頁面，WordPress 都要從頭跑一遍：執行 PHP、向資料庫發出十幾到幾十次查詢、把結果套進模板渲染成 HTML。問題是，同一個頁面對每個訪客的內容其實一模一樣，這套運算等於白做了無數次。

頁面快取就是來省掉這個浪費。啟用之後，第一個訪客觸發的渲染結果會被存成靜態 HTML，後面的訪客直接拿到這份成品，完全跳過 PHP 和資料庫。沒裝快取的 WordPress 頁面 TTFB 動不動就 400ms 到 800ms，裝了之後通常能壓到 50ms 到 150ms——這一步的投報率高到沒有理由不做。

怎麼查：用前面切主機與程式那一刀的邏輯反推就好。如果你的靜態頁很快、動態頁很慢，而且還沒裝任何快取外掛，那快取幾乎肯定是你最該先補的洞。

怎麼改：裝一個頁面快取外掛把這層補上（市面上常見的免費選項就能達成基本效果）。如果你的主機支援更底層的伺服器級快取，效果會更好——伺服器級快取在請求還沒進到 PHP 之前就直接攔下來回應，連 PHP 都不必啟動，TTFB 可以壓得更低更穩。能用主機本身提供的快取機制，就比只靠外掛在 PHP 層做更徹底。

根因五，資料庫慢查詢，最隱形的那幾百毫秒

如果前面幾刀都查過了——主機夠近、CDN 開了、PHP 新版、快取也裝了——TTFB 還是降不下來，那問題很可能藏在最深的一層，也就是資料庫。這也是最難自己看出來的一個根因，因為它不像「沒裝快取」那麼一目了然。

問題通常是這樣發生的。某些頁面（特別是無法快取的，像是會員中心、購物車、後台、即時搜尋結果）每次都得真的去查資料庫，而當資料表變得龐大、或某個查詢缺了適當的索引，一句查詢就可能從幾毫秒膨脹到幾百毫秒。在動態頁的整段 TTFB 裡，這種慢查詢往往是最大的那一塊，偏偏它被埋在伺服器內部，從外面量只看得到「總共慢」，看不出慢在哪一句。

怎麼查：這裡有個多數教學沒講清楚、但其實很關鍵的工具——Server-Timing 回應標頭。它讓你的後端程式把「資料庫查詢花了多久」「伺服器端渲染花了多久」這類內部耗時，直接寫進 HTTP 回應標頭裡，再到開發者工具的 Network 時間軸上把這些分段攤開來看。等於把原本黑箱的伺服器內部時間變成可量測的數字，你就能精準指出到底是資料庫、還是渲染、還是磁碟存取在拖。在 WordPress 環境裡，前面提到的 Query Monitor 也能直接列出每個頁面跑了哪些查詢、各自花多久、哪一句最慢。

怎麼改：揪出最慢的那幾句查詢後，常見的解法有幾種。第一，為高頻查詢的欄位補上適當的資料庫索引，這往往是單筆查詢從幾百毫秒掉到個位數毫秒的關鍵。第二，導入物件快取（例如 Redis 或 Memcached），把重複的查詢結果和運算物件存進記憶體，下次直接取用、不再重複查庫，對資料庫吃重的頁面特別有感。第三，定期清理資料庫裡累積的垃圾——過期的暫存資料、文章修訂版本、失效的排程，這些都會默默把資料表撐大、拖慢查詢。把這層整理乾淨，那段最隱形的延遲才會真正消失。

把這幾刀照順序切下去，TTFB 自然會回到該有的位置

TTFB 偏高從來不是「換個更貴的主機」就能解決的單一問題，而是一條從 DNS、機房距離、CDN、PHP、快取一路到資料庫的鏈條，任一環卡住都會反映在那個數字上。真正省時間的做法，是先用靜態頁那一刀切出問題在主機端還是程式端，再順著對應的根因一個一個查，每一刀都帶著該用的工具，不要憑感覺亂槍打鳥。

如果你現在只想做一件事，那就先去量一次自己的 TTFB、再放一個靜態頁量第二次——光是這兩個數字的對照，就會告訴你接下來該往哪個方向動手。把這條起跑線往前拉，後面那些壓圖、延遲載入的努力，才終於有了發揮的空間。