什麼是 Waiting TTFB 加載時間過長？ 3 步教你如何在 WordPress 當中優化 TTFB 速度

Facebook Line Messenger Telegram

TTFB（Time to First Byte）是瀏覽器發出請求到伺服器回傳第一個位元組的等待時間。WordPress 網站只要把 TTFB 壓到 200ms 以內，使用者的白畫面等待感就會幾乎消失，Core Web Vitals 的 LCP 分數也會跟著改善。

很多站長花大量心力壓圖片、延遲載入 JS、裝 CDN，卻忽略了伺服器回應速度這個根本問題。前端再怎麼優化，如果伺服器要花 2 秒才開始吐資料，使用者的第一印象就是「慢」。這篇文章會帶你搞懂 TTFB 的原理、測量方式，以及 4 個在 WordPress 中實際有效的優化方法。

什麼是 TTFB（Time to First Byte）？

TTFB 全名是 Time to First Byte，測量的是從瀏覽器發出 HTTP 請求，到收到伺服器回傳的第一個位元組為止所經過的時間。這個指標跟整體頁面載入速度不同：頁面載入速度涵蓋所有資源下載完成的總時間，TTFB 只看伺服器「多快能開始回應」。

一個完整的 TTFB 過程可以拆成三個階段：

DNS 解析：瀏覽器將網域名稱轉換成伺服器的 IP 位址
連線建立：瀏覽器與伺服器建立 TCP 連線，HTTPS 還需要 TLS 握手
伺服器處理與回應：伺服器接收請求、查詢資料庫、渲染頁面後回傳第一個位元組

WordPress 網站的 TTFB 偏高，問題通常出在第三個階段。動態的 PHP 處理和資料庫查詢吃掉了大部分時間，這也是為什麼優化 TTFB 的核心策略集中在伺服器端，而不是前端。

TTFB 與 SEO 排名的關聯

Google 從 2010 年就把網站速度列為排名因素，2021 年又推出 Core Web Vitals 評估機制。截至 2026 年 5 月，Core Web Vitals 包含三個指標：LCP（Largest Contentful Paint，最大內容繪製）、INP（Interaction to Next Paint，互動到下一次繪製，已取代原本的 FID）、以及 CLS（Cumulative Layout Shift，累計版面位移）。

TTFB 雖然不是直接的排名因子，但它直接影響 LCP 和 FCP（First Contentful Paint）。TTFB 越長，瀏覽器越晚收到第一批資料，後續所有的渲染工作都會跟著延遲。Google 在官方文件中明確建議伺服器回應時間應控制在 200ms 以下（PageSpeed Insights 標準），而 web.dev 的建議是整體 TTFB 在 800ms 以內算良好，超過 1800ms 就屬於不佳。

從SEO 優化的角度看，TTFB 是間接但重要的排名因素。不只是使用者體驗的問題，TTFB 過長也會影響 Google 爬蟲的抓取效率。爬蟲在有限的抓取預算內，碰到回應慢的頁面就會少抓幾頁，連帶影響索引量。

如何測量 WordPress 網站的 TTFB

要知道自己網站的 TTFB 表現，有兩種主要方式。

方法一：Chrome DevTools

最快的方式就是用 Chrome 內建的開發者工具。在網頁上按右鍵選「檢查」，切換到 Network 標籤頁，重新整理頁面後點選第一個請求（通常就是你的網址），在 Timing 標籤下就能看到 Waiting for server response 的時間，這就是 TTFB。

這個方法的優點是即時、零安裝，缺點是只能測試你當前網路環境下的數值，不具備全球代表性。

方法二：線上 TTFB 檢測工具

如果想知道全球各地使用者體驗到的 TTFB，可以使用以下工具：

