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

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

?

什么是 TTFB？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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