參考：
1、https://developers.google.com/web/tools/chrome-devtools/network-performance/reference#timing
2、http://www.mamicode.com/info-detail-1015625.html
瀏覽器根據html中外連資源出現的順序，依次放入隊列（Queue）,然后根據優先級確定向服務器獲取資源的順序。同優先級的資源根據html中出現的先后順序來向服務器獲取資源
- Queueing. 出現下面的情況時，瀏覽器會把當前請求放入隊列中進行排隊
- 有更高優先級的請求時.
- 和目標服務器已經建立了6個TCP連接（最多6個，適用於HTTP/1.0和HTTP/1.1）
- 瀏覽器正在硬盤緩存上簡單的分配空間
- Stalled. 請求會因為上面的任一個原因而阻塞
- DNS Lookup. 瀏覽器起正在解析IP地址.
- Proxy negotiation. The browser is negotiating the request with a proxy server.
- Request sent. The request is being sent.
- ServiceWorker Preparation. The browser is starting up the service worker.
- Request to ServiceWorker. The request is being sent to the service worker.
- Waiting (TTFB). 瀏覽器等待響應第一個字節到達的時間. 包含來回的延遲時間和服務器准備響應的時間.
- Content Download. The browser is receiving the response.
- Receiving Push. The browser is receiving data for this response via HTTP/2 Server Push.
- Reading Push. The browser is reading the local data previously received.
-
DNS Lookup - 在瀏覽器和服務器進行通信之前, 必須經過DNS查詢, 將域名轉換成IP地址. 在這個階段, 你可以處理的東西很少. 但幸運的是, 並非所有的請求都需要經過這一階段.
-
Initial Connection - 在瀏覽器發送請求之前, 必須建立TCP連接. 這個過程僅僅發生在瀑布圖中的開頭幾行, 否則這就是個性能問題(后邊細說).
-
SSL/TLS Negotiation - 如果你的頁面是通過SSL/TLS這類安全協議加載資源, 這段時間就是瀏覽器建立安全連接的過程. 目前Google將HTTPS作為其 搜索排名因素 之一, SSL/TLS 協商的使用變得越來越普遍了.
-
Time To First Byte (TTFB) - TTFB 是瀏覽器請求發送到服務器的時間+服務器處理請求時間+響應報文的第一字節到達瀏覽器的時間. 我們用這個指標來判斷你的web服務器是否性能不夠, 或者說你是否需要使用CDN.
-
Downloading - 這是瀏覽器用來下載資源所用的時間. 這段時間越長, 說明資源越大. 理想情況下, 你可以通過控制資源的大小來控制這段時間的長度.
根據瀑布圖進行性能優化
那么我們如何是一個web頁面加載的更快並且創造更好的用戶體驗呢? 瀑布圖提供是三個直觀的玩意兒來協助我們達成這一目標:
-
首先, 減少所有資源的加載時間. 亦即減小瀑布圖的寬度. 瀑布圖越窄, 網站的訪問速度越快.
-
其次, 減少請求數量 也就是降低瀑布圖的高度. 瀑布圖越矮越好.
-
最后, 通過優化資源請求順序來加快渲染時間. 從圖上看, 就是將綠色的"開始渲染"線向左移. 這條線向左移動的越遠越好.
如圖所示，select2_metro.css在位置上要比avatar1_small.png和index.js靠后，但是優先級確實最高(Higthest-->High-->Medium-->Low),所以這個下載順序是：select2_metro.css-->index.js-->avatar1_small.png
Connection ID:可以看到總共有6個值--166718、166774、166775、166776、166777、166778，因為瀏覽器並發數limit是6；如果兩個url相同，就表示兩個資源的下載共用的同一個tcp長連接
