媒介

假如我們發明本身頁面加載慢，平常會翻開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

1、Queuing

主如果資本加載的列隊

• 不可優化部份

  • 要求被襯着引擎推延，如劇本/款式會優先，圖片推延。
  • 天生磁盤緩存條目所用的時候（平常異常敏捷）。

• 可優化部份

  • 要求已被停息，以守候將要開釋的不可用TCP套接字。

    瀏覽器線程池不是無窮的，須要守候socket(TCP)開釋。
    
    兼并小文件削減要求。
    

  • 要求被停息，HTTP 1上，瀏覽器僅許可每一個源具有六個TCP銜接。

    主如果對效勞器的庇護。
    
    能夠把資本放到差異的域名上，參考`域名發散`。
    

2、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

3、Proxy Negotiation

與代辦效勞器銜接協商所用的時候。

主如果瀏覽器經由過程代辦效勞器去效勞目的效勞，如當地代辦Fiddler，平常沒法優化。

4、DNS Lookup

DNS查詢所用的時候

• 可優化部份

  • 不要有太多的新域名（能夠遞歸查詢繞地球一圈），參考域名收斂。
  • 削減DNS剖析途徑（假如內部有許多DNS效勞器剖析）。

5、Initial Connection / Connecting

豎立銜接所用的時候，包含TCP 握手/重試和協商 SSL的時候。

6、SSL

完成SSL握手所用的時候。

• 可優化部份

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

7、Request Sent / Sending

發出收集要求所用的時候。平常不到一毫秒。

8、Waiting (TTFB)

守候初始相應所用的時候，也稱為至第一字節的時候。

• 可優化部份

  * 效勞器相應速度
  
  * 效勞器收集帶寬
  

9、Content Download / Downloading

吸收相應數據所用的時候。

• 可優化部份

  * 效勞器收集帶寬
  
  * 單個文件大小
  

其他

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

有不對的處所迎接大佬們指出。

參考

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