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

谷歌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	-	-

問題的根本原因也找到了,那麼解決方案也就應運而出了.
將資料展示的介面放在其他介面前面進行呼叫即可實現資料展示不被阻塞,頁面就會第一時間顯現出來,使得使用者體驗更好,專案優化完成.

如果錯誤,請指出!!!