KeyCDN Performance Test：可從多個地區同時測試 TTFB，介面簡潔
Pingdom Website Speed Test：提供詳細瀑布流分析，可選擇不同測試地點
GTmetrix：結合 Google Lighthouse 與 Web Vitals 數據，報告完整
WebPageTest：進階工具，支援從全球多個地點測試，可設定各種測試條件
PageSpeed Insights：Google 官方工具，直接給出 Core Web Vitals 評分

如果你需要更全面的網站測速工具，或者想用瀑布流方式檢測網站載入速度，這些都是很好的選擇。也可以搭配Testmysite.io 從不同角度了解速度表現。

TTFB 標準評分表

等級	TTFB 數值	說明
優良	< 200ms	伺服器回應極快，使用者幾乎感受不到等待
普通	200ms ~ 800ms	尚可接受，但仍有優化空間
不佳	> 800ms	使用者會明顯感受到延遲，需要盡快優化
嚴重	> 1800ms	嚴重影響使用者體驗與 SEO 排名

TTFB 多少才算正常？

Google 建議伺服器回應時間控制在 200ms 以內，但這個目標對很多使用虛擬主機的 WordPress 網站來說並不容易。實際上，不同等級的主機有不同的 TTFB 表現範圍：

主機類型	預期 TTFB 範圍
共用主機（Shared Hosting）	300ms ~ 800ms
VPS / 雲端主機	100ms ~ 300ms
專屬主機 / Managed WordPress	50ms ~ 200ms

要找出你自己主機的 TTFB 基準值，有個簡單的方法：在網站根目錄建立一個純靜態的 HTML 檔案，然後用線上工具測量這個頁面的 TTFB。假設測出來是 60ms，這個數值就是你這台主機的理論最短 TTFB。如果 WordPress 動態頁面的 TTFB 是 500ms，代表 WordPress 本身的處理就吃掉了 440ms，這就是你該優化的方向。

地理位置對 TTFB 的影響非常大。一台放在美國的主機，台灣使用者連過去的 TTFB 通常會比美國本地使用者高出 150-300ms，這就是網路傳輸距離造成的延遲。選擇距離目標使用者較近的主機，是降低 TTFB 最直接有效的方法之一。

導致 WordPress 網站 TTFB 過長的 5 大原因

搞清楚問題的根源，才能對症下藥。以下是 WordPress 網站 TTFB 過長最常見的五個原因：

原因 1：主機伺服器距離使用者太遠

網路資料的傳輸速度雖然很快，但物理距離的影響無法消除。主機放在美國，台灣使用者每次請求都要跨越整個太平洋，光海底光纖的傳輸就要 100-200ms。如果目標讀者主要在台灣或亞洲，選擇亞太區資料中心會有立竿見影的改善。

原因 2：主機效能不足

便宜的共用主機一台實體機器上可能塞了幾百個網站，CPU、記憶體、磁碟 I/O 全部共用。當鄰居網站流量暴增時，你的 WordPress 也就跟著變慢。這種情況下 TTFB 往往不是固定偏高，而是時好時壞，尖峰時段特別嚴重。

原因 3：DNS 解析速度過慢

DNS 是 TTFB 三階段中的第一關。如果域名註冊商提供的 DNS 伺服器回應速度慢，使用者每次連線都要多等幾十到幾百毫秒。很多人換了主機卻忘了換 DNS，結果 TTFB 還是降不下來。

原因 4：WordPress 外掛裝太多

每個啟用的外掛都可能在頁面載入時執行額外的 PHP 程式碼和資料庫查詢。裝了 30 幾個外掛的網站和只裝 5 個的網站，TTFB 可以差到兩三倍。特別是社交分享按鈕、相關文章推薦、SEO 分析這類在每次請求都會跑一輪的外掛，影響尤其明顯。

原因 5：沒有啟用頁面快取

WordPress 是動態網站，每次有人造訪一個頁面，伺服器都要執行 PHP 程式碼、查詢資料庫、組合模板後才輸出 HTML。啟用頁面快取之後，第一次造訪的結果會被存起來，後續訪客直接拿到靜態 HTML，完全跳過 PHP 和資料庫的處理。沒裝快取外掛的 WordPress 網站 TTFB 動不動就 500ms 以上，裝了之後通常可以壓到 100ms 以內。

