TTFB 優化怎麼做？5 個常見原因逐一排查

多數人聽到網站變慢，第一個反應是圖片沒壓、外掛裝太多，於是壓圖、延遲載入、裝一輪外掛清理工具，測完卻發現分數紋風不動。問題往往根本不在前端——如果伺服器要花半秒甚至一秒才擠出第一個位元組，後面不管怎麼優化，都是在跟一個已經輸在起跑點的數字賽跑。

這段等待，業界稱作 TTFB（Time to First Byte，第一位元組時間）。Google 把它視為 LCP（最大內容繪製）的起跑線，這條線往後移多少，LCP 就跟著往後移多少，不管前端怎麼優化都補不回來。TTFB 優化因此不是選配，而是所有前端努力能不能生效的地基。

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

TTFB 是什麼？為什麼它決定了 LCP 能不能達標

把 TTFB 和「網站整體載入速度」這種籠統說法搞混，是多數人優化方向抓錯的起點。頁面載入速度涵蓋 HTML、CSS、JavaScript、圖片全部下載並渲染完成的總時間，TTFB 只量一件很單純的事，也就是從瀏覽器發出請求，到它收到伺服器回傳的第一個位元組為止，中間經過多久，後面下載得快不快完全不算在這個數字裡。

依官方定義拆開來看，TTFB 涵蓋重新導向時間（如果有）、DNS 查詢、連線與 TLS 協商，一直到請求送出後、回應第一個位元組送達為止。動態網站的 TTFB 偏高，問題幾乎都出在最後那一段，伺服器要跑程式、查資料庫、把 HTML 組好才開始回應，這也是為什麼優化 TTFB 的重心在伺服器端，不是你一直在弄的前端。

它之所以被視為 LCP 的天花板，是因為渲染有先後順序，瀏覽器要先收到資料，才能開始解析、下載資源、畫出最大那塊內容。Google 官方的說法是，TTFB 會先於 FCP（首次內容繪製）、LCP 這類使用者體感指標執行，TTFB 值偏高，會讓後面所有指標的值跟著被往後推。嚴格說，TTFB 本身不在 Google 三大核心網頁指標（LCP、INP、CLS）的清單裡，不是直接的排名分數，但它是這些指標能不能達標的起跑線，也因此透過 LCP 間接影響 SEO。它還有一個容易被忽略的副作用，也就是爬蟲的抓取預算有限，碰到回應慢的頁面就會少抓幾頁，連帶拖累索引量。

多快才算合格？官方基準是 0.8 秒與 1.8 秒

網路上流傳的及格線版本很多，有人說 200 毫秒，有人說 600 毫秒，真正的官方基準只有一個。Google 在 web.dev 把 TTFB 的「良好」門檻訂在 0.8 秒以下，「不佳」訂在超過 1.8 秒，中間這一段屬於待改善。

同一個網站，PageSpeed Insights 上常會出現兩組不同的 TTFB，一組來自「瞭解實際使用者體驗」的欄位資料，一組來自「文件要求延遲時間」的實驗室資料。兩者對不上很正常，實驗室工具通常只測最終網址，會漏掉重新導向拉長的那段時間；欄位資料則是真實訪客各種網路環境的綜合結果。哪一組數字比較該相信，要看落差是哪個方向：實驗室數字遠比欄位數字高，代表測試環境比一般使用者更受限；欄位數字遠比實驗室數字高，通常代表伺服器快取、重新導向或網路環境在真實流量裡拖了後腿，這種情況更該往下一節的排查方法查。

主機等級大致能對出一個合理順序：共用主機因為要跟同一台伺服器上的其他網站分資源，通常最慢；VPS 或雲端主機資源相對獨立，能明顯壓低延遲；代管型 WordPress 主機如果針對效能調校過，往往是三者裡反應最快的一種。先知道自己這台主機物理上落在哪個等級，後面設的目標才務實。

