[lwptoc numeration=”decimalnested”]
什麼是TTFB
在開始著手處理 TTFB 延遲的問題前，我們先了解一下什麼是 TTFB 才能對症下藥，TTFB 是從 Request 到系統回應第一個 Byte 的累計時間，從上圖可以清楚了解 TTFB 是從 startTime 到 responseEnd（Resouce Timing），這中間包含以下幾個階段：
- Redirect 時間
- 服務起始時間
- DNS 查詢時間
- 連線（包含 TLS 協商時間）
- 請求後直到第一個 Byte 回應的時間
所以要降低TTFB延遲，就必須針對以上這幾個階段下手才行。
TTFB 目標數值
Google 建議 TTFB 最好要低於 0.8 秒甚至更低，若超過 1.8 秒是比較差 (POOR) 的狀況，所以我們要優化 TTFB 時要以 0.8 秒為目標值。
如何量測 TTFB
目前網路上有很多不錯的工具可以量測，個人比較喜歡使用 WebPageTest 及 PageSpeed Insights ，因為在檢測結果頁面會提供優化的處理方向
- WebPageTest
- PageSpeed Insights
- Chrome 開發人員工具的 network panel
下圖為本站使用 PageSpeed Insights 工具檢測結果，紅圈處為 TTFB 的值另外也提供其他參考數據，在結果頁面下方有更多分析可提供你找出網站緩慢的可能問題
如何降低 TTFB
在了解 TTFB 及知道如何量測後，就可知道 TTFB 是很依賴主機及後端系統的架構，要改善並不是一件容易的事情，接下來我們就對 TTFB 每個階段可以改善的部份進行說明。
若你無法花太多資源來改善 TTFB 時也沒關係，Google 提到只要不妨礙其他重要指標的基礎下， TTFB 並不是必要的 Core Web Vitals 量測指標，或許你可以把資源放在其他指標的改善。
更換虛擬主機
由於 TTFB 很依賴主機和後端系統，所以改善的主要方式就是直接更換或升級主機，例如共享主機、VPS和雲端主機的效能一定不一樣，再來申請雲端虛擬主機時要選擇離目標客戶較近的機房，在回應的速度上也會有很大的落差，若你的目標客戶是跨國的狀況，建議也要購買 CDN 服務來降低 TTFB。
避免重導（Redirect）
重導就是從A網址轉到B網址，過多或無效的重導其實就是一種耗損，所以檢查網站是不是有多餘的重導行為並進行修正可稍微提昇效能，最常見的重導行為有：
- 從 http 轉到 https：
導入 HSTS preload list ，HSTS 讓瀏覽器直接以 HTTPS 連到你的網站，就可避免重導的時間並提昇網站的資訊安全，但要特別注意導入 HSTS 後，網站的 TLS 憑證要保持有效的狀態，瀏覽器不再允許使用者忽略憑證無效的警告。 - 從主網域轉到次網域（例如 example.com 轉 www.example.com）
通常網站的主網域跟www的子網域會是同一個網站，請保持使用一種域名稱就好（建議為主網域）。
啟用網站服務的快取功能
HTTP 快取的概念其實很簡單，當瀏覽器連線到伺服器並提供資料回應時，順便告訴瀏覽器這些資料可以保留在本地端多久的時間，下次訪問時只要資料沒有過期就從本地端載入，不必重新下載，這樣簡單的機制就能達到降低 TTFB 並減少頻寬的使用，另外使用快取除了可以降低 TTFB 外，還可降低主機對外的流量，若你的網站服務供應商會對流量計價時，不論你有沒有要解決 TTFB 的問題，使用 HTTP 快取對你絕對是有幫助。
通常伺服器及瀏覽器預設都會啟用快取的機制，但最好是依照自己網站的特性去設計快取，例如部落格（內容較少變動）跟電商（內容經常變動）使用的快取的策略絕對會不一樣，建議閱讀 Jake Archibald 的 Caching best practices & max-age gotchas 後再進行實做，Wordpress 的 javascript 跟 css 通常網址後面都會加上版號，所以直接上快取大致上不會有問，若真的不放心就使用 Cache-Control “no-cache, must-revalidate
改善DNS回應的速度
在瀏覽器發起連線之前，主機都要先透過 DNS 服務將網址轉換為 IP 才能發起連線，所以試著降低 DNS 回應的時間可以稍微降低 TTFB，網路上可以查到各供應商回應速度，若還沒有購買 DNS 服務時可以先做個功課調查一下供應商服務的回應時間，我查到的資料幾乎都是 Cloudflare 的速度最快，若已經購買了也沒關係，個人認為是不太需要花太多力氣在這幾十毫秒的改善上。
若 DNS 服務是自己架設的，或供應商允許你調整 TTL ，可在網站上線穩定後（不會經常更動 DNS 紀錄時），把 TTL 的時間拉長至少為 86400 秒（24小時），如此可達到 DNS 快取的效果，如下圖 DNS 有快取時的回應為 0ms。
採用HTTP/2協定
採用HTTP/2有以下的優點，在挑選主機共應商或自己架站時，都應選擇或啟用HTTP/2協定
- 只需要單一個網路連線就可連接網站伺服器下載所需要的資源，HTTP/1.1則需要一直建立多個網路連線，這個是最主要效能提昇的改善。
- 優先權設計，伺服器可決定例如CSS或Javascript檔案哪些要先傳送。
- 連線多工，併發請求資源。
- 採用 HPACK 壓縮技術將標頭進行壓縮
使用 Persistent Object Cache
由於 TTFB 的計算是包含從客戶端發起請求到伺服器的回應時間，所以想辦法讓伺服器更快的回應也是解決的辦法之一，好消息是 wordpress 內建 object cache 機制，可將資料庫查詢結果儲存在記憶體，待下次有相同的查詢的時候直接從記憶體取用，不用再重新查詢資料庫來達到加速的效果，但鳥的是內建的 object cache 沒有儲存機制，所以一換頁這些快取就會遺失。我們可透過安裝 Persistent caching 外掛來解決這個問題，常見的儲存方式有使用 Redis（本站使用Redis）、Memcached 及 APCu 等方式，各位可參考 wordpress 提供的建議安裝外掛。
