network工具功能強大，可以讓我看到網頁加載的信息，好比加載時間，和前後順序，是不是並行加載，仍是堵塞加載。 
默認狀況下有八列: （1）.Name:表示加載的文件名。 （2）.Method:表示請求的方式。 （3）.Status:表示狀態碼（200爲請求成功，304表示從緩存讀取）。 （4）.Type:表示文件的MIME Type的類型。 （5）.Initiator:表示發出這個文件請求的發出者。 （6）.Size:表示文件大小。 （7）.Time:表示每一個請求的總時長。 （8）.Timeline:以圖表的形式顯示元素的請求和加載狀況。 固然內容不只僅先於以上8個，右擊上面八個任意一個選項卡能夠彈出一個菜單，能夠查看更多內容: css
（1）.Stalled（阻塞）
通常常規的優化包括：css、js合併壓縮、圖片壓縮、雪碧圖、靜態資源所有上CDN，通常這些都作了可是慢的話，這是時候問題通常出在Stalled阻塞了，以下圖: 什麼是stalled呢？下面是一段比較容易懂的解釋：html
Time the request spent waiting before it could be sent. This time is inclusive of any time spent in proxy negotiation.Additionally, this time will include when the browser is waiting for an already established connection to become available for re-use, obeying Chrome’s maximum six TCP connection per origin rule.gulp
也便是從TCP鏈接創建完成，到真正能夠傳輸數據之間的時間差。先讓咱們要分析TCP鏈接爲何要等待這麼久才能用？用Wireshark抓包發現(以下圖)，TCP鏈接過程當中有屢次重傳，直到達到最大重傳次數後鏈接被客戶端重置。 爲何會發生重傳呢？windows
The sender waits for an ACK for the byte-range sent to the client and when not received, resends the packets, after a particular interval. After a certain number of retries, the host is considered to be 「down」 and the sender gives up and tears down the TCP connection.瀏覽器
TCP三次握手後，發送端發送數據後，一段時間內（不一樣的操做系統時間段不一樣）接收不到服務端ACK包，就會以 某一時間間隔(時間間隔通常爲指數型增加)從新發送，從重傳開始到接收端正確響應的時間就是stalled階段。而重傳超過必定的次數（windows系統是5次），發送端就認爲本次TCP鏈接已經down掉了，須要從新創建鏈接。 對比如下，沒有重傳的http請求過程。以下圖： stalled階段時TCP鏈接的檢測過程，若是檢測成功就會繼續使用該TCP鏈接發送數據，若是檢測失敗就會從新創建TCP鏈接。因此出現stalled階段過長，每每是丟包所致，這也意味着網絡或服務端有問題。緩存
另外，須要注意的是：瀏覽器對同一個主機域名的併發鏈接數有限制，所以若是當前的鏈接數已經超過上限，那麼其他請求就會被阻塞，等待新的可用鏈接；此外腳本也會阻塞其餘組件的下載，被阻塞的請求的stalled也會很長。服務器
總結一下： 1，單一服務發送時候stalled過長，每每是丟包所致，這也意味着網絡或服務端有問題。 2，多個服務併發致使stalled過長，是瀏覽器對同一個主機域名的併發鏈接數有限制，過長的請求是被阻塞了，處在隊列中等待tcp鏈接網絡
因此，stalled階段是瀏覽器獲得要發出這個請求的指令，到請求能夠發出的等待時間，通常是代理協商、以及等待可複用的TCP鏈接釋放的時間，不包括DNS查詢、創建TCP鏈接等時間等。併發
優化措施： 一、將資源合理分佈到多臺主機上，能夠提升併發數，可是增長並行下載數量也會增大 開銷，這取決於帶寬和CPU速度，過多的並行下載會下降性能； 二、腳本置於頁面底部；tcp
（2）DNS Lookup（域名解析）
請求某域名下的資源，瀏覽器須要先經過DNS解析器獲得該域名服務器的IP地址。在DNS查找完成以前，瀏覽器不能從主機名那裏下載到任何東西。
優化措施： 一、利用DNS緩存（設置TTL時間）； 二、利用Connection:keep-alive特性創建持久鏈接，能夠在當前鏈接上進行多個請求，無需再進行域名解析；
（3）Initial connection（初始化鏈接）
TCP創建鏈接的三次握手時間
（4）Request sent（發送請求）
請求第一個字節發出前到最後一個字節發出後的時間，也就是上傳時間。 發送HTTP請求的時間（從第一個bit到最後一個bit）
優化措施： 一、減小HTTP請求，可使用CSS Sprites、內聯圖片、合併腳本和樣式表等； 二、對不常變化的組件添加長久的Expires頭（至關於設置久遠的過時時間），在後續的頁面瀏覽中能夠避免沒必要要的HTTP請求；
（3）Waiting（等待響應）
請求發出後，到收到響應的第一個字節所花費的時間(Time To First Byte)。
一般是耗費時間最長的。從發送請求到收到響應之間的空隙，會受到線路、服務器距離等因素的影響。
優化措施： 一、使用CDN，將用戶的訪問指向距離最近的工做正常的緩存服務器上，由緩存服務器直接響應用戶請求，提升響應速度；
（4）Content Download（下載）
收到響應的第一個字節，到接受完最後一個字節的時間，就是下載時間。 下載HTTP響應的時間（包含頭部和響應體）
優化措施： 一、經過條件Get請求，對比If-Modified-Since和Last-Modified時間，肯定是否使用緩存中的組件，服務器會返回「304Not Modified」狀態碼，減少響應的大小； 二、移除重複腳本，精簡和壓縮代碼，如藉助自動化構建工具grunt、gulp等； 三、壓縮響應內容，服務器端啓用gzip壓縮，能夠減小下載時間；
原文出處：https://www.cnblogs.com/both-eyes/p/10573713.html