Network Resource Timing 個人請求慢在哪

前言

若是咱們發現本身頁面加載慢，一般會打開DevTools的Network欄找到具體的慢的請求，那他到底慢在哪呢？

Timing包含的內容

1. Queuing
2. Stalled/Blocking
3. Proxy Negotiation
4. DNS Lookup
5. Initial Connection / Connecting
6. SSL
7. Request Sent / Sending
8. Waiting (TTFB)
9. Content Download / Downloading

一、Queuing

主要是資源加載的排隊

• 不可優化部分

  • 請求被渲染引擎推遲，如腳本/樣式會優先，圖片推遲。
  • 生成磁盤緩存條目所用的時間（一般很是迅速）。

• 可優化部分

  • 請求已被暫停，以等待將要釋放的不可用TCP套接字。

    瀏覽器線程池不是無限的，須要等待socket(TCP)釋放。
    
    合併小文件減小請求。

  • 請求被暫停，HTTP 1上，瀏覽器僅容許每一個源擁有六個TCP鏈接。

    主要是對服務器的保護。
    
    能夠把資源放到不一樣的域名上，參考`域名發散`。

二、Stalled/Blocking

請求等待發送所用的時間。Queuing中的全部緣由加上代理協商所用的任什麼時候間。

• 不可優化部分

  • Queuing中不可優化部分
  • 代理協商

• 可優化部分

  • Queuing中可優化部分
  • 相同的N次請求 緩存鎖，通常資源加載不會加載相同的，但ajax有可能，加timestamp可解決。

注意1：

Stalled是 Queuing以後的下一個狀態， Stalled開始時已經出隊，他們太顯著的差異（是否使用 proxy/ssl），他們之間沒有 and/or/parent/child的關係，有建議將 queueing/stalled更名爲 postponed/awaiting socket，具體能夠看看 chromium issue。

注意2：

另外，同源連接複用可能引起這樣的問題，因爲以前存在可用連接，此時瀏覽器但願重用以前的鏈接以節省資源，用以前的一個socket去發起鏈接，後收到服務器返回的連接已重置/不存在，再從本來可用連接中找可用連接，引起長時間等待，具體能夠看看 chrome-stalled-problem-resolving-process

三、Proxy Negotiation

與代理服務器鏈接協商所用的時間。

主要是瀏覽器經過代理服務器去服務目標服務，如本地代理Fiddler，通常沒法優化。

四、DNS Lookup

DNS查詢所用的時間

• 可優化部分

  • 不要有太多的新域名（可能遞歸查詢繞地球一圈），參考域名收斂。
  • 減小DNS解析路徑（若是內部有不少DNS服務器解析）。

五、Initial Connection / Connecting

創建鏈接所用的時間，包括TCP 握手/重試和協商 SSL的時間。

六、SSL

完成SSL握手所用的時間。

• 可優化部分

  • 須要區分好什麼資源須要https，什麼須要http。

七、Request Sent / Sending

發出網絡請求所用的時間。一般不到一毫秒。

八、Waiting (TTFB)

等待初始響應所用的時間，也稱爲至第一字節的時間。

• 可優化部分

  * 服務器響應速度
  
  * 服務器網絡帶寬

九、Content Download / Downloading

接收響應數據所用的時間。

• 可優化部分

  * 服務器網絡帶寬
  
  * 單個文件大小

其餘

大佬們總說要寫文章，第一次寫文章，就搬運了一下都感受好難哦。

有不對的地方歡迎大佬們指出。

參考

Understanding Resource Timing
Chrome Cache Lock
Chromium Issues 476749
chrome-stalled-problem-resolving-process