Waiting (TTFB) 時間

什麼是 Waiting (TTFB) 時間

TTFB 是 Time to First Byte 的縮寫，指的是瀏覽器開始收到服務器響應數據的時間（後臺處理時間+重定向時間），是反映服務端響應速度的重要指標。就像你問朋友了一個問題，你的朋友思考了一下子纔給你答案，你朋友思考的時間就至關於 TTFB。你朋友思考的時間越短，就說明你朋友越聰明或者對你的問題越熟悉。對服務器來講，TTFB 時間越短，就說明服務器響應越快。

 

TTFB 時間多長算長？

由於每一個服務器的硬件和網絡環境都不盡相同，每一個服務器的 TTFB 時間也不相同。若是想知道你的服務器能夠優化到什麼程度，你們能夠上傳一些靜態的 HTML 頁面到服務器，而後打開這些靜態頁面，看一些這些頁面的 TTFB 時間，大多數服務器的 TTFB 時間都在 50 ms 一下，這個時間就是咱們優化時候能夠追求的時間。下面兩個圖中的 TTFB 時間分別是本站所在服務器的靜態和動態網頁 TTFB 等待時間。

根據咱們的測試，TTFB 時間若是超過了 500 ms，用戶在打開網頁的時候就會感受到明顯的等待。我麼能夠把 500 ms 以上認爲是 TTFB 時間過長。可見，WordPress 智庫的服務器還不算差。

 

TTFB 過長的緣由

咱們知道，對於動態網頁來講，服務器收到用戶打開一個頁面的請求時，首先要從數據庫中讀取該頁面須要的數據，而後把這些數據傳入到模版中，模版渲染後，再返回給用戶。因爲查詢數據和渲染模版須要須要必定的時間，在這個過程沒有完成以前，瀏覽器就一致處於等待接收服務器響應的狀態。有些服務的性能比較低，或者優化沒作好，這個時間就會比較長。

固然，若是服務器到用戶之間的網絡很差，（好比，服務器在歐洲，用戶在中國，用戶打開網頁的時候，請求須要跨越千山萬水才能達到服務器），服務器接收到用戶請求的時間過長，也是致使 TTFB 時間過長的緣由。

有時候，頁面在用戶的瀏覽器中保存了過多的 Cookie，每次請求，這些 Cookie 都要發送到服務器，服務器都要處理這些 Cookie，這也是致使 TTFB 時間過長的緣由之一。

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

知道了緣由，解決辦法就顯而易見了，那就是縮短服務器響應時間，最簡單直接而且有效的辦法就是使用緩存，把 PHP 和 MySQL 的執行時間最小化，一些緩存插件能夠把 SQL 查詢結果緩存起來，把幾十次查詢結果轉換爲幾回；一些緩存插件能夠直接把用戶所請求的頁面靜態化，用戶打開網頁時，至關於直接從服務器上下載了靜態頁面。

若是是網絡緣由，換一個服務器是比較直接的解決辦法。若是由於一些緣由不能換服務器，可使用一個 CDN，把頁面同步到離用戶比較近的 CDN 節點上，也是一個不錯的解決辦法。

若是是 Cookie 的緣由，能夠經過修改應用程序，刪除一些沒必要要的 Cookie，或者精簡 Cookie 內容，縮短 Cookie 的有效期等，都是解決辦法。

 

記錄一個問題吧。

新上線的應用，第一次上線部署了兩個節點，經過DMZ的NGINX映射出去的。

上線以後，第三天忽然發現訪問很慢，有50%的概率保持在7秒左右，經過日誌平臺觀察代碼處理時間在40ms左右。

打開F12，發現TTFB時間消耗了6秒。猜想nginx配置有問題，但是nginx配置是咱們寫好發給運維同事作的，不會出問題。

再猜是DMZ區到應用服務器的防火牆沒有打通。最後定位是這個緣由。

現象，偶爾訪問時間過長，NGINX  hash路由  消耗時間過長。

形成緣由，NGINX  Hash 路由 其中某一臺 沒法訪問，形成 迂迴訪問，消耗時間。（能夠經過curl命令直接在服務器上訪問，跳過nginx 而後再分析）