通過chrome瀏覽器分析網頁載入時間

標籤：用戶端   nat   develop   dev   ref   src   也有   限制   any   

今天趁著下班的時間看了下chrome瀏覽器的網頁載入時間分析工具和相關文檔，簡單寫點兒東西記錄一下。

以百度首頁載入為例，分析下一張圖片1.jgp（就是背景圖）的載入時間

看右側的Timing標籤，從下往上看各個階段：

最下面一行，Explanation是一個連結，它連結到了chrome對Timing解釋的文檔(從這裡可以看出chrome對開發人員真的很友好)，這張圖片載入總共花費的時間為：36.32ms。

Content Download，瀏覽器下載回應檔所花費的時間26.84ms，與本網有關係。

Waiting(TTFB)，從發起請求到接收到伺服器響應的首個位元組所花費的時間，它的主要組成部分：伺服器響應和網路傳輸（往返）。

Request sent. The request is being sent.  表示請求正在發出，這個是不佔用時間的。

Stalled。The request could be stalled for any of the reasons described in Queueing. 請求會因為各種原因的排隊被拖延，與請求隊列有關係。這張圖片的請求被拖延了1.48ms。

Queueing(排隊). The browser queues requests when: 瀏覽器會在以下情況下將某個請求排隊：

• There are higher priority requests. 有更高優先順序的請求
• There are already six TCP connections open for this origin, which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only. 在http1.0/1.1協議下，chrome對於同一網域名稱下的並發請求數（串連數）限制為6個。這麼做的原因：（1）是基於連接埠數量和線程切換開銷的考慮，瀏覽器不可能無限量的並發請求：由於 TCP 協議的限制，PC 端只有65536個連接埠可用以向外部發出串連，而作業系統對半開串連數也有限制以保護作業系統的 TCP\IP 協議棧資源不被迅速耗盡，因此瀏覽器不好發出太多的 TCP 串連，而是採取用完了之後再重複利用 TCP 串連或者乾脆重建立立 TCP 串連的方法。如果採用阻塞的通訊端模型來建立串連，同時發出多個串連會導致瀏覽器不得不多開幾個線程，而線程有時候算不得是輕量級資源，畢竟做一次環境切換開銷不小。（2）為了防止過多的並發導致伺服器崩潰，這是“有良知的tcp用戶端”對於伺服器的一種默契。詳見：瀏覽器允許的並發請求資源數是什麼意思？
• The browser is briefly allocating space in the disk cache 瀏覽器正在硬碟的緩衝上分配空間。

 

對於某個請求我們能夠最佳化的主要是TTFB，即，從發起請求到收到伺服器響應的時間間隔。也可以看出，它耗費的時間所佔的比例也比較大。那麼也就主要從伺服器響應和網路傳輸這兩方面來下手。如果只考慮網路傳輸這個因素，那麼壓縮傳輸資料，畢竟網路速度有限，減少傳送的資料位元組數可以加快傳輸速度。

通過chrome瀏覽器分析網頁載入時間