TTFB 是 Time to First Byte 的縮寫，指的是瀏覽器開始收到服務(wù)器響應(yīng)數(shù)據(jù)的時(shí)間（后臺(tái)處理時(shí)間+重定向時(shí)間），是反映服務(wù)端響應(yīng)速度的重要指標(biāo)。就像你問朋友了一個(gè)問題，你的朋友思考了一會(huì)兒才給你答案，你朋友思考的時(shí)間就相當(dāng)于 TTFB。你朋友思考的時(shí)間越短，就說明你朋友越聰明或者對(duì)你的問題越熟悉。對(duì)服務(wù)器來說，TTFB 時(shí)間越短，就說明服務(wù)器響應(yīng)越快。

TTFB 時(shí)間多長算長？

因?yàn)槊總€(gè)服務(wù)器的硬件和網(wǎng)絡(luò)環(huán)境都不盡相同，每個(gè)服務(wù)器的 TTFB 時(shí)間也不相同。如果想知道你的服務(wù)器可以優(yōu)化到什么程度，大家可以上傳一些靜態(tài)的 HTML 頁面到服務(wù)器，然后打開這些靜態(tài)頁面，看一些這些頁面的 TTFB 時(shí)間，大多數(shù)服務(wù)器的 TTFB 時(shí)間都在 50 ms 一下，這個(gè)時(shí)間就是我們優(yōu)化時(shí)候可以追求的時(shí)間。下面兩個(gè)圖中的 TTFB 時(shí)間分別是本站所在服務(wù)器的靜態(tài)和動(dòng)態(tài)網(wǎng)頁 TTFB 等待時(shí)間。

根據(jù)我們的測試，TTFB 時(shí)間如果超過了 500 ms，用戶在打開網(wǎng)頁的時(shí)候就會(huì)感覺到明顯的等待。我么可以把 500 ms 以上認(rèn)為是 TTFB 時(shí)間過長?？梢?，WordPress 智庫的服務(wù)器還不算差。

TTFB 過長的原因

我們知道，對(duì)于動(dòng)態(tài)網(wǎng)頁來說，服務(wù)器收到用戶打開一個(gè)頁面的請(qǐng)求時(shí)，首先要從數(shù)據(jù)庫中讀取該頁面需要的數(shù)據(jù)，然后把這些數(shù)據(jù)傳入到模版中，模版渲染后，再返回給用戶。由于查詢數(shù)據(jù)和渲染模版需要需要一定的時(shí)間，在這個(gè)過程沒有完成之前，瀏覽器就一致處于等待接收服務(wù)器響應(yīng)的狀態(tài)。有些服務(wù)的性能比較低，或者優(yōu)化沒做好，這個(gè)時(shí)間就會(huì)比較長。

當(dāng)然，如果服務(wù)器到用戶之間的網(wǎng)絡(luò)不好，（比如，服務(wù)器在歐洲，用戶在中國，用戶打開網(wǎng)頁的時(shí)候，請(qǐng)求需要跨越千山萬水才能達(dá)到服務(wù)器），服務(wù)器接收到用戶請(qǐng)求的時(shí)間過長，也是導(dǎo)致 TTFB 時(shí)間過長的原因。

有時(shí)候，頁面在用戶的瀏覽器中保存了過多的 Cookie，每次請(qǐng)求，這些 Cookie 都要發(fā)送到服務(wù)器，服務(wù)器都要處理這些 Cookie，這也是導(dǎo)致 TTFB 時(shí)間過長的原因之一。

Waiting (TTFB) 時(shí)間過長的解決辦法

知道了原因，解決辦法就顯而易見了，那就是縮短服務(wù)器響應(yīng)時(shí)間，最簡單直接并且有效的辦法就是使用緩存，把 PHP 和 MySQL 的執(zhí)行時(shí)間最小化，一些緩存插件可以把 SQL 查詢結(jié)果緩存起來，把幾十次查詢結(jié)果轉(zhuǎn)換為幾次；一些緩存插件可以直接把用戶所請(qǐng)求的頁面靜態(tài)化，用戶打開網(wǎng)頁時(shí)，相當(dāng)于直接從服務(wù)器上下載了靜態(tài)頁面。

如果是網(wǎng)絡(luò)原因，換一個(gè)服務(wù)器是比較直接的解決辦法。如果因?yàn)橐恍┰虿荒軗Q服務(wù)器，可以使用一個(gè) CDN，把頁面同步到離用戶比較近的 CDN 節(jié)點(diǎn)上，也是一個(gè)不錯(cuò)的解決辦法。

如果是 Cookie 的原因，可以通過修改應(yīng)用程序，刪除一些不必要的 Cookie，或者精簡 Cookie 內(nèi)容，縮短 Cookie 的有效期等，都是解決辦法。

記錄一個(gè)問題吧。

新上線的應(yīng)用，第一次上線部署了兩個(gè)節(jié)點(diǎn)，通過DMZ的NGINX映射出去的。

上線之后，第三天突然發(fā)現(xiàn)訪問很慢，有50%的幾率保持在7秒左右，通過日志平臺(tái)觀察代碼處理時(shí)間在40ms左右。

打開F12，發(fā)現(xiàn)TTFB時(shí)間消耗了6秒。猜測nginx配置有問題，可是nginx配置是我們寫好發(fā)給運(yùn)維同事做的，不會(huì)出問題。

再猜是DMZ區(qū)到應(yīng)用服務(wù)器的防火墻沒有打通。最后定位是這個(gè)原因。

現(xiàn)象，偶爾訪問時(shí)間過長，NGINX  hash路由  消耗時(shí)間過長。

造成原因，NGINX  Hash 路由 其中某一臺(tái) 無法訪問，造成迂回訪問，消耗時(shí)間。（可以通過curl命令直接在服務(wù)器上訪問，跳過nginx 然后再分析）