瀏覽器是怎樣工作的？

當瀏覽器傳送乙個請求到接受所有響應資料，這個過程發生了什麼？

開發模式下開啟航班管家 h5，通過dev-tool分析jipiao/檔案請求，看從connection start到content download期間，瀏覽器做了哪些事：

圖（1）請求並得到乙個網路資源/檔案的過程、及時間

queued.瀏覽器在以下事件發生時產生排隊請求：有更高優先順序許可權的請求；已經開啟 6 個同源限制的 tcp 鏈結；瀏覽器會短暫分配磁碟快取中的空間。

stalled.當產生queued 時，請求會被阻塞。

dns lookup.瀏覽器正在查詢請求的 ip 位址。

proxy negotiation.瀏覽器正在和**伺服器協商請求。

request sent.開始傳送請求。

waiting(ttfb).瀏覽器正在等待響應的第乙個位元組。ttfb表示time to first byte。它包括1次往返延遲的時間和服務端準備響應的時間。

content download.瀏覽器正在接收響應。

tl;dr

當html檔案的相應位元組被瀏覽器接受後（通常是8k乙個包），「渲染引擎」便開始工作了：

為了更好的使用者體驗（user experience），渲染引擎會解析一部分內容就顯示一部分，不會等到所有的 html 都被解析才開始構建和布局渲染樹。

簡要總結渲染引擎的工作：

html 的解析演算法並不是傳統的自頂向下或自底向上，它包含兩個步驟： tokenization 和 tree construction。這裡好像比較複雜（詳細內容請參考構建物件模型），但至少要明白解析的順序是自頂向下的。

當然，解析並不一直一帆風順，當遇到以下情況，解析過程將被阻塞：

樣式非同步過程，解析樣式不會阻塞dom構建，但會阻塞構建渲染樹。切記，cssom和dom共同構建渲染樹，但它們是分別構建的，誰也不影響誰。

解析指令碼

同步過程。當解析過程中遇到了標籤，會停止繼續解析直到指令碼執行完成。如果指令碼是外鏈資源，則需要等待資源載入並執行完畢才能繼續向下解析。

不過，在文件解析階段，指令碼會詢問樣式資訊。如果樣式尚未載入並解析，指令碼將得到錯誤的答案，顯然這會導致很多問題。所以，當有乙個仍在載入和解析的樣式表時，firefox將阻止所有指令碼。 webkit僅在指令碼嘗試訪問某些可能受解除安裝樣式表影響的樣式屬性時才阻止指令碼。

等等！！！既然載入指令碼會阻塞解析過程，那麼，為什麼後面的指令碼（或外部資源）會和當前指令碼一起載入呢？這裡不得不提到乙個優化技術——猜測預載入。

猜測預載入技術

現代主流瀏覽器都用到了這個優化技術。

當執行指令碼的時候，瀏覽器會啟動另乙個執行緒來向下解析文件，找到需要從網路載入的鏈結並載入它們，載入這些資源的請求是併發的。注意，這項技術不會修改 dom 樹，它僅解析對外部資源（如外部指令碼，樣式表和影象）的引用。

如果能看到這裡，那麼真是感謝你的耐心。

另外，我猜想上面大段大段的文字，未必能給你留下什麼印象。或許，下面這張圖更能表達本文的中心。

更多：詳談合成層（composite layers）

關鍵渲染路徑

how browsers work