你可以透過WordPress 網站狀態檢查來初步了解目前的伺服器效能表現，再針對上述問題逐一排查。

優化 TTFB 方法 1：選擇高效能的 WordPress 主機

主機效能是 TTFB 的根本。你可以把 DNS 調到最快、快取裝到最滿，但如果主機本身的 CPU 和記憶體就不夠力，TTFB 還是降不到理想範圍。

在選擇 WordPress 主機時，有幾個會直接影響 TTFB 的關鍵因素：

資料中心位置：選擇離你目標使用者最近的機房。如果讀者主要在台灣，優先考慮有東京、新加坡或香港節點的主機商
伺服器資源配置：共用主機的問題在於資源競爭。升級到 VPS 或 Managed WordPress 方案可以獲得獨立的 CPU 和記憶體配額
是否內建快取：有些主機商在伺服器層級就提供進階快取機制（如 LiteSpeed Cache、Nginx FastCGI Cache），效果比外掛層級的快取更好
PHP 版本支援：支援 PHP 8.x 的主機在處理速度上會比只支援 PHP 7.x 的快上不少

Bluehost 是 WordPress 官方推薦的主機商之一，入門方案價格親民，而且針對 WordPress 做了專門的環境優化。對於剛開始架站的新手來說，Bluehost 的 TTFB 表現在共用主機中相當不錯。

如果網站流量比較大，或者對速度有更高的要求，Kinsta 是值得考慮的進階選項。Kinsta 使用 Google Cloud Platform 基礎架構，提供企業等級的伺服器效能和全方位快取機制，TTFB 通常可以壓到非常低。

想要看更多主機的比較資訊，可以參考我們整理的WordPress 虛擬主機推薦懶人包，裡面有 17 家主機的速度、費用和功能完整比較。其他像是 SiteGround 和 A2 Hosting 也是在速度方面口碑不錯的選擇。

優化 TTFB 方法 2：使用 Cloudflare DNS 與 CDN 加速

DNS 解析是 TTFB 的第一關，很多人花了很多心力在主機和快取上，卻忽略了這個環節。如果域名使用的是註冊商預設的 DNS 伺服器，回應速度可能不太理想。

換用 Cloudflare DNS

Cloudflare 提供的 DNS 服務是全球公認最快的之一。根據 DNSPerf 的持續監測數據，Cloudflare DNS 的全球平均解析時間穩定在 10ms 以下。更棒的是，Cloudflare 的基本方案完全免費，包含 DNS 服務和基礎 CDN 功能。

切換到 Cloudflare DNS 之後，TTFB 的 DNS 階段通常可以從原本的 80-120ms 降到 10ms 左右，光這一步就省掉了將近 100ms。設定方式也不複雜：到 Cloudflare 註冊帳號、加入你的域名，再到域名註冊商那邊把 DNS 伺服器改成 Cloudflare 指定的地址即可。

如果你也想在手機或家用網路上使用 Cloudflare 的快速 DNS，可以參考1.1.1.1 DNS 服務的設定教學。

啟用 CDN 縮短物理距離

CDN（Content Delivery Network）的原理是在全球各地部署快取節點，當使用者造訪你的網站時，靜態資源會從離他最近的節點提供，不用每次都連回你的主機。雖然 CDN 對動態頁面的 TTFB 直接影響有限，但它能大幅縮短 HTML 頁面首次回應的傳輸時間，特別是當主機和使用者分處不同洲的時候。

Cloudflare 的免費方案本身就包含基礎 CDN 功能。啟用前後可以用Cloudflare Speed Test 來確認速度差異。

DNS 速度檢測工具

想知道目前 DNS 的速度表現，可以用以下工具測試：

