Feature Photo by Unsplash+

什麼是 TTFB ? 了解和最佳化 TTFB 是至關重要，因為它決定了載入時間並影響內容到達用戶的速度，這不僅僅是一個指標，它是提高網站效能及速度的基礎。

TTFB 是網站性能第一個基礎部分，不能解決這個問題，你就不可能真正擁有一個速度出色的網站。

內容目錄：

• TTFB 的過程
• 什麼是好的 TTFB ?
• 重新導向、DNS 和 TLS
• 最佳化 TTFB

TTFB 的過程

什麼是 TTFB ? 可以參考我之前寫的「如何減少 TTFB 以改善 WordPress 速度最佳化」文章。

就以一個網頁載入順序 / 時間而言，TTFB 是載入網站時第一件發生的事情，它發生在頁面上視覺方式和繪製任何內容之前，我們經常被稱為「伺服器回應時間」。

但這不是 Google 官方的 Core Web Vitals 重要指標，只有 LCP、INP 和 CLS 是你必須通過或失敗的正式指標，所以，很多人會忽略 TTFB 的重要性。

但是，TTFB 為何很重要 ?

因為 TTFB 是感知性能，感覺網站有多快 ，這一點與 PageSpeed Insights 的

分數有關連，對指標具有巨大的影響。

TTFB 是以下幾個部分組成：

• 重新導向
• DNS 查找
• SSL / TLS
• 快取

TTFB 的過程發展：
HTTP 連接、重定向 (HTTP 301 → HTTPS) → DNS → SSL 連接 → 快取

什麼是好的 TTFB？

根據 Google 的說法，他們希望你的 TTFB 時間低於 800 ms (毫秒)，我個人建議目標是 300 ms 以下。

重新導向、DNS 和 TLS

在測試 TTFB 時，不僅看到伺服器回應時間，還有之前提到 TTFB 組成的部分 (重新導向、DNS 和 TLS)。

例如：在 GTmetrix 測試中，你可以查看到 DNS 查找時間、連線、SSL / TLS、等待時間等。

重新導向的影響

假設我用 URL 的 HTTP 版本而不是 HTTPS 版本進行 TTFB 速度測試，我們可以看到，第一個請求到 HTTP 版本有自己的時間消耗，然後，301 再轉到 HTTPS 版本，它又消耗了更多時間。

TTFB 整個過程需要 168 ms + 231 ms = 399 ms 完成。

這包含了 HTTP 轉 HTTPS 時間 + DNS 解析時間 + SSL 握手時間 + 等待時間的總合。

最佳化 TTFB

沒有其他的答案了，確定 TTFB 速度的最重要因素之一，就是你的主機了。

在你考慮 TTFB 其他最佳化方法之前，首先應該考慮你的網站主機。

Google

更高品質的主機提供者只會擁有更快的伺服器、更多資源、更好的正常運行時間等。

網站快取

最佳化 TTFB 的第一件事情，就是安裝快取外掛，例如：WP Fastest Cache、WP Rocket 或 WP Super Cache。

如果你的託管主機商已經有提供快取解決方案，例如：Kinsta Cache 或 Cloudways 的 Breeze 快取等，那麼最好使用它，因為，他們比任何人都更了解他們自己的主機環境。

沒有快取的 TTFB

有快取的 TTFB

• TTFB 時間減少 63.86%

距離是一個大問題

TTFB 對於瀏覽者的距離的影響：距離越遠，TTFB 時間越大。

你的 WordPress 網站主機的地點，位於你的客戶 (瀏覽者) 間的距離，是一個重要的關鍵因素。

主機位置在東京，瀏覽者在香港

主機位置在東京，瀏覽者在英國

• TTFB 時間增加 257.43 %

使用邊緣快取

如果，你的客戶 (瀏覽者) 遍佈全球，解決 TTFB 距離問題的唯一方法是利用邊緣快取。

邊緣快取方式與加速 CSS、JS 和圖片的傳統 CDN 不同，邊緣快取從 Cloudflare 邊緣伺服器 (全球多個地點) 為你的整個網站（HTML、CSS、JS 和圖片）提供服務。

選擇有邊緣快取的主機託管商，例如：Kinsta 或 Rocket.net 主機商。

如果，你使用的主機沒有此功能，可以使用付費的 Cloudflare APO (5 美金 / 月) + Cloudflare 外掛程式來實現相同的效果。

其實，我很不建議使用 Cloudflare 免費或付費的服務，因為對台灣不友善的網路，只會加大 TTFB 的時間。

有時 Cloudflare 也有安全的優勢，完全取決於你的考量。

邊緣快取對全球 TTFB 的影響有多大 ?

這是使用 Rocket.net 主機的邊緣快取，主機位置位於新加坡，當遠離主機位置的國家時，TTFB 的時間變化都可以保持在 200 ms 之內。

這是一般主機，沒有邊緣快取伺服器，距離主機位置越遠的國家，TTFB 時間越大。

增加快取的存活時間 (TTL)

增長快取的存活時間之前，要先明白快取靜態頁面如何生成。

第一個瀏覽者 (訪客) 點擊網頁時，才會開始生成快取靜態頁面。

那第一個訪客點擊網頁時，TTFB 一定是比較長的時間，處於無快取的狀態，第二個訪客點擊網頁時，網頁才會是快取狀態。

如果，你的快取設定每 10 小時過期或更短時間，則訪客很大的機率在網頁未快取的情況下造訪網站，相對 TTFB 時間會增長。

我不希望常常有第一個倒霉者，那就要拉長快取的存活時間，讓訪客隨時都處於網站快取狀態。

大部份的外掛都可以調整快取存活時間 (自動清除更新內容)。

我建議調整為 30 天，若是部落格網站，甚至可以增加到 1 年。

快取預熱

改善 TTFB 的另一個方法是預先載入快取，也稱為「預熱」，也就是 WP Rocket 外掛的 Preload Cache 功能。

簡單說，一旦快取被清除 (或存活時間到期)，就會有一個自動化過程來重建網站快取，而且無需訪客的點擊。

這可以透過幾種不同的方式來實現：

• 利用快取外掛本身的功能。
• 定時掃描 WordPress sitemap.xml 地圖檔案重建快取。

你要知道，預先載入快取的缺點是，它會產生伺服器負載，要考慮伺服器是否可以承受。

減少清除快取的頻率

前面所說：我們增長了快取存活的時間，相對的，就要盡量減少清除快取的頻率，清除的頻率越高，就要重複的一直生成網站快取。

結論

我簡單做一個摘要：

• TTFB 對後面的 FCP、LCP 有著重要的影響。
• TTFB 必須低於 800 ms，但目標是低於 300 ms。
• 一個高效能的主機是必須的。
• 網站一定要有快取。
• 邊緣快取伺服器解決了距離問題。
• 減少 HTML 文件的大小和 DOM 元素的數量。
• 增長快取存活的時間。
• 預先載入快取 (快取預熱)。
• 降低清除快取的頻率。

網站的速度並非一切都是完美的，由於某些功能原因，你需要繞過快取。

如果，你的網站是為全球各地的客戶提供服務，那麼 TTFB 是個重要的觀念。

追求網站的完美有時是浪費時間，就像 PageSpeed Insights 中的所有內容一樣。

隨著時間的改變，網站最佳化的方法會不斷改進，這就是 WordPress 的美妙之處。