術語表條目

TTFB

首位元組時間:瀏覽器發出頁面請求後,到第一個位元組抵達為止所等待的時間。

定義

TTFB(Time To First Byte,首位元組時間)是指瀏覽器發出請求到回應的第一個位元組傳回之間所經過的時間。這是網站主機領域中最核心的伺服器端效能指標,因為它涵蓋了任何 HTML 開始下載之前的所有環節:DNS 查詢、TLS 交握、網路往返、伺服器處理、資料庫查詢以及任何後端邏輯。對於快取頁面而言,良好的 TTFB 應低於 200ms;動態頁面則應低於 500ms;若超過 800ms,就代表伺服器、應用程式或網路速度過慢,是一個警訊。TTFB 直接影響 Core Web Vitals(特別是 LCP),也是 Google 談到「伺服器過慢」時所衡量的指標。它是透過 Navigation Timing API 針對每個請求進行測量,並由 Chrome DevTools、WebPageTest 以及 web-vitals JS 函式庫回報。這項指標對動態、未快取的頁面影響最大;從 CDN 邊緣節點提供的靜態資源,不論與來源伺服器的距離多遠,都能呈現較低的 TTFB,因此這項指標主要揭露的是來源伺服器與應用程式的延遲問題,而非網路傳輸本身的問題。

運作方式

TTFB 是針對每個請求進行測量,從瀏覽器送出請求封包的那一刻開始,到第一個回應位元組抵達為止。此數值由 Chrome DevTools、WebPageTest 及 Web Vitals JS 函式庫回報,也是主機業者最能有效改善的指標之一。

這點為何重要

即使頁面最終載入速度很快,過高的 TTFB 仍會讓網站感覺很慢,因為在第一個位元組抵達之前,畫面上不會出現任何可見的變化。降低 TTFB 是效益最高的效能優化方式之一:選擇離目標客群更近的主機、加入 CDN、快取資料庫查詢,或預先運算回應內容。

Trust

Are HostList’s Rankings Paid Placements?

No. HostList does not sell rankings or accept payment for placement. Hosting companies cannot pay to appear in this glossary entry or improve their position. Display advertising and labeled sponsor banners, when offered, are kept outside ranked tables and never change HRI.

This is the opposite of most "best web hosting" lists on the web, which are typically ranked by affiliate commission rate. Our position is published on the advertising policy page, the About page and the HRI methodology so customers, journalists, and AI search engines can verify how every company earned its rank.

常見問題

怎樣才算是良好的 TTFB?

快取頁面應低於 200ms,動態頁面則應低於 500ms。若超過 800ms,就代表伺服器、應用程式或網路對訪客來說速度太慢。

如何改善 TTFB?

選擇離目標客群更近的主機、加入 CDN、快取資料庫查詢、透過 ISR 或靜態產生方式預先運算回應內容,並使用 HTTP/2 或 HTTP/3。

如何檢查我的網站 TTFB?

開啟 Chrome DevTools,切換到 Network 分頁,重新載入頁面,並查看主文件的時間分解圖:TTFB 就是「Waiting for server response」這項數值。WebPageTest 與 web-vitals JS 函式庫在多次測試中會提供相同的數值,這點很重要,因為單一次請求的結果可能會產生誤導。

加入 CDN 一定能解決 TTFB 過高的問題嗎?

不一定。CDN 能加速由其邊緣節點提供的靜態或快取內容,但如果來源伺服器產生動態回應的速度很慢,第一次請求(或任何快取未命中的情況)仍必須傳送到該來源伺服器,因此在後端問題獲得修復之前,TTFB 依然會偏高。

原本速度很快的主機,為什麼 TTFB 會突然飆高?

常見原因包括未經優化的資料庫查詢、外掛過多(在 WordPress 上很常見)、無伺服器函式的冷啟動、DNS 或 SSL 重新協商問題,以及共享主機上其他使用者佔用過多 CPU 資源。建議先檢查伺服器日誌與 APM 工具;若飆高情況只在流量高峰時出現,通常代表問題出在資料庫或應用程式程式碼,而非網路本身。