UltraTools DNS Hosting Speed：輸入域名即可測試 DNS 伺服器的回應速度
SolveDNS Speed Test：提供全球多地的 DNS 解析速度數據

另外，DNS 的技術標準也在持續更新，保持 DNS 伺服器的軟體版本最新也有助於維持解析速度。

優化 TTFB 方法 3：啟用 WordPress 快取機制

對 WordPress 這種動態內容管理系統來說，快取是降低 TTFB 最立竿見影的方法。原理很簡單：正常情況下每次有人訪問頁面，WordPress 都要執行 PHP 程式碼、向資料庫發出十幾到幾十次查詢、把結果套入模板渲染成 HTML。啟用頁面快取後，第一次的渲染結果會被存成靜態 HTML 檔案，之後的訪客直接拿到靜態版本，完全跳過 PHP 和資料庫處理。

實測效果非常明顯：未啟用快取的 WordPress 頁面 TTFB 通常在 400-800ms 之間，啟用後可以降到 50-150ms。

伺服器端進階快取

如果你的主機支援，還可以啟用更底層的快取機制來進一步壓低 TTFB：

OPcache：PHP 的 opcode 快取，把編譯後的 PHP 腳本存在記憶體中，省掉每次請求重新編譯的時間
Redis / Memcached：物件快取，把資料庫查詢結果存在記憶體中。很多 Managed WordPress 主機都有內建 Redis 支援
GZIP 壓縮：啟用GZIP 資料壓縮可以減少傳輸資料量，間接加快整體回應速度

快取做到這個層級，TTFB 基本上就能穩定在很低的水平了。

優化 TTFB 方法 4：升級 PHP 版本與精簡外掛

很多 WordPress 網站的 TTFB 問題其實不是出在硬體，而是出在軟體層面。PHP 版本過舊和外掛裝太多這兩個問題，是 WordPress TTFB 偏高的隱形殺手。

升級到 PHP 8.x

PHP 是 WordPress 運作的基礎語言，版本之間的效能差異非常大。根據多個獨立測試單位的基準測試結果，PHP 8.x 相比 PHP 7.4 的處理速度提升約 20-30%，最大的效能躍進來自從 PHP 7.x 升級到 8.0。PHP 8.3、8.4 之間的差異就比較小了，升級的主要好處是安全性和功能支援，而不是速度。

檢查 WordPress 網站的 PHP 版本很簡單：進入後台的「工具」→「網站狀態」→「資訊」頁面，在「伺服器」區塊就能看到目前的 PHP 版本。大部分現代化的主機商都支援一鍵切換 PHP 版本。

升級前建議先確認佈景主題和外掛是否相容 PHP 8.x，避免升級後出現白屏或其他錯誤。

精簡外掛數量

WordPress 外掛的便利性讓人很容易不知不覺裝了一大堆。但每多一個啟用的外掛，頁面載入時就多了一份 PHP 處理和資料庫查詢的負擔。裝了 40 多個外掛的網站，TTFB 動不動就 1 秒以上，砍到 15 個之後可能立刻降到 300ms 以內。

幾個精簡外掛的原則：

功能重複的外掛只保留一個（例如裝了兩個 SEO 外掛就刪掉一個）
沒有在用的外掛直接停用並刪除，不要只是關掉
可以用程式碼實現的功能就不要裝外掛（例如加入 Google Analytics，直接改 theme 的 header.php 就好）
定期檢查外掛列表，移除長期沒有更新的外掛

除了精簡外掛，WordPress 網站速度優化還有很多小技巧可以幫忙降低伺服器的處理負擔。如果你正在系統性地優化 WordPress 網站，這些方法都值得搭配使用。

TTFB 優化常見問題 FAQ

TTFB 和頁面載入速度有什麼不同？

