原文地址：Time to First Byte: What It Is and Why It Matters – CSS Wizardry – Web Performance Optimisation
中文翻譯：什么是 TTFB, 為什么 TTFB 很重要_YITA90的專欄-CSDN博客，有刪減?

引言

Time to First Byte(TTFB) 是一個前端開發人員很容易忽略的指標，因為它即將進入后端領域。但是，一個快的 TTFB 不一定意味著你會有一個快速的網站，但一個慢的 TTFB 一定會意味著網頁慢。

作為前端開發者，可能沒有能力獨自對 TTFB 進行改進。但必須要知道，高 TTFB 的問題會影響頁面性能。前端工程師所做的優化，比如優化圖片、清除關鍵路徑、異步加載網頁字體這些努力都會受到影響。所以應該優先消滅那些 TTFB 帶來的問題，而不應該忽略 TTFB 對頁面性能的影響。

?

什么是 TTFB？

TTFB 包含了許多不同的東西，很多人以為 TTFB 是花銷在服務器端的時間，這其實只是其中很少的一部分而已。TTFB 計算的是整個延遲的往返時間。 TTFB 不僅僅是服務器上花的時間，它還包括設備到服務器，再從服務器到設備的時間。

那 TTFB 究竟包含了哪些東西呢？下面是一個詳盡無遺的列表，順序無先后。

延遲
我們計算的是從服務器接收到請求到再到發出后的時間。倫敦的一臺設備請求紐約的一臺服務器，理論上最理想的環境，光纖速度是28毫秒，但實際情況可能接近75毫秒。這就是為什么我們要使用 CDN 的原因：即使在互聯網時代，在地理位置上離你的客戶更近也是有優勢的。

翻譯過來的，是指不同的線路、線路損耗，使用 CDN 很多時候是必須的。

路由
如果您正在使用 CDN ーー而且您應該這樣做! ーー利茲的一個客戶可能會被路由到 MAN 數據中心，結果發現他們請求的資源不在那個 PoP 的緩存中。 因此，它們將被路由到您的原始服務器，然后從那里檢索它。 所以如果你的源服務器是在弗吉尼亞州，將大幅增加 TTFB 的時間開銷。

翻譯過來的，其實就是不同的路由、不同的網之間的差距。

文件讀取
服務器只是從文件系統讀取靜態文件，如圖像或系統表，都是有代價的。這些都會被計算到你的 TTFB 時間中。

優先級HTTP/2 有一個(重新)優先級機制，它可以選擇在服務器上停止較低優先級的響應，同時發送較高優先級的響應。 撇開 H/2 優先級問題不談，即使 H/2 運行順利，這些預期的延遲也會給你的 TTFB 帶來影響。

運行時
運行時需要時間是顯而易見的，所以這可能是 TTFB 時間開銷中占比較重的。

數據庫查詢
頁面如果需要獲取來自數據庫的數據，那么在對數據庫進行檢索時將會產生時間成本，增加 TTFB 時間。

API 調用
如果您需要調用任何 API (內部或其他)來填充頁面，開銷將計入您的 TTFB。

服務器端渲染
服務器渲染一個頁面的成本可能是微不足道的，但它仍然會增加你的 TTFB 時間。

廉價的托管服務器
如果托管服務器的成本高于性能，那通常意味著你要與其他網站共享一個服務器，服務器性能會降低，可能會影響你接收請求的能力，也可能在運行應用程序時出現硬件供電不足。

DDoS 或高負載
與上一點類似，增加負載而無法自動擴容的應用程序會達到硬件基礎設施的極限，進而導致性能大幅下降。

WAFs 和負載均衡器
諸如 web 應用程序防火墻 或負載均衡器之類的服務放在你的應用程序之前也會對你的 TTFB 有所拖累。

CDN 的特點
盡管 CDN 是一個解決網絡請求問題的重要方案，但在某些情況下，他們可能會增加 TTFB 時間。 例如，請求折疊、邊緣端包含 等)

最后一英里延遲
當我們想到倫敦的一臺計算機訪問紐約的一臺服務器時，我們想象一下，如果我們暴力點，讓兩者是直接連接，行不行？事實上，從我們自己的路由器到我們的 ISP (互聯網服務提供商)，有一系列更加復雜的中介，從手機信號塔到海底電纜。最后一英里延遲處理的是到達連接終點前無法比擬的復雜連接。

0 延遲的 TTFB 是不可能存在的！所以我們需要注意的是，以上列表任意項不好，不代表會使得 TTFB 時間增加。但你看到的 TTFB 時長包含了上面各項內容。在這里我不單獨介紹某一項內容，只是介紹下這些都會影響到你的 TTFB 時長。所以現在想想，網頁加載成功簡直是太厲害了，堪稱奇跡。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的Time to First Byte（TTFB）与Web性能优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。