資訊專欄INFORMATION COLUMN
摘要：前言瀏覽器的內核是指支持瀏覽器運行的最核心的程序，分為兩個部分的，一是渲染引擎，另一個是引擎。渲染引擎在不同的瀏覽器中也不是都相同的。接下來就是瀏覽器的渲染過程。布局完成后，瀏覽器會立即發出和事件，將渲染樹轉換成屏幕上的像素。
前言
瀏覽器的內核是指支持瀏覽器運行的最核心的程序，分為兩個部分的，一是渲染引擎，另一個是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，例如：、等。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文本：
Web page parsing
Web page parsing
This is an example Web page.
上面這段HTML會解析成這樣：
構建CSSOMDOM會捕獲頁面的內容，但瀏覽器還需要知道頁面如何展示，所以需要構建CSSOM。
構建CSSOM的過程與構建DOM的過程非常相似，當瀏覽器接收到一段CSS，瀏覽器首先要做的是識別出Token，然后構建節點并生成CSSOM。
在這一過程中，瀏覽器會確定下每一個節點的樣式到底是什么，并且這一過程其實是很消耗資源的。因為樣式你可以自行設置給某個節點，也可以通過繼承獲得。在這一過程中，瀏覽器得遞歸 CSSOM 樹，然后確定具體的元素到底是什么樣式。
注意：CSS匹配HTML元素是一個相當復雜和有性能問題的事情。所以，DOM樹要小，CSS盡量用id和class，千萬不要過渡層疊下去。
構建渲染樹當我們生成 DOM 樹和 CSSOM 樹以后，就需要將這兩棵樹組合為渲染樹。
在這一過程中，不是簡單的將兩者合并就行了。渲染樹只會包括需要顯示的節點和這些節點的樣式信息，如果某個節點是 display: none 的，那么就不會在渲染樹中顯示。
我們或許有個疑惑：瀏覽器如果渲染過程中遇到JS文件怎么處理？
渲染過程中，如果遇到
布局與繪制當瀏覽器生成渲染樹以后，就會根據渲染樹來進行布局（也可以叫做回流）。這一階段瀏覽器要做的事情是要弄清楚各個節點在頁面中的確切位置和大小。通常這一行為也被稱為“自動重排”。
布局流程的輸出是一個“盒模型”，它會精確地捕獲每個元素在視口內的確切位置和尺寸，所有相對測量值都將轉換為屏幕上的絕對像素。
布局完成后，瀏覽器會立即發出“Paint Setup”和“Paint”事件，將渲染樹轉換成屏幕上的像素。
以上我們詳細介紹了瀏覽器工作流程中的重要步驟，接下來我們討論幾個相關的問題：幾點補充說明 1.async和defer的作用是什么？有什么區別?
接下來我們對比下 defer 和 async 屬性的區別：
其中藍色線代表JavaScript加載；紅色線代表JavaScript執行；綠色線代表 HTML 解析。
1）情況1沒有 defer 或 async，瀏覽器會立即加載并執行指定的腳本，也就是說不等待后續載入的文檔元素，讀到就加載并執行。
2）情況2 (異步下載)async 屬性表示異步執行引入的 JavaScript，與 defer 的區別在于，如果已經加載好，就會開始執行——無論此刻是 HTML 解析階段還是 DOMContentLoaded 觸發之后。需要注意的是，這種方式加載的 JavaScript 依然會阻塞 load 事件。換句話說，async-script 可能在 DOMContentLoaded 觸發之前或之后執行，但一定在 load 觸發之前執行。
3）情況3 (延遲執行)defer 屬性表示延遲執行引入的 JavaScript，即這段 JavaScript 加載時 HTML 并未停止解析，這兩個過程是并行的。整個 document 解析完畢且 defer-script 也加載完成之后（這兩件事情的順序無關），會執行所有由 defer-script 加載的 JavaScript 代碼，然后觸發 DOMContentLoaded 事件。
defer 與相比普通 script，有兩點區別：**載入 JavaScript 文件時不阻塞 HTML 的解析，執行階段被放到 HTML 標簽解析完成之后。
在加載多個JS腳本的時候，async是無順序的加載，而defer是有順序的加載。**
把 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 幾何尺寸的變化（比如修改元素的寬、高或隱藏元素等）時，瀏覽器需要重新計算元素的幾何屬性（其他元素的幾何屬性和位置也會因此受到影響），然后再將計算的結果繪制出來。這個過程就是回流（也叫重排）
我們知道，當網頁生成的時候，至少會渲染一次。在用戶訪問的過程中，還會不斷重新渲染。重新渲染會重復回流+重繪或者只有重繪。
回流必定會發生重繪，重繪不一定會引發回流。重繪和回流會在我們設置節點樣式時頻繁出現，同時也會很大程度上影響性能。回流所需的成本比重繪高的多，改變父節點里的子節點很可能會導致父節點的一系列回流。
任何會改變元素幾何信息(元素的位置和尺寸大小)的操作，都會觸發回流，
添加或者刪除可見的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優化：
參考文章async 和 defer 的區別 | SegmentFault
瀏覽器的渲染原理簡介
前端面試之道
關鍵渲染路徑
前端性能優化原理與實踐
由入門到專家：前端全鏈路開發實踐手冊
Web 前端面試指南與高頻考題解析
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/103384.html
摘要：前言瀏覽器的內核是指支持瀏覽器運行的最核心的程序，分為兩個部分的，一是渲染引擎，另一個是引擎。渲染引擎在不同的瀏覽器中也不是都相同的。接下來就是瀏覽器的渲染過程。布局完成后，瀏覽器會立即發出和事件，將渲染樹轉換成屏幕上的像素。 前言 瀏覽器的內核是指支持瀏覽器運行的最核心的程序，分為兩個部分的，一是渲染引擎，另一個是JS引擎。渲染引擎在不同的瀏覽器中也不是都相同的。目前市面上常見的瀏覽...
摘要：不同的框架對這三個屬性的命名會有點差別，但表達的意思是一致的。它們分別是標簽名屬性和子元素對象。我們先來看下頁面的更新一般會經過幾個階段。元素有可能是數組的形式，需要將數組解構一層。 歡迎關注我的公眾號睿Talk，獲取我最新的文章：showImg(https://segmentfault.com/img/bVbmYjo); 一、前言 目前最流行的兩大前端框架，React和Vue，都不約...
摘要：歡迎來我的個人站點性能優化其他優化瀏覽器關鍵渲染路徑開啟性能優化之旅高性能滾動及頁面渲染優化理論寫法對壓縮率的影響唯快不破應用的個優化步驟進階鵝廠大神用直出實現網頁瞬開緩存網頁性能管理詳解寫給后端程序員的緩存原理介紹年底補課緩存機制優化動 歡迎來我的個人站點 性能優化 其他 優化瀏覽器關鍵渲染路徑 - 開啟性能優化之旅 高性能滾動 scroll 及頁面渲染優化 理論 | HTML寫法...
閱讀 623·2023-04-26 01:53
閱讀 2748·2021-11-17 17:00
閱讀 2880·2021-09-04 16:40
閱讀 1983·2021-09-02 15:41
閱讀 830·2019-08-26 11:34
閱讀 1222·2019-08-26 10:16
閱讀 1335·2019-08-23 17:51
閱讀 815·2019-08-23 16:50
