今天趁着下班的時間看了下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，即，從發起請求到收到服務器響應的時間間隔。從圖中也可以看出，它耗費的時間所占的比例也比較大。那么也就主要從服務器響應和網絡傳輸這兩方面來下手。如果只考慮網絡傳輸這個因素，那么壓縮傳輸數據，畢竟網絡速度有限，減少傳送的數據字節數可以加快傳輸速度。