怎麼揪出 TTFB 慢在哪一段？

工具面板裡的數字只會告訴你「TTFB 是多少」，不會告訴你「慢在哪一段」，而這才是真正卡住優化方向的地方。有兩個方法能把黑箱打開。

第一個方法簡單但很有效，作法是在網站根目錄放一個純靜態的 HTML 檔案，內容隨便寫幾行字就好，重點是它完全不經過 PHP 和資料庫，再用測速工具量這個靜態頁的 TTFB。這個數字代表你這台主機不做任何運算、純粹回應一個檔案的理論最短時間。接著拿它跟 WordPress 動態頁的 TTFB 對照，如果靜態頁本身就慢，問題出在主機或網路層，動 WordPress 設定沒有用；如果靜態頁很快、動態頁卻慢很多，那中間拉開的差距就是 WordPress 自己的處理吃掉的，要往程式層面查。

第二個方法更精準，卻是多數教學沒講清楚的一環，也就是 Server-Timing 回應標頭。它讓後端程式把資料庫查詢花了多久、伺服器端渲染花了多久這類內部耗時，直接寫進 HTTP 回應標頭：

Server-Timing: db;desc="Database";dur=121.3, cache;desc="Edge Cache";dur=4.2Code language: plaintext (plaintext)

把這個標頭加進回應之後，Chrome 開發者工具的 Network 時間軸就會把這些分段攤開來看，原本黑箱的伺服器內部時間變成可量測的數字，能精準指出到底是資料庫、渲染、還是快取層在拖時間。在 WordPress 環境裡，Query Monitor 這類除錯外掛能直接列出每個頁面跑了哪些查詢、各自花多久，兩個工具搭配著用，幾乎能把整段 TTFB 拆到看見每一小段的重量。

原因一：主機量能扛不住，不是被鄰居擠資源，就是版本太舊

共用主機最容易被忽略的問題，不是效能不夠，而是效能會被別人借走。多數共用方案把幾百個網站塞進同一顆 CPU、同一份記憶體額度，平常相安無事，一旦某個鄰居網站流量暴衝，或某支外掛陷入無窮迴圈占用資源，主機商為了保護整台伺服器會啟動資源限制，你的網站就跟著被連坐降速。這種被搶占資源造成的忽快忽慢，比單純效能不足更難查，因為同一個時段測兩次，數字可能完全不一樣。

版本老舊是另一個常被放著不管的變數。WordPress 是用 PHP 寫的，每次有人開頁面，伺服器都要跑一輪 PHP 才能組出 HTML，不同版本之間的執行效能差距不小。根據 Kinsta 在 2025 年底發布的跨版本效能測試，WordPress 從 PHP 7.4 升到最新的 PHP 8.5，每秒能處理的請求數提升約 6.6%；如果網站上還跑著 WooCommerce 這類電商功能，光是從 PHP 7.4 升到 PHP 8.2，吞吐量就拉高了約 23%。版本越新，伺服器算同一件事花的時間通常越短。

要查目前跑的是哪個版本，進 WordPress 後台的「工具」到「網站狀態」再到「資訊」，在「伺服器」區塊就看得到，多數主機商後台也支援一鍵切換，升級前先確認佈景主題和外掛都相容。除了版本，記憶體額度同樣值得留意，如果主機給應用程式分配的記憶體不夠，程式就得靠磁碟做暫存空間來補，磁碟讀寫比記憶體慢上好幾個量級，網頁自然遲遲生不出來。選主機時除了看價格，更該問清楚記憶體給多少、後端軟體版本是不是持續在更新。

原因二：讀者離主機太遠，CDN 卻只顧到圖片和 CSS

