谷歌chrome瀏覽器network中Stalled分析和優化

問題由來

最近項目上要求首頁的加載速度，查看瀏覽器的network發現接口加載速度非常慢。

問題解決思路

SSL

網上有人因為圖片加載,選擇關閉SSL.就不存在問題，速度非常快
原因:查詢相關資料使用ssl效率降低60%左右。
結果:SSL是一種安全協議(在此不做具體分析),不舍棄安全協議去優化性能

Network

Network中的瀑布流可直觀查看到接口調用詳細
本文主要從Network入手,並且逐步解決問題

分析過程

簡單列出 chrome network的功能

1. Name:表示加載的文件名。
2. Method:表示請求的方式。
3. Status:表示狀態碼（200為請求成功，304表示從緩存讀取）。
4. Type:表示文件的MIME Type的類型。
5. Initiator:表示發出這個文件請求的發出者。
6. Size:表示文件大小。
7. Time:表示每個請求的總時長。
8. Timeline:以圖表的形式顯示元素的請求和加載情況。

1.關閉從緩存加載,避免緩存導致的影響

取消勾選

2.從Network瀑布流中查看哪些接口的請求時間比較長

點擊Time從大到小排序
兩種圖表表達情況

圖一

圖二

圖一(前后端均需要優化)

后端:優化接口,優化sql語句,提升接口響應速度.但有時候確實因為數據量巨大,類似表格數據,后端查詢完畢還需要進行處理,所以耗時長
前端:最簡單的解決辦法就是減少數據量,例如限制一個范圍(時間、分頁處理)

圖二(前端優化)

先來看看Network上的詳細信息

關注紅框的兩個值Stalled、Waiting
實際上就是等待了Stalled(1.47S才開始正式請求數據),數據請求到完成的時間實際上很短

那么到底什么是Stalled呢? 具體我們去查詢資料分析分析

Stalled

Stalled也即是從TCP連接建立完成，到真正可以傳輸數據之間的時間差。先讓我們要分析TCP連接為什么要等待這么久才能用？我用Wireshark抓包發現(如下圖)，TCP連接過程中有多次重傳，直到達到最大重傳次數后連接被客戶端重置。

又有問題了!! 明明我的網絡很好,為什么會發生重傳呢？

TCP三次握手后，發送端發送數據后，一段時間內（不同的操作系統時間段不同）接收不到服務端ACK包，就會以 某一時間間隔(時間間隔一般為指數型增長)重新發送，從重傳開始到接收端正確響應的時間就是stalled階段。而重傳超過一定的次數（windows系統是5次），發送端就認為本次TCP連接已經down掉了，需要重新建立連接。 對比以下，沒有重傳的http請求過程。

總結一下：stalled階段時TCP連接的檢測過程，如果檢測成功就會繼續使用該TCP連接發送數據，如果檢測失敗就會重新建立TCP連接。所以出現stalled階段過長，往往是丟包所致，這也意味着網絡或服務端有問題。

上面也說過,網絡是沒有問題的,同時也確認過服務端沒有問題,那么總結的不就是有問題的嗎? 我們在分析下一般情況下stalledstalled的原因有哪些呢?

瀏覽器得到要發出這個請求的指令，到請求可以發出的等待時間，一般是代理協商、以及等待可復用的TCP連接釋放的時間，不包括DNS查詢、建立TCP連接等時間等。
瀏覽器對同一個主機域名的並發連接數有限制，因此如果當前的連接數已經超過上限，那么其余請求就會被阻塞，等待新的可用連接；此外腳本也會阻塞其他組件的下載；

也就是說根本問題是在於瀏覽器的底層上
瀏覽器對同一個主機域名的並發連接數有限制，因此如果當前的連接數已經超過上限，那么其余請求就會被阻塞，等待新的可用連接
我們還需注意的是腳本也會進行阻塞

瀏覽器對同一域名進行請求的最大並發連接數

瀏覽器版本	HTTP 1.0 服務器（寬帶連接）	HTTP 1.1 服務器（寬帶連接）	HTTP 1.0 服務器（撥號連接）	HTTP 1.1 服務器（撥號連接）
Internet Explorer 7 和早期版本	4	2	4	2
Internet Explorer 8	6	6	4	2
Internet Explorer 9	10	10	-	-
Internet Explorer 10	6	6	-	-
Internet Explorer 11	6	6	-	-
chrome、firefox	6	6	-	-

問題的根本原因也找到了,那么解決方案也就應運而出了.
將數據展示的接口放在其他接口前面進行調用即可實現數據展示不被阻塞,頁面就會第一時間顯現出來,使得用戶體驗更好,項目優化完成.

如果錯誤,請指出!!!