network工具功能強大，能夠讓我看到網頁加載的信息，比如加載時間，和先后順序，是否是並行加載，還是堵塞加載。
默認情況下有八列:
（1）.Name:表示加載的文件名。
（2）.Method:表示請求的方式。
（3）.Status:表示狀態碼（200為請求成功，304表示從緩存讀取）。
（4）.Type:表示文件的MIME Type的類型。
（5）.Initiator:表示發出這個文件請求的發出者。
（6）.Size:表示文件大小。
（7）.Time:表示每個請求的總時長。
（8）.Timeline:以圖表的形式顯示元素的請求和加載情況。
當然內容不僅僅先於以上8個，右擊上面八個任意一個選項卡可以彈出一個菜單，可以查看更多內容:
（1）.Stalled（阻塞）
一般常規的優化包括：css、js合並壓縮、圖片壓縮、雪碧圖、靜態資源全部上CDN，一般這些都做了但是慢的話，這是時候問題一般出在Stalled阻塞了，如下圖:
什么是stalled呢？下面是一段比較容易懂的解釋：
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.
也即是從TCP連接建立完成，到真正可以傳輸數據之間的時間差。先讓我們要分析TCP連接為什么要等待這么久才能用？用Wireshark抓包發現(如下圖)，TCP連接過程中有多次重傳，直到達到最大重傳次數后連接被客戶端重置。
為什么會發生重傳呢？
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連接等時間等。
優化措施：
1、將資源合理分布到多台主機上，可以提高並發數，但是增加並行下載數量也會增大 開銷，這取決於帶寬和CPU速度，過多的並行下載會降低性能；
2、腳本置於頁面底部；
（2）DNS Lookup（域名解析）
請求某域名下的資源，瀏覽器需要先通過DNS解析器得到該域名服務器的IP地址。在DNS查找完成之前，瀏覽器不能從主機名那里下載到任何東西。
優化措施：
1、利用DNS緩存（設置TTL時間）；
2、利用Connection:keep-alive特性建立持久連接，可以在當前連接上進行多個請求，無需再進行域名解析；
（3）Initial connection（初始化連接）
TCP建立連接的三次握手時間
（4）Request sent（發送請求）
請求第一個字節發出前到最后一個字節發出后的時間，也就是上傳時間。
發送HTTP請求的時間（從第一個bit到最后一個bit）
優化措施：
1、減少HTTP請求，可以使用CSS Sprites、內聯圖片、合並腳本和樣式表等；
2、對不常變化的組件添加長久的Expires頭（相當於設置久遠的過期時間），在后續的頁面瀏覽中可以避免不必要的HTTP請求；
（3）Waiting（等待響應）
請求發出后，到收到響應的第一個字節所花費的時間(Time To First Byte)。
通常是耗費時間最長的。從發送請求到收到響應之間的空隙，會受到線路、服務器距離等因素的影響。
優化措施：
1、使用CDN，將用戶的訪問指向距離最近的工作正常的緩存服務器上，由緩存服務器直接響應用戶請求，提高響應速度；
（4）Content Download（下載）
收到響應的第一個字節，到接受完最后一個字節的時間，就是下載時間。
下載HTTP響應的時間（包含頭部和響應體）
優化措施：
1、通過條件Get請求，對比If-Modified-Since和Last-Modified時間，確定是否使用緩存中的組件，服務器會返回“304Not Modified”狀態碼，減小響應的大小；
2、移除重復腳本，精簡和壓縮代碼，如借助自動化構建工具grunt、gulp等；
3、壓縮響應內容，服務器端啟用gzip壓縮，可以減少下載時間；