TTFB 只測量從發出請求到收到第一個位元組的時間，頁面載入速度（Page Load Time）則涵蓋所有資源（HTML、CSS、JavaScript、圖片）全部下載並渲染完成的總時間。TTFB 是頁面載入速度的其中一環，但不是全部。一個網站可能有很快的 TTFB 但整體載入很慢（例如圖片太大），也可能 TTFB 偏高但後續載入很快（因為啟用了瀏覽器快取）。

CDN 能改善 TTFB 嗎？

要看情況。CDN 主要加速靜態資源的傳輸，對 HTML 頁面的 TTFB 直接幫助有限（除非啟用了全頁面快取功能）。但如果主機距離使用者很遠，CDN 可以減少 TCP 連線和 TLS 握手的延遲，間接降低 TTFB。Cloudflare 的免費方案同時提供了 DNS 加速和基本 CDN 功能，搭配使用效果不錯。

為什麼本地測試 TTFB 很快但全球測試很慢？

這通常是地理距離造成的。本地測試時，瀏覽器和伺服器可能都在同一個城市，網路延遲極低。但全球測試工具可能從美國、歐洲等地發出請求，跨越半個地球的網路傳輸本身就會增加 100-300ms 的延遲。解決方式就是選擇靠近目標使用者的主機位置，或者使用 CDN 來縮短距離。

共用主機的 TTFB 能做到多少？

老實說，共用主機的 TTFB 天花板就在那裡。好的共用主機在離機房近的地區可以做到 200-400ms，但尖峰時段可能飆到 800ms 以上。如果 TTFB 目標是穩定在 200ms 以內，通常需要考慮升級到 VPS 或 Managed WordPress 主機。不過先確保啟用了頁面快取和最新 PHP 版本，共用主機也能有不錯的表現。

TTFB 過長會影響 SEO 排名嗎？

會，雖然是間接影響。TTFB 過長會拖慢 LCP 和 FCP 等 Core Web Vitals 指標，而 Google 確實把這些指標納入排名考量。不只如此，TTFB 過長也會影響 Google 爬蟲抓取頁面的效率。如果爬蟲預算用完了你的頁面還沒抓完，索引量就會受到影響。所以 TTFB 優化不只是使用者體驗問題，也是 SEO 的重要一環。

TTFB 為 0 是正常的嗎？

不是。如果在某個工具上看到 TTFB 為 0 或極低（例如 1-2ms），通常表示測試的是已經被快取在本地的頁面，或者測試工具本身有問題。真實的 TTFB 不可能為 0，因為資料在網路上傳輸一定需要時間。

如何區分是主機問題還是程式問題導致 TTFB 過長？

最簡單的方法就是前面提到的靜態頁面測試法：建立一個純 HTML 靜態頁面，測量它的 TTFB。如果靜態頁面的 TTFB 已經很高（超過 200ms），那問題就在主機或網路層面。如果靜態頁面 TTFB 很低但 WordPress 頁面很高，那就是 WordPress 程式層面的問題（外掛太多、沒裝快取、PHP 版本太舊）。

優化 TTFB 的下一步

如果你看完這篇文章，準備開始動手優化，建議按照以下順序執行：

先測量目前的 TTFB：用 Chrome DevTools 或 PageSpeed Insights 測一次基準值，同時測一個靜態 HTML 頁面的 TTFB，判斷問題出在主機還是 WordPress。預期結果：你會得到一個明確的基準數字和問題定位。
啟用頁面快取：安裝 WP Rocket 或你主機對應的快取外掛，啟用後重新測量。這一步的效果最直接，TTFB 通常可以降 50-70%。預期結果：TTFB 從 400-800ms 降到 100-200ms。
換用 Cloudflare DNS：到 Cloudflare 註冊免費帳號，將域名的 DNS 伺服器切換過去。這一步可以省掉 DNS 階段幾十到一百多毫秒。預期結果：DNS 解析時間從 80-120ms 降到 10ms 以下。

這三步做完之後，絕大多數 WordPress 網站的 TTFB 都能進入可接受的範圍。如果還是不夠理想，那就是時候認真考慮升級主機了。