現在我們需要填充樣式結構。首先要填充的是 margin 結構。由于最后的規則節點 (F) 并沒有添加到 margin 結構，我們需要上溯規則樹，直至找到在先前節點插入中計算過的緩存結構，然后使用該結構。我們會在指定 margin 規則的最上層節點（即 B 節點）上找到該結構。

我們已經有了 color 結構的定義，因此不能使用緩存的結構。由于 color 有一個屬性，我們無需上溯規則樹以填充其他屬性。我們將計算端值（將字符串轉化為 RGB 等）并在此節點上緩存經過計算的結構。

第二個 元素處理起來更加簡單。我們將匹配規則，最終發現它和之前的 span 一樣指向規則 G。由于我們找到了指向同一節點的同級，就可以共享整個樣式上下文了，只需指向之前 span 的上下文即可。

對于包含了繼承自父代的規則的結構，緩存是在上下文樹中進行的（事實上 color 屬性是繼承的，但是 Firefox 將其視為 reset 屬性，并緩存到規則樹上）
所以生成的上下文樹如下：

樣式對象具有與每個可視化屬性一一對應的屬性（均為 CSS 屬性但更為通用）。如果某個屬性未由任何匹配規則所定義，那么部分屬性就可由父代元素樣式對象繼承。其他屬性具有默認值。
如果定義不止一個，就會出現問題，需要通過層疊順序來解決。

一些例子：

 *             {}  /* a=0 b=0 c=0 d=0 -> specificity = 0,0,0,0 */
 li            {}  /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,1 */
 li:first-line {}  /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */
 ul li         {}  /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */
 ul ol+li      {}  /* a=0 b=0 c=0 d=3 -> specificity = 0,0,0,3 */
 h1 + *[rel=up]{}  /* a=0 b=0 c=1 d=1 -> specificity = 0,0,1,1 */
 ul ol li.red  {}  /* a=0 b=0 c=1 d=3 -> specificity = 0,0,1,3 */
 li.red.level  {}  /* a=0 b=0 c=2 d=1 -> specificity = 0,0,2,1 */
 #x34y         {}  /* a=0 b=1 c=0 d=0 -> specificity = 0,1,0,0 */
 style=""          /* a=1 b=0 c=0 d=0 -> specificity = 1,0,0,0 */

利用上面的方法，基本可以快速確定不同選擇器的優先級。

創建渲染樹后，下一步就是布局（Layout）,或者叫回流（reflow,relayout），這個過程就是通過渲染樹中渲染對象的信息，計算出每一個渲染對象的位置和尺寸，將其安置在瀏覽器窗口的正確位置，而有些時候我們會在文檔布局完成后對DOM進行修改，這時候可能需要重新進行布局，也可稱其為回流，本質上還是一個布局的過程，每一個渲染對象都有一個布局或者回流方法，實現其布局或回流。

對渲染樹的布局可以分為全局和局部的，全局即對整個渲染樹進行重新布局，如當我們改變了窗口尺寸或方向或者是修改了根元素的尺寸或者字體大小等；而局部布局可以是對渲染樹的某部分或某一個渲染對象進行重新布局。

大多數web應用對DOM的操作都是比較頻繁，這意味著經常需要對DOM進行布局和回流，而如果僅僅是一些小改變，就觸發整個渲染樹的回流，這顯然是不好的，為了避免這種情況，瀏覽器使用了臟位系統，只有一個渲染對象改變了或者某渲染對象及其子渲染對象臟位值為”dirty”時，說明需要回流。

表示需要布局的臟位值有兩種：

“dirty”–自身改變，需要回流

“children are dirty”–子節點改變，需要回流

布局是一個從上到下，從外到內進行的遞歸過程，從根渲染對象，即對應著HTML文檔根元素，然后下一級渲染對象，如對應著元素，如此層層遞歸，依次計算每一個渲染對象的幾何信息（位置和尺寸）。

每一個渲染對象的布局流程基本如：

1.計算此渲染對象的寬度（width）；

2.遍歷此渲染對象的所有子級，依次：

2.1設置子級渲染對象的坐標

2.2判斷是否需要觸發子渲染對象的布局或回流方法，計算子渲染對象的高度（height）

3.設置此渲染對象的高度：根據子渲染對象的累積高，margin和padding的高度設置其高度；

4.設置此渲染對象臟位值為false。

在繪制階段，系統會遍歷呈現樹，并調用呈現器的“paint”方法，將呈現器的內容顯示在屏幕上。繪制工作是使用用戶界面基礎組件完成的。

