前言
瀏覽器的核心是指支援瀏覽器執行的最核心的程式，分為兩個部分的，一是渲染引擎，另一個是JS引擎。渲染引擎在不同的瀏覽器中也不是都相同的。目前市面上常見的瀏覽器核心可以分為這四種：Trident（IE）、Gecko（火狐）、Blink（Chrome、Opera）、Webkit（Safari）。這裡面大家最耳熟能詳的可能就是 Webkit 核心了，Webkit 核心是當下瀏覽器世界真正的霸主。 本文我們就以 Webkit 為例，對現代瀏覽器的渲染過程進行一個深度的剖析。
想閱讀更多優質文章請猛戳GitHub部落格，一年五十篇優質文章等著你！
頁面載入過程
在介紹瀏覽器渲染過程之前，我們簡明扼要介紹下頁面的載入過程，有助於更好理解後續渲染過程。
要點如下：
- 瀏覽器根據 DNS 伺服器得到域名的 IP 地址
- 向這個 IP 的機器傳送 HTTP 請求
- 伺服器收到、處理並返回 HTTP 請求
- 瀏覽器得到返回內容
例如在瀏覽器輸入https://juejin.im/timeline，然後經過 DNS 解析，juejin.im對應的 IP 是36.248.217.149（不同時間、地點對應的 IP 可能會不同）。然後瀏覽器向該 IP 傳送 HTTP 請求。
服務端接收到 HTTP 請求，然後經過計算（向不同的使用者推送不同的內容），返回 HTTP 請求，返回的內容如下：
其實就是一堆 HMTL 格式的字串，因為只有 HTML 格式瀏覽器才能正確解析，這是 W3C 標準的要求。接下來就是瀏覽器的渲染過程。
瀏覽器渲染過程
瀏覽器渲染過程大體分為如下三部分：
1）瀏覽器會解析三個東西：
- 一是HTML/SVG/XHTML，HTML字串描述了一個頁面的結構，瀏覽器會把HTML結構字串解析轉換DOM樹形結構。
- 二是CSS，解析CSS會產生CSS規則樹，它和DOM結構比較像。
- 三是Javascript指令碼，等到Javascript 指令碼檔案載入後， 通過 DOM API 和 CSSOM API 來操作 DOM Tree 和 CSS Rule Tree。
2）解析完成後，瀏覽器引擎會通過DOM Tree 和 CSS Rule Tree 來構造 Rendering Tree。
- Rendering Tree 渲染樹並不等同於DOM樹，渲染樹只會包括需要顯示的節點和這些節點的樣式資訊。
- CSS 的 Rule Tree主要是為了完成匹配並把CSS Rule附加上Rendering Tree上的每個Element（也就是每個Frame）。
- 然後，計算每個Frame 的位置，這又叫layout和reflow過程。
3）最後通過呼叫作業系統Native GUI的API繪製。
接下來我們針對這其中所經歷的重要步驟詳細闡述
構建DOM
瀏覽器會遵守一套步驟將HTML 檔案轉換為 DOM 樹。巨集觀上，可以分為幾個步驟：
- 瀏覽器從磁碟或網路讀取HTML的原始位元組，並根據檔案的指定編碼（例如 UTF-8）將它們轉換成字串。
在網路中傳輸的內容其實都是 0 和 1 這些位元組資料。當瀏覽器接收到這些位元組資料以後，它會將這些位元組資料轉換為字串，也就是我們寫的程式碼。
- 將字串轉換成Token，例如：
<html>、<body>等。Token中會標識出當前Token是“開始標籤”或是“結束標籤”亦或是“文字”等資訊。
這時候你一定會有疑問，節點與節點之間的關係如何維護？
事實上，這就是Token要標識“起始標籤”和“結束標籤”等標識的作用。例如“title”Token的起始標籤和結束標籤之間的節點肯定是屬於“head”的子節點。
上圖給出了節點之間的關係，例如：“Hello”Token位於“title”開始標籤與“title”結束標籤之間，表明“Hello”Token是“title”Token的子節點。同理“title”Token是“head”Token的子節點。
- 生成節點物件並構建DOM
事實上，構建DOM的過程中，不是等所有Token都轉換完成後再去生成節點物件，而是一邊生成Token一邊消耗Token來生成節點物件。換句話說，每個Token被生成後，會立刻消耗這個Token建立出節點物件。注意：帶有結束標籤標識的Token不會建立節點物件。
接下來我們舉個例子，假設有段HTML文字：
<html>
<head>
<title>Web page parsing</title>
</head>
<body>
<div>
<h1>Web page parsing</h1>
<p>This is an example Web page.</p>
</div>
</body>
</html>
複製程式碼上面這段HTML會解析成這樣：
構建CSSOM
DOM會捕獲頁面的內容，但瀏覽器還需要知道頁面如何展示，所以需要構建CSSOM。
構建CSSOM的過程與構建DOM的過程非常相似，當瀏覽器接收到一段CSS，瀏覽器首先要做的是識別出Token，然後構建節點並生成CSSOM。
注意：CSS匹配HTML元素是一個相當複雜和有效能問題的事情。所以，DOM樹要小，CSS儘量用id和class，千萬不要過渡層疊下去。
構建渲染樹
當我們生成 DOM 樹和 CSSOM 樹以後，就需要將這兩棵樹組合為渲染樹。
在這一過程中，不是簡單的將兩者合併就行了。渲染樹只會包括需要顯示的節點和這些節點的樣式資訊，如果某個節點是 display: none 的，那麼就不會在渲染樹中顯示。
我們或許有個疑惑：瀏覽器如果渲染過程中遇到JS檔案怎麼處理？
渲染過程中，如果遇到<script>就停止渲染，執行 JS 程式碼。因為瀏覽器渲染和 JS 執行共用一個執行緒，而且這裡必須是單執行緒操作，多執行緒會產生渲染 DOM 衝突。
JavaScript的載入、解析與執行會阻塞DOM的構建，也就是說，在構建DOM時，HTML解析器若遇到了JavaScript，那麼它會暫停構建DOM，將控制權移交給JavaScript引擎，等JavaScript引擎執行完畢，瀏覽器再從中斷的地方恢復DOM構建。
也就是說，如果你想首屏渲染的越快，就越不應該在首屏就載入 JS 檔案，這也是都建議將 script 標籤放在 body 標籤底部的原因。當然在當下，並不是說 script 標籤必須放在底部，因為你可以給 script 標籤新增 defer 或者 async 屬性（下文會介紹這兩者的區別）。
JS檔案不只是阻塞DOM的構建，它會導致CSSOM也阻塞DOM的構建。
原本DOM和CSSOM的構建是互不影響，井水不犯河水，但是一旦引入了JavaScript，CSSOM也開始阻塞DOM的構建，只有CSSOM構建完畢後，DOM再恢復DOM構建。
這是什麼情況？
這是因為JavaScript不只是可以改DOM，它還可以更改樣式，也就是它可以更改CSSOM。因為不完整的CSSOM是無法使用的，如果JavaScript想訪問CSSOM並更改它，那麼在執行JavaScript時，必須要能拿到完整的CSSOM。所以就導致了一個現象，如果瀏覽器尚未完成CSSOM的下載和構建，而我們卻想在此時執行指令碼，那麼瀏覽器將延遲指令碼執行和DOM構建，直至其完成CSSOM的下載和構建。也就是說，在這種情況下，瀏覽器會先下載和構建CSSOM，然後再執行JavaScript，最後在繼續構建DOM。
佈局與繪製
當瀏覽器生成渲染樹以後，就會根據渲染樹來進行佈局（也可以叫做迴流）。這一階段瀏覽器要做的事情是要弄清楚各個節點在頁面中的確切位置和大小。通常這一行為也被稱為“自動重排”。
佈局流程的輸出是一個“盒模型”，它會精確地捕獲每個元素在視口內的確切位置和尺寸，所有相對測量值都將轉換為螢幕上的絕對畫素。
佈局完成後，瀏覽器會立即發出“Paint Setup”和“Paint”事件，將渲染樹轉換成螢幕上的畫素。
以上我們詳細介紹了瀏覽器工作流程中的重要步驟，接下來我們討論幾個相關的問題：
幾點補充說明
1.async和defer的作用是什麼？有什麼區別?
接下來我們對比下 defer 和 async 屬性的區別：
其中藍色線代表JavaScript載入；紅色線代表JavaScript執行；綠色線代表 HTML 解析。
1）情況1<script src="script.js"></script>
沒有 defer 或 async，瀏覽器會立即載入並執行指定的指令碼，也就是說不等待後續載入的文件元素，讀到就載入並執行。
2）情況2<script async src="script.js"></script> (非同步下載)
async 屬性表示非同步執行引入的 JavaScript，與 defer 的區別在於，如果已經載入好，就會開始執行——無論此刻是 HTML 解析階段還是 DOMContentLoaded 觸發之後。需要注意的是，這種方式載入的 JavaScript 依然會阻塞 load 事件。換句話說，async-script 可能在 DOMContentLoaded 觸發之前或之後執行，但一定在 load 觸發之前執行。
3）情況3 <script defer src="script.js"></script>(延遲執行)
defer 屬性表示延遲執行引入的 JavaScript，即這段 JavaScript 載入時 HTML 並未停止解析，這兩個過程是並行的。整個 document 解析完畢且 defer-script 也載入完成之後（這兩件事情的順序無關），會執行所有由 defer-script 載入的 JavaScript 程式碼，然後觸發 DOMContentLoaded 事件。
defer 與相比普通 script，有兩點區別：載入 JavaScript 檔案時不阻塞 HTML 的解析，執行階段被放到 HTML 標籤解析完成之後。 在載入多個JS指令碼的時候，async是無順序的載入，而defer是有順序的載入。
2.為什麼操作 DOM 慢
把 DOM 和 JavaScript 各自想象成一個島嶼，它們之間用收費橋樑連線。——《高效能 JavaScript》
JS 是很快的，在 JS 中修改 DOM 物件也是很快的。在JS的世界裡，一切是簡單的、迅速的。但 DOM 操作並非 JS 一個人的獨舞，而是兩個模組之間的協作。
因為 DOM 是屬於渲染引擎中的東西，而 JS 又是 JS 引擎中的東西。當我們用 JS 去操作 DOM 時，本質上是 JS 引擎和渲染引擎之間進行了“跨界交流”。這個“跨界交流”的實現並不簡單，它依賴了橋接介面作為“橋樑”（如下圖）。
過“橋”要收費——這個開銷本身就是不可忽略的。我們每操作一次 DOM（不管是為了修改還是僅僅為了訪問其值），都要過一次“橋”。過“橋”的次數一多，就會產生比較明顯的效能問題。因此“減少 DOM 操作”的建議，並非空穴來風。
3.你真的瞭解迴流和重繪嗎
渲染的流程基本上是這樣（如下圖黃色的四個步驟）：1.計算CSS樣式 2.構建Render Tree 3.Layout – 定位座標和大小 4.正式開畫
注意：上圖流程中有很多連線線，這表示了Javascript動態修改了DOM屬性或是CSS屬性會導致重新Layout，但有些改變不會重新Layout，就是上圖中那些指到天上的箭頭，比如修改後的CSS rule沒有被匹配到元素。
這裡重要要說兩個概念，一個是Reflow，另一個是Repaint
- 重繪：當我們對 DOM 的修改導致了樣式的變化、卻並未影響其幾何屬性（比如修改了顏色或背景色）時，瀏覽器不需重新計算元素的幾何屬性、直接為該元素繪製新的樣式（跳過了上圖所示的迴流環節）。
- 迴流：當我們對 DOM 的修改引發了 DOM 幾何尺寸的變化（比如修改元素的寬、高或隱藏元素等）時，瀏覽器需要重新計算元素的幾何屬性（其他元素的幾何屬性和位置也會因此受到影響），然後再將計算的結果繪製出來。這個過程就是迴流（也叫重排）
我們知道，當網頁生成的時候，至少會渲染一次。在使用者訪問的過程中，還會不斷重新渲染。重新渲染會重複迴流+重繪或者只有重繪。 迴流必定會發生重繪，重繪不一定會引發迴流。重繪和迴流會在我們設定節點樣式時頻繁出現，同時也會很大程度上影響效能。迴流所需的成本比重繪高的多，改變父節點裡的子節點很可能會導致父節點的一系列迴流。
1）常見引起迴流屬性和方法
任何會改變元素幾何資訊(元素的位置和尺寸大小)的操作，都會觸發迴流，
- 新增或者刪除可見的DOM元素；
- 元素尺寸改變——邊距、填充、邊框、寬度和高度
- 內容變化，比如使用者在input框中輸入文字
- 瀏覽器視窗尺寸改變——resize事件發生時
- 計算 offsetWidth 和 offsetHeight 屬性
- 設定 style 屬性的值
2）常見引起重繪屬性和方法
3）如何減少迴流、重繪
- 使用 transform 替代 top
- 使用 visibility 替換 display: none ，因為前者只會引起重繪，後者會引發迴流（改變了佈局）
- 不要把節點的屬性值放在一個迴圈裡當成迴圈裡的變數。
for(let i = 0; i < 1000; i++) {
// 獲取 offsetTop 會導致迴流，因為需要去獲取正確的值
console.log(document.querySelector('.test').style.offsetTop)
}
複製程式碼- 不要使用 table 佈局，可能很小的一個小改動會造成整個 table 的重新佈局
- 動畫實現的速度的選擇，動畫速度越快，迴流次數越多，也可以選擇使用 requestAnimationFrame
- CSS 選擇符從右往左匹配查詢，避免節點層級過多
- 將頻繁重繪或者回流的節點設定為圖層，圖層能夠阻止該節點的渲染行為影響別的節點。比如對於 video 標籤來說，瀏覽器會自動將該節點變為圖層。
效能優化策略
基於上面介紹的瀏覽器渲染原理，DOM 和 CSSOM 結構構建順序，初始化可以對頁面渲染做些優化，提升頁面效能。
- JS優化：
<script>標籤加上 defer屬性 和 async屬性 用於在不阻塞頁面文件解析的前提下，控制指令碼的下載和執行。- defer屬性： 用於開啟新的執行緒下載指令碼檔案，並使指令碼在文件解析完成後執行。
- async屬性： HTML5新增屬性，用於非同步下載指令碼檔案，下載完畢立即解釋執行程式碼。
- CSS優化：
<link>標籤的 rel屬性 中的屬性值設定為 preload 能夠讓你在你的HTML頁面中可以指明哪些資源是在頁面載入完成後即刻需要的,最優的配置載入順序，提高渲染效能
總結
綜上所述，我們得出這樣的結論：
- 瀏覽器工作流程：構建DOM -> 構建CSSOM -> 構建渲染樹 -> 佈局 -> 繪製。
- CSSOM會阻塞渲染，只有當CSSOM構建完畢後才會進入下一個階段構建渲染樹。
- 通常情況下DOM和CSSOM是並行構建的，但是當瀏覽器遇到一個不帶defer或async屬性的script標籤時，DOM構建將暫停，如果此時又恰巧瀏覽器尚未完成CSSOM的下載和構建，由於JavaScript可以修改CSSOM，所以需要等CSSOM構建完畢後再執行JS，最後才重新DOM構建。
歡迎關注公眾號：前端工匠，你的成長我們一起見證！