很多人裝了 CDN，滿心以為 TTFB 就此解決，結果一測還是沒什麼變化。問題出在多數 CDN 預設只加速圖片、CSS、JavaScript 這類靜態資源，對 HTML 頁面幫助有限，原因很單純，HTML 是動態產生的，就算 CDN 有能力快取任何內容，只要沒有替 HTML 設定合適的 Cache-Control 標頭，請求還是得整段繞回原站，由 PHP 重新跑一遍。

在處理這一層之前，先確認第一層物理限制有沒有解決。如果讀者主要在台灣，主機卻擺在美國，每次請求都要橫跨整個太平洋，光是海底光纖的來回傳輸就多花上百毫秒，這還沒算伺服器處理的時間。距離造成的延遲，網路再快也消不掉，選主機時，亞洲讀者為主的網站建議優先挑亞太區資料中心，別只因為地理位置以外的因素把站放在歐美機房。

真正能把動態頁 TTFB 壓下來的做法，是替 HTML 也開啟邊緣快取。把 Cache-Control 設定好，讓 CDN 能在離讀者最近的節點直接快取整份 HTML，使用者拿到的是邊緣節點上的成品，不用等 PHP 重跑，原站只在第一次產生快取或內容更新時才被碰一次。多數 CDN 供應商同時支援 HTTP/3 與 TLS 1.3，前者用 UDP 通訊協定解決 TCP 排隊阻塞的問題，後者把加密交握的往返次數壓到最低，兩者搭配邊緣快取，能把整段連線與回應時間一起往下拉。要確認有沒有生效，在開發者工具的 Network 裡看 HTML 文件那個請求的回應標頭，找命中快取的標記，如果每次都顯示未命中、每次都回原站，邊緣快取就還沒設定對。

原因三：沒開頁面快取與物件快取，每次都逼伺服器重新算一次

對動態網站來說，這是壓低 TTFB 最立竿見影的一步，卻也是最常被跳過的一步。正常情況下，每個訪客造訪同一個頁面，WordPress 都要從頭跑一遍：執行 PHP、向資料庫發出十幾到幾十次查詢、把結果套進模板組成 HTML。問題是，同一個頁面對每個訪客顯示的內容多半一模一樣，這套運算等於白做了無數次。

頁面快取就是用來省掉這個浪費。第一個訪客觸發的渲染結果被存成靜態 HTML，後面的訪客直接拿現成的，完全跳過 PHP 和資料庫，TTFB 通常會出現數量級的落差。如果主機支援更底層的伺服器級快取，效果會更明顯，請求在還沒進到 PHP 之前就被直接攔下來回應，連 PHP 都不必啟動，比只靠外掛在 PHP 層做的快取更徹底。

頁面快取解決的是整頁內容都一樣的情境，但會員中心、購物車、後台這類每個人看到的內容不一樣的頁面，沒辦法整頁快取，這時候該補的是物件快取。用 Redis 或 Memcached 把重複查詢的結果和運算物件存進記憶體，下次直接取用，不用再重新查一次資料庫，對這類無法整頁快取的頁面特別有感。

原因四：重新導向鏈，悄悄多墊了幾百毫秒

重新導向是很容易被忽略的一種 TTFB 拖累，因為它發生在真正的內容還沒開始傳送之前。當瀏覽器對一份文件發出導覽請求，收到的卻是「資源在別的地方」的回應，就會再發一次請求，一次重新導向就已經多墊了一趟來回，如果那個新位置又指向另一次重新導向，延遲會一路疊加上去。

最常見的成因是同源重新導向，網址少打了 https 協定，瀏覽器先預設連 http、再被導去 https；或是網址結尾有沒有斜線、有沒有 www 前綴不統一，內部連結指向舊版網址，每次點擊都先繞一圈才到真正的頁面。這類重新導向完全在自己的掌控之內，值得抓時間逐一檢查網站上的連結，看有沒有回應 301 或 302 狀態碼的路徑。