CSS2 規范定義了繪制流程的順序。繪制的順序其實就是元素進入堆棧樣式上下文的順序。這些堆棧會從后往前繪制，因此這樣的順序會影響繪制。塊呈現器的堆棧順序如下：

背景顏色

背景圖片

邊框

子代

輪廓

這里還要說兩個概念，一個是Reflow，另一個是Repaint。這兩個不是一回事。
Repaint ——屏幕的一部分要重畫，比如某個CSS的背景色變了。但是元素的幾何尺寸沒有變。
Reflow 元件的幾何尺寸變了，我們需要重新驗證并計算Render Tree。是Render Tree的一部分或全部發生了變化。這就是Reflow，或是Layout。（HTML使用的是flow based layout，也就是流式布局，所以，如果某元件的幾何尺寸發生了變化，需要重新布局，也就叫reflow）reflow 會從這個root frame開始遞歸往下，依次計算所有的結點幾何尺寸和位置，在reflow過程中，可能會增加一些frame，比如一個文本字符串必需被包裝起來。

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。其些元件的尺寸變了。

StyleChange。如果CSS的屬性發生變化了。

Dirty。幾個Incremental的reflow發生在同一個frame的子樹上。

看幾個例子：

$("body").css("color", "red"); // repaint
$("body").css("margin", "2px"); // reflow, repaint

var bstyle = document.body.style; // cache

bstyle.padding = "20px"; // reflow, repaint
bstyle.border = "10px solid red"; //  再一次的 reflow 和 repaint

bstyle.color = "blue"; // repaint
bstyle.backgroundColor = "#fad"; // repaint

bstyle.fontSize = "2em"; // reflow, repaint

// new DOM element - reflow, repaint
document.body.appendChild(document.createTextNode("dude!"));

當然，我們的瀏覽器是聰明的，它不會像上面那樣，你每改一次樣式，它就reflow或repaint一次。一般來說，瀏覽器會把這樣的操作積攢一批，然后做一次reflow，這又叫異步reflow或增量異步reflow。但是有些情況瀏覽器是不會這么做的，比如：resize窗口，改變了頁面默認的字體，等。對于這些操作，瀏覽器會馬上進行reflow。

但是有些時候，我們的腳本會阻止瀏覽器這么干，比如：如果我們請求下面的一些DOM值：

offsetTop, offsetLeft, offsetWidth, offsetHeight
scrollTop/Left/Width/Height
clientTop/Left/Width/Height
IE中的 getComputedStyle(), 或 currentStyle

因為，如果我們的程序需要這些值，那么瀏覽器需要返回最新的值，而這樣一樣會flush出去一些樣式的改變，從而造成頻繁的reflow/repaint。

頁面的渲染詳細過程可以通過chrome開發者工具中的timeline查看

發起請求；

解析HTML；

解析樣式；

執行JavaScript；

布局；

繪制

瀏覽器對上文介紹的關鍵渲染路徑進行了很多優化，針對每一次變化產生盡量少的操作，還有優化判斷重新繪制或布局的方式等等。
在改變文檔根元素的字體顏色等視覺性信息時，會觸發整個文檔的重繪，而改變某元素的字體顏色則只觸發特定元素的重繪；改變元素的位置信息會同時觸發此元素（可能還包括其兄弟元素或子級元素）的布局和重繪。某些重大改變，如更改文檔根元素的字體尺寸，則會觸發整個文檔的重新布局和重繪，據此及上文所述，推薦以下優化和實踐：

HTML文檔結構層次盡量少，最好不深于六層；

腳本盡量后放，放在前即可；

少量首屏樣式內聯放在標簽內；

樣式結構層次盡量簡單；

在腳本中盡量減少DOM操作，盡量緩存訪問DOM的樣式信息，避免過度觸發回流；

減少通過JavaScript代碼修改元素樣式，盡量使用修改class名方式操作樣式或動畫；

動畫盡量使用在絕對定位或固定定位的元素上；

隱藏在屏幕外，或在頁面滾動時，盡量停止動畫；

盡量緩存DOM查找，查找器盡量簡潔；

涉及多域名的網站，可以開啟域名預解析

瀏覽器渲染是個很繁瑣的過程，其中每一步都有對應的算法。
了解渲染過程原理可以有針對的性能優化，而且也可以懂得一些基本的要求和規范的原理。
最后文章中間很多語句都是直接復制的原文，自己的語言概況還是不及原文精彩。

《How Browser Work》

瀏覽器的工作原理：新式網絡瀏覽器幕后揭秘

瀏覽器渲染原理

淺析前端頁面渲染機制

瀏覽器 渲染,繪制流程及性能優化

優化CSS重排重繪與瀏覽器性能