瀏覽器解析渲染以及頁面優化
瀏覽器對頁面的加載、解析以及渲染是一個非常復雜的話題，這里我只對這個過程做一個非常概括的總覽，以初步了解這些過程，對于前端編程如何優化頁面給予一些原理性的支撐。
為什么要了解這些過程
- 了解瀏覽器的資源加載，可以使我們在引入外部樣式、腳本資源時進行更合理的時機選擇
- 了解瀏覽器文檔解析，可以使我們在構建DOM結構，組織CSS選擇器等，選擇更為合理的寫法
- 了解瀏覽器結果渲染，讓我們在設置元素屬性，腳本操作盡量優化以減少和避免不必要的重繪和回流
以上三個過程并非完全獨立，而是會有交叉，存在一邊加載一邊解析一邊渲染的工作現象。
加載
從用戶輸入網址，這其后到獲得網頁文檔之前也包含了如下眾多步驟：
- DNS解析，會依次從緩存，本地Hosts，本地DNS服務器直至根DNS服務器，任何一級***結果則直接返回，此步驟獲得目標服務器IP
- 端口解析，從URL中獲得目標服務器端口號
- 瀏覽器建立一條與網頁服務器的TCP連接(三次握手)
- 瀏覽器向服務器發送一條HTTP請求報文
- 服務器執行一些邏輯如數據庫查詢并最終生成并返回HTTP響應報文
初步經過以上步驟，瀏覽器獲得一份HTML文檔，然后瀏覽器會對此文檔自上而下進行加載，加載過程中就同時進行解析和渲染。
加載過程中，遇到外部的CSS資源，瀏覽器會通過額外的資源線程發出請求，獲取CSS文件，同樣如果遇到圖片資源，瀏覽器會發出另一個請求，獲取圖片資源，這些請求都是異步的，并不影響HTML文檔繼續加載。但是如果遇到了JS資源，HTML文檔會暫停解析，要等待JS資源加載并解析執行完畢，才會重新恢復HTML文檔解析。
瀏覽器這樣設計的考量是JS很有可能修改DOM結構，這意味著JS腳本后的一些資源加載、文檔解析可能是不必要的工作。這里就衍生出常見的一條優化法則: 將腳本文件加載置于文檔末尾'body'閉合標簽之前，或者在腳本引入代碼上添加defer或async屬性，以表明它們是可以異步加載
此外，在HTTP1.X中，同一個域名下并行資源請求的數量是很有限的，不同瀏覽器的限制不一定一致，對于這一點又衍生出多條優化方案:
將資源請求合并，如利用雪碧圖將多個圖片合為一個圖片使用
啟用靜態資源專用域名，擴大瀏覽器同時進行資源請求的數量
雖然CSS資源的加載并不影響JS資源的加載，但是卻會影響JS的執行:
這是因為JS內部可能會執行一些依賴于CSS樣式的操作，如獲得元素尺寸，所以JS執行前，瀏覽器務必保證CSS資源下載和解析完成。所以如果有需要提前執行的JS腳本，可以將JS引入置于CSS引入之前。
解析
瀏覽器解析HTML文檔主要包含如下幾個部分:
- 將HTML文檔解析為DOM Tree，是由DOM元素以及屬性節點組成，樹的根是Document對象
- 將CSS解析為樣式表對象，是CSS選擇器以及對象CSS規則的集合
- JS腳本解析，可能會對DOM Tree以及元素樣式進行更改，并最終反映到DOM Tree和CSS樣式表對象的更新里面
渲染
此過程即為瀏覽器構建渲染樹(Render Tree)的過程，渲染樹是DOM樹的可視化表示，是DOM數與樣式表對象的結合，所以DOM樹中一些不可見元素不會插入到渲染樹中，如 <head> 或 display:none 的元素等。一些脫離了文檔流的元素(使用了絕對或浮動的元素等)在兩棵樹上的位置不完全一致，渲染樹會標識出真實的位置，而只在原有位置放置占位標識。
渲染過程中，瀏覽器要為每個元素找出在樣式表對象中定義的不定數量的樣式規則。這里就需要指出CSS選擇器匹配的問題，多重選擇器是從右向左進行匹配，選擇器太深不利于樣式查找。
渲染樹創建完畢后，則繼續進行布局(Layout)。這個過程根據渲染對象的信息，計算出每個渲染對象的位置、尺寸，將其放置在瀏覽器窗口的正確位置。如果在布局完成之后又進行了DOM修改，這時候可能需要重新布局。每個渲染對象都有其自身的布局方法，同樣渲染樹的布局可以是全局也可以是局部，比如窗口尺寸改變或修改根元素尺寸或字體大小等，將會帶來全局的重新布局，如果只改變了內部某一塊渲染對象，則可能帶來一個局部重新布局。
布局完成之后，瀏覽器會遍歷上步獲得的呈現樹，不斷調用呈現器的繪制方法，將對應呈現器的內容顯示在屏幕上。
下圖指示了WebKit瀏覽器解析渲染的過程
此外，還需要說明兩個概念， 重繪(Repaint) 和 回流(Reflow)
Repaint: 不影響布局的屬性變更，如背景色
Reflow: 元素的幾何尺寸變了，需要重新驗證并計算Render Tree。是Render Tree的一部分或全部發生了變化。這就是Reflow，或是Layout
Reflow的成本比Repaint的成本高得多的多。DOM Tree里的每個結點都會有reflow方法，一個結點的reflow很有可能導致子結點，甚至父點以及同級結點的reflow。在一些高性能的電腦上也許還沒什么，但是如果reflow發生在手機上，那么這個過程是非常痛苦和耗電的。 所以，下面這些動作有很大可能會是成本比較高的。
當你增加、刪除、修改DOM結點時，會導致Reflow或Repaint
當你移動DOM的位置，或是搞個動畫的時候。
當你修改CSS樣式的時候。
當你Resize窗口的時候（移動端沒有這個問題），或是滾動的時候。
當你修改網頁的默認字體時。
display:none會觸發reflow，而visibility:hidden只會觸發repaint，因為沒有發現位置變化。
基本上來說，reflow有如下的幾個原因：
Initial: 網頁初始化的時候。
Incremental: 一些Javascript在操作DOM Tree時。
Resize: 其些元件的尺寸變了。
Style Change: 如果CSS的屬性發生變化了。
Dirty: 幾個Incremental的reflow發生在同一個frame的子樹上。
瀏覽器對于頻繁的重繪和回流做了一些優化，比如，瀏覽器會把回流操作積攢一批，然后做一次回流，這又叫異步回流或增量異步回流。但是有些情況瀏覽器是不會這么做的，比如：resize窗口，改變了頁面默認的字體，等。對于這些操作，瀏覽器會馬上進行回流。
頁面渲染優化
雖然瀏覽器已經極盡所能會對頁面渲染做一些針對性的優化，但是在了解瀏覽器的文檔加載渲染和解析過程之后，我們需要對自己編寫的代碼做一些相對應的優化和更佳的實踐:
簡化DOM層次結構
簡化CSS選擇器結構
腳本后置
少量首屏樣式可內聯
腳本中減少不必要的DOM操作，盡量緩存DOM查找以及DOM樣式信息
盡量通過修改類名或動畫來修改元素樣式
動畫盡量使用在絕對或固定定位元素上
屏幕外不可見部分或滾動時的動畫盡量停止
