瀏覽器的主要功能是將用戶選擇的web資源呈現出來，它從服務器請求資源，并將得到的資源（HTML，PDF，image等等）顯示在瀏覽器窗口。那么從用戶敲入URL到完整渲染出來，經歷了什么過程呢？也就是說整個瀏覽器的工作流程是怎樣的呢？
整個過程大致如下：
1. 輸入URL，瀏覽器根據域名尋找IP地址
2. 瀏覽器發送一個HTTP請求給服務器，如果服務器返回以301之類的重定向，瀏覽器根據相應頭中的location再次發送請求
3. 服務器接受請求，處理請求生成html代碼，返回給瀏覽器，這時的html頁面代碼可能是經過壓縮的
4. 瀏覽器接收服務器響應結果，如果有壓縮則首先進行解壓處理
5. 瀏覽器開始顯示HTML
6. 瀏覽器發送請求，以獲取嵌入在HTML中的對象。在瀏覽器顯示HTML時，它會注意到需要獲取其他地址內容的標簽。
這時，瀏覽器會發送一個獲取請求來重新獲得這些文件——包括CSS/JS/圖片等資源，這些資源的地址都要經歷一個和HTML讀取類似的過程。所以瀏覽器會在DNS中查找這些域名，發送請求，重定向等等…
那么，一個頁面，究竟是如何從我們輸入一個網址到最后完整的呈現在我們面前的呢？還需要了解一下瀏覽器是如何渲染的。
首先是用戶輸入url，瀏覽器通過DNS查詢要訪問頁面的IP，查詢到后，瀏覽器會替用戶去向這個IP地址發送請求拉取html文件，瀏覽器會派GUI線程去解析加載回來的html文件
html解析過程：01機器碼-》charter字符-》tokens令牌-》node節點-》dom樹
解析CSS，構建CSSOM
有了骨骼以后，接下來就是確定長相了，這是CSS要做的事情。和解析HTML類似，CSS解析各種樣式信息，生成網頁的“外觀”。但是有個問題，CSSA（class選擇器）說，我喜歡藍色，我家網頁的所有文字都要是藍色。CSSB（id選擇器）就不樂意了，憑啥啊，我喜歡紅色，我家的標題必須是紅色。由于id選擇器是親生的，那就標題是紅色的吧，于是不同選擇器就有了不同的權重。最后生成CSSOM
因為瀏覽器解析文檔，如果遇到請求外部資源時，如圖像,iconfont,JS等。瀏覽器將下載該資源。請求過程是異步的，并不會影響HTML文檔進行加載，當遇到 <script>標簽的時候，會立即解析腳本，停止解析文檔（因為JS可以操作DOM和CSS，可能會改動DOM和CSS，所以繼續解析會造成浪費）。如果腳本是外部的，會等待腳本下載完畢，再繼續解析文檔。所以常見的做法是將js放到頁腳部分。
構建Render Tree（呈現樹）
骨骼和長相都有了，那就組合到一起唄，DOM和CSSOM根據一定的規則組合起來生成了Render Tree。
布局（Layout）
創建渲染樹后，接下來正式開工，確定各個元素的位置，包括元素在視圖中的位置以及自身的大小，將其安置在瀏覽器的正確位置。
繪制（Painting）
這個階段，瀏覽器會遍歷呈現樹，并調用呈現器的“paint”方法，將前期所有的工作結合到一起，將網頁的內容呈現出來。如果網頁只是HTML+CSS，那么可能就到此結束了，but還有神奇的JS呢，請看回流和重繪。
回流（Reflow）和重繪（Repaint）
如果這個時候我寫了用JS操作了DOM，將網頁的所有元素設置float:left，那么問題來了，上面兩步的工作白干了，推翻從新再來。如果將所有元素的顏色改變了（并沒有改變結構），比如color:red，還好還好，上面一步的工作白干，推翻重來?？梢韵胂笠幌拢阈列量嗫嗉影嘁粋€月終于完成工作，產品經理來了一句：“好像要改一下需求…”
頁面在首次加載時必然會經歷reflow和repaint。reflow和repaint過程是非常消耗性能的，尤其是在移動設備上，它會破壞用戶體驗，有時會造成頁面卡頓。所以我們應該盡可能少的減少reflow和repaint。
所以，盡可能少操作DOM，提升網頁的性能。
總結一下:
1. 解析HTML
2. 構建DOM樹
3. DOM樹與CSS樣式進行附著構造呈現樹（render樹）
4. 布局
5. 繪制
上述這個過程是逐步完成的，為了更好的用戶體驗，渲染引擎將會盡可能早的將內容呈現到屏幕上，并不會等到所有的html都解析完成之后再去構建和布局render樹。它是解析完一部分內容就顯示一部分內容，同時，可能還在通過網絡下載其余內容。
