原文地址：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) 是一個前端開發(fā)人員很容易忽略的指標(biāo)，因?yàn)樗磳⑦M(jìn)入后端領(lǐng)域。但是，一個快的 TTFB 不一定意味著你會有一個快速的網(wǎng)站，但一個慢的 TTFB 一定會意味著網(wǎng)頁慢。

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

?

什么是 TTFB？

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

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

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

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

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

翻譯過來的，其實(shí)就是不同的路由、不同的網(wǎng)之間的差距。

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

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

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

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

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

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

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

DDoS 或高負(fù)載
與上一點(diǎn)類似，增加負(fù)載而無法自動擴(kuò)容的應(yīng)用程序會達(dá)到硬件基礎(chǔ)設(shè)施的極限，進(jìn)而導(dǎo)致性能大幅下降。

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

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

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。