跨來源重新導向比較棘手，通常來自社群媒體的縮網址服務、廣告或電子報的追蹤連結，這些不是網站自己能控制的部分，只能盡量確保提供給廣告主或電子報的是正確的最終網址，避免中間再疊加別的縮網址服務。至於最常見的 HTTP 轉 HTTPS 重新導向，可以靠設定 HSTS 標頭改善，讀者第一次造訪後，瀏覽器會記住這個網站要用 HTTPS，下次直接用 HTTPS 連線，不用再繞一次重新導向；把網站送進瀏覽器的 HSTS 預先載入清單，連第一次造訪都能省掉這一趟。

原因五：資料庫查詢慢、還揹著陳年設定的重量

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

某些頁面，特別是無法整頁快取的會員中心、購物車、即時搜尋結果，每次都得真的去查資料庫。資料表一旦變得龐大，或某個查詢缺了適當的索引，一句查詢就可能從幾毫秒膨脹到幾百毫秒，偏偏這種延遲被埋在伺服器內部，從外面量只看得到「總共慢」，看不出慢在哪一句，這正是前面 Server-Timing 與 Query Monitor 派上用場的地方。揪出最慢的那幾句查詢後，常見解法有兩個：替高頻查詢的欄位補上適當的索引，往往是單筆查詢從幾百毫秒掉到個位數毫秒的關鍵；再來就是前面提過的物件快取，把重複查詢結果留在記憶體，不用每次都重新問一次資料庫。

另一個常被忽略的角落，藏在 WordPress 資料庫的 wp_options 資料表裡。這張表裡的每一筆設定都可以被標記為自動載入，只要標記了，不管當下這個頁面用不用得到，都會在每一次請求時被整批讀進記憶體，後台每次點擊、每個 AJAX 呼叫、每個排程任務都一樣。外掛或佈景主題被停用甚至刪除後，留在這張表裡的設定往往沒有被真正清乾淨，日積月累疊成一堆從來沒被讀取、卻還在被強制載入的陳年資料。定期檢查並清理這些自動載入資料，能減少每次請求要處理的資料量，對長期沒整理過資料庫的網站，往往能感覺到 TTFB 明顯往下降。

103 Early Hints 是什麼？讓瀏覽器不用等你把話講完

就算前面五個原因都處理過，有些頁面天生就得花時間，牽涉到複雜資料庫運算或個人化內容的頁面，伺服器需要的準備時間很難再壓縮。這種情況下，還有一招能讓使用者感受到的等待縮短，也就是 103 Early Hints。

這是伺服器在後端還在忙著準備 HTML 的同時，先傳給瀏覽器的一個早期回應代碼，用來提示這個頁面等一下會需要哪些資源，例如樣式表。支援的瀏覽器收到這個提示，會提早開始下載那些渲染關鍵資源，不用等最終的 HTML 回應完全準備好才動工。對支援的瀏覽器來說，效果是文件能更快開始算繪、頁面看起來更快載入完成。

要注意的是，這招跟快取一樣，可能會讓 TTFB 看起來變快，實際上伺服器真正處理的時間並沒有縮短。如果後端本身效能不足或程式碼需要優化，加了 103 Early Hints，問題只是被掩蓋，不是被解決。用了這個技巧的網站，更該搭配前面提過的 Server-Timing 標頭，去量真正的後端耗時，而不是只看瀏覽器面板上那個看起來變快的數字。

TTFB 偏高從來不是換一台更貴的主機就能解決的單一問題，而是一條從連線設定、機房距離、CDN、版本、快取，一路到資料庫的鏈條，任一環卡住都會反映在那個數字上。真正省時間的做法，是先用靜態頁那一刀切出問題在主機端還是程式端，再用 Server-Timing 把黑箱攤開，順著對應的原因一個一個查，每一步都帶著該用的工具，不要憑感覺亂槍打鳥。如果現在只想先做一件事，那就去量一次自己的 TTFB，再放一個靜態頁量第二次，這兩個數字的對照，會直接告訴你接下來該往哪個方向動手。