前端开发这么多年，你真的了解浏览器页面渲染机制吗？
作者 |?浪里行舟
?
前言
瀏覽器的內(nèi)核是指支持瀏覽器運(yùn)行的最核心的程序，分為兩個(gè)部分的，一是渲染引擎，另一個(gè)是JS引擎。渲染引擎在不同的瀏覽器中也不是都相同的。目前市面上常見(jiàn)的瀏覽器內(nèi)核可以分為這四種：Trident（IE）、Gecko（火狐）、Blink（Chrome、Opera）、Webkit（Safari）。這里面大家最耳熟能詳?shù)目赡芫褪?Webkit?內(nèi)核了，Webkit?內(nèi)核是當(dāng)下瀏覽器世界真正的霸主。本文我們就以?Webkit?為例，對(duì)現(xiàn)代瀏覽器的渲染過(guò)程進(jìn)行一個(gè)深度的剖析。
?
頁(yè)面加載過(guò)程
在介紹瀏覽器渲染過(guò)程之前，我們簡(jiǎn)明扼要介紹下頁(yè)面的加載過(guò)程，有助于更好理解后續(xù)渲染過(guò)程。
要點(diǎn)如下：
-
瀏覽器根據(jù) DNS 服務(wù)器得到域名的 IP 地址
-
向這個(gè) IP 的機(jī)器發(fā)送 HTTP 請(qǐng)求
-
服務(wù)器收到、處理并返回 HTTP 請(qǐng)求
-
瀏覽器得到返回內(nèi)容
例如在瀏覽器輸入?https://juejin.im/timeline，然后經(jīng)過(guò)?DNS?解析，?juejin.im對(duì)應(yīng)的?IP?是?36.248.217.149（不同時(shí)間、地點(diǎn)對(duì)應(yīng)的?IP?可能會(huì)不同）。然后瀏覽器向該?IP?發(fā)送?HTTP?請(qǐng)求。
服務(wù)端接收到?HTTP?請(qǐng)求，然后經(jīng)過(guò)計(jì)算（向不同的用戶推送不同的內(nèi)容），返回?HTTP?請(qǐng)求，返回的內(nèi)容如下：
其實(shí)就是一堆?HMTL?格式的字符串，因?yàn)橹挥?HTML?格式瀏覽器才能正確解析，這是?W3C?標(biāo)準(zhǔn)的要求。接下來(lái)就是瀏覽器的渲染過(guò)程。
?
瀏覽器渲染過(guò)程
瀏覽器渲染過(guò)程大體分為如下三部分：
1）瀏覽器會(huì)解析三個(gè)東西：
一是HTML/SVG/XHTML，HTML字符串描述了一個(gè)頁(yè)面的結(jié)構(gòu)，瀏覽器會(huì)把HTML結(jié)構(gòu)字符串解析轉(zhuǎn)換DOM樹(shù)形結(jié)構(gòu)。
二是CSS，解析CSS會(huì)產(chǎn)生CSS規(guī)則樹(shù)，它和DOM結(jié)構(gòu)比較像。
三是Javascript腳本，等到Javascript?腳本文件加載后，?通過(guò)?DOM?API?和?CSSOM?API?來(lái)操作?DOM?Tree?和?CSS?Rule?Tree。
2）解析完成后，瀏覽器引擎會(huì)通過(guò)DOM?Tree?和?CSS?Rule?Tree?來(lái)構(gòu)造?Rendering?Tree。
-
Rendering?Tree?渲染樹(shù)并不等同于DOM樹(shù)，渲染樹(shù)只會(huì)包括需要顯示的節(jié)點(diǎn)和這些節(jié)點(diǎn)的樣式信息。
-
CSS?的?Rule?Tree主要是為了完成匹配并把CSS?Rule附加上Rendering?Tree上的每個(gè)Element（也就是每個(gè)Frame）。
-
然后，計(jì)算每個(gè)Frame?的位置，這又叫l(wèi)ayout和reflow過(guò)程。
3）最后通過(guò)調(diào)用操作系統(tǒng)Native?GUI的API繪制。
接下來(lái)我們針對(duì)這其中所經(jīng)歷的重要步驟詳細(xì)闡述。
構(gòu)建DOM
瀏覽器會(huì)遵守一套步驟將HTML?文件轉(zhuǎn)換為?DOM?樹(shù)。宏觀上，可以分為幾個(gè)步驟：
瀏覽器從磁盤或網(wǎng)絡(luò)讀取HTML的原始字節(jié)，并根據(jù)文件的指定編碼（例如?UTF-8）將它們轉(zhuǎn)換成字符串。
在網(wǎng)絡(luò)中傳輸?shù)膬?nèi)容其實(shí)都是?0?和?1?這些字節(jié)數(shù)據(jù)。當(dāng)瀏覽器接收到這些字節(jié)數(shù)據(jù)以后，它會(huì)將這些字節(jié)數(shù)據(jù)轉(zhuǎn)換為字符串，也就是我們寫的代碼。
將字符串轉(zhuǎn)換成Token，例如：?<html>、?<body>等。Token中會(huì)標(biāo)識(shí)出當(dāng)前Token是“開(kāi)始標(biāo)簽”或是“結(jié)束標(biāo)簽”亦或是“文本”等信息。
這時(shí)候你一定會(huì)有疑問(wèn)，節(jié)點(diǎn)與節(jié)點(diǎn)之間的關(guān)系如何維護(hù)？
事實(shí)上，這就是Token要標(biāo)識(shí)“起始標(biāo)簽”和“結(jié)束標(biāo)簽”等標(biāo)識(shí)的作用。例如“title”Token的起始標(biāo)簽和結(jié)束標(biāo)簽之間的節(jié)點(diǎn)肯定是屬于“head”的子節(jié)點(diǎn)
上圖給出了節(jié)點(diǎn)之間的關(guān)系，例如：“Hello”Token位于“title”開(kāi)始標(biāo)簽與“title”結(jié)束標(biāo)簽之間，表明“Hello”Token是“title”Token的子節(jié)點(diǎn)。同理“title”Token是“head”Token的子節(jié)點(diǎn)。
-
生成節(jié)點(diǎn)對(duì)象并構(gòu)建DOM
事實(shí)上，構(gòu)建DOM的過(guò)程中，不是等所有Token都轉(zhuǎn)換完成后再去生成節(jié)點(diǎn)對(duì)象，而是一邊生成Token一邊消耗Token來(lái)生成節(jié)點(diǎn)對(duì)象。換句話說(shuō)，每個(gè)Token被生成后，會(huì)立刻消耗這個(gè)Token創(chuàng)建出節(jié)點(diǎn)對(duì)象。注意：帶有結(jié)束標(biāo)簽標(biāo)識(shí)的Token不會(huì)創(chuàng)建節(jié)點(diǎn)對(duì)象。
接下來(lái)我們舉個(gè)例子，假設(shè)有段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會(huì)解析成這樣：
構(gòu)建CSSOM
DOM會(huì)捕獲頁(yè)面的內(nèi)容，但瀏覽器還需要知道頁(yè)面如何展示，所以需要構(gòu)建CSSOM。
構(gòu)建CSSOM的過(guò)程與構(gòu)建DOM的過(guò)程非常相似，當(dāng)瀏覽器接收到一段CSS，瀏覽器首先要做的是識(shí)別出Token，然后構(gòu)建節(jié)點(diǎn)并生成CSSOM
在這一過(guò)程中，瀏覽器會(huì)確定下每一個(gè)節(jié)點(diǎn)的樣式到底是什么，并且這一過(guò)程其實(shí)是很消耗資源的。因?yàn)闃邮侥憧梢宰孕性O(shè)置給某個(gè)節(jié)點(diǎn)，也可以通過(guò)繼承獲得。在這一過(guò)程中，瀏覽器得遞歸?CSSOM?樹(shù)，然后確定具體的元素到底是什么樣式。
注意：CSS匹配HTML元素是一個(gè)相當(dāng)復(fù)雜和有性能問(wèn)題的事情。所以，DOM樹(shù)要小，CSS盡量用id和class，千萬(wàn)不要過(guò)渡層疊下去。
構(gòu)建渲染樹(shù)
當(dāng)我們生成?DOM?樹(shù)和?CSSOM?樹(shù)以后，就需要將這兩棵樹(shù)組合為渲染樹(shù)。
在這一過(guò)程中，不是簡(jiǎn)單的將兩者合并就行了。渲染樹(shù)只會(huì)包括需要顯示的節(jié)點(diǎn)和這些節(jié)點(diǎn)的樣式信息，如果某個(gè)節(jié)點(diǎn)是?display:none?的，那么就不會(huì)在渲染樹(shù)中顯示。
我們或許有個(gè)疑惑：瀏覽器如果渲染過(guò)程中遇到JS文件怎么處理？
渲染過(guò)程中，如果遇到?<script>就停止渲染，執(zhí)行?JS?代碼。因?yàn)闉g覽器渲染和?JS?執(zhí)行共用一個(gè)線程，而且這里必須是單線程操作，多線程會(huì)產(chǎn)生渲染?DOM?沖突。JavaScript的加載、解析與執(zhí)行會(huì)阻塞DOM的構(gòu)建，也就是說(shuō)，在構(gòu)建DOM時(shí)，HTML解析器若遇到了JavaScript，那么它會(huì)暫停構(gòu)建DOM，將控制權(quán)移交給JavaScript引擎，等JavaScript引擎運(yùn)行完畢，瀏覽器再?gòu)闹袛嗟牡胤交謴?fù)DOM構(gòu)建。
也就是說(shuō)，如果你想首屏渲染的越快，就越不應(yīng)該在首屏就加載?JS?文件，這也是都建議將?script?標(biāo)簽放在?body?標(biāo)簽底部的原因。當(dāng)然在當(dāng)下，并不是說(shuō)?script?標(biāo)簽必須放在底部，因?yàn)槟憧梢越o?script?標(biāo)簽添加?defer?或者?async?屬性（下文會(huì)介紹這兩者的區(qū)別）。
JS文件不只是阻塞DOM的構(gòu)建，它會(huì)導(dǎo)致CSSOM也阻塞DOM的構(gòu)建。
原本DOM和CSSOM的構(gòu)建是互不影響，井水不犯河水，但是一旦引入了JavaScript，CSSOM也開(kāi)始阻塞DOM的構(gòu)建，只有CSSOM構(gòu)建完畢后，DOM再恢復(fù)DOM構(gòu)建。
這是什么情況？
這是因?yàn)镴avaScript不只是可以改DOM，它還可以更改樣式，也就是它可以更改CSSOM。因?yàn)椴煌暾腃SSOM是無(wú)法使用的，如果JavaScript想訪問(wèn)CSSOM并更改它，那么在執(zhí)行JavaScript時(shí)，必須要能拿到完整的CSSOM。所以就導(dǎo)致了一個(gè)現(xiàn)象，如果瀏覽器尚未完成CSSOM的下載和構(gòu)建，而我們卻想在此時(shí)運(yùn)行腳本，那么瀏覽器將延遲腳本執(zhí)行和DOM構(gòu)建，直至其完成CSSOM的下載和構(gòu)建。也就是說(shuō)，在這種情況下，瀏覽器會(huì)先下載和構(gòu)建CSSOM，然后再執(zhí)行JavaScript，最后在繼續(xù)構(gòu)建DOM。
布局與繪制
當(dāng)瀏覽器生成渲染樹(shù)以后，就會(huì)根據(jù)渲染樹(shù)來(lái)進(jìn)行布局（也可以叫做回流）。這一階段瀏覽器要做的事情是要弄清楚各個(gè)節(jié)點(diǎn)在頁(yè)面中的確切位置和大小。通常這一行為也被稱為“自動(dòng)重排”。
布局流程的輸出是一個(gè)“盒模型”，它會(huì)精確地捕獲每個(gè)元素在視口內(nèi)的確切位置和尺寸，所有相對(duì)測(cè)量值都將轉(zhuǎn)換為屏幕上的絕對(duì)像素。
布局完成后，瀏覽器會(huì)立即發(fā)出“Paint?Setup”和“Paint”事件，將渲染樹(shù)轉(zhuǎn)換成屏幕上的像素。
以上我們?cè)敿?xì)介紹了瀏覽器工作流程中的重要步驟，接下來(lái)我們討論幾個(gè)相關(guān)的問(wèn)題：
幾點(diǎn)補(bǔ)充說(shuō)明
1.async和defer的作用是什么？有什么區(qū)別?
接下來(lái)我們對(duì)比下?defer?和?async?屬性的區(qū)別：
其中藍(lán)色線代表JavaScript加載；紅色線代表JavaScript執(zhí)行；綠色線代表?HTML?解析。
1）情況1?<scriptsrc="script.js"></script>
沒(méi)有?defer?或?async，瀏覽器會(huì)立即加載并執(zhí)行指定的腳本，也就是說(shuō)不等待后續(xù)載入的文檔元素，讀到就加載并執(zhí)行。
2）情況2?<scriptasyncsrc="script.js"></script>?(異步下載)
async?屬性表示異步執(zhí)行引入的?JavaScript，與?defer?的區(qū)別在于，如果已經(jīng)加載好，就會(huì)開(kāi)始執(zhí)行——無(wú)論此刻是?HTML?解析階段還是?DOMContentLoaded?觸發(fā)之后。需要注意的是，這種方式加載的?JavaScript?依然會(huì)阻塞?load?事件。換句話說(shuō)，async-script?可能在?DOMContentLoaded?觸發(fā)之前或之后執(zhí)行，但一定在?load?觸發(fā)之前執(zhí)行。
3）情況3?<scriptdefersrc="script.js"></script>(延遲執(zhí)行)
defer?屬性表示延遲執(zhí)行引入的?JavaScript，即這段?JavaScript?加載時(shí)?HTML?并未停止解析，這兩個(gè)過(guò)程是并行的。整個(gè)?document?解析完畢且?defer-script?也加載完成之后（這兩件事情的順序無(wú)關(guān)），會(huì)執(zhí)行所有由?defer-script?加載的?JavaScript?代碼，然后觸發(fā)?DOMContentLoaded?事件。
defer?與相比普通?script，有兩點(diǎn)區(qū)別：載入?JavaScript?文件時(shí)不阻塞?HTML?的解析，執(zhí)行階段被放到?HTML?標(biāo)簽解析完成之后；在加載多個(gè)JS腳本的時(shí)候，async是無(wú)順序的加載，而defer是有順序的加載。
2.為什么操作?DOM?慢？
把?DOM?和?JavaScript?各自想象成一個(gè)島嶼，它們之間用收費(fèi)橋梁連接。——《高性能?JavaScript》
JS?是很快的，在?JS?中修改?DOM?對(duì)象也是很快的。在JS的世界里，一切是簡(jiǎn)單的、迅速的。但?DOM?操作并非?JS?一個(gè)人的獨(dú)舞，而是兩個(gè)模塊之間的協(xié)作。
因?yàn)?DOM?是屬于渲染引擎中的東西，而?JS?又是?JS?引擎中的東西。當(dāng)我們用?JS?去操作?DOM?時(shí)，本質(zhì)上是?JS?引擎和渲染引擎之間進(jìn)行了“跨界交流”。這個(gè)“跨界交流”的實(shí)現(xiàn)并不簡(jiǎn)單，它依賴了橋接接口作為“橋梁”（如下圖）。
過(guò)“橋”要收費(fèi)——這個(gè)開(kāi)銷本身就是不可忽略的。我們每操作一次?DOM（不管是為了修改還是僅僅為了訪問(wèn)其值），都要過(guò)一次“橋”。過(guò)“橋”的次數(shù)一多，就會(huì)產(chǎn)生比較明顯的性能問(wèn)題。因此“減少?DOM?操作”的建議，并非空穴來(lái)風(fēng)。
3.你真的了解回流和重繪嗎
渲染的流程基本上是這樣（如下圖黃色的四個(gè)步驟）：1.計(jì)算CSS樣式?2.構(gòu)建Render?Tree?3.Layout?–?定位坐標(biāo)和大小?4.正式開(kāi)畫
注意：上圖流程中有很多連接線，這表示了Javascript動(dòng)態(tài)修改了DOM屬性或是CSS屬性會(huì)導(dǎo)致重新Layout，但有些改變不會(huì)重新Layout，就是上圖中那些指到天上的箭頭，比如修改后的CSS?rule沒(méi)有被匹配到元素。
這里重要要說(shuō)兩個(gè)概念，一個(gè)是Reflow，另一個(gè)是Repaint
重繪：當(dāng)我們對(duì)?DOM?的修改導(dǎo)致了樣式的變化、卻并未影響其幾何屬性（比如修改了顏色或背景色）時(shí)，瀏覽器不需重新計(jì)算元素的幾何屬性、直接為該元素繪制新的樣式（跳過(guò)了上圖所示的回流環(huán)節(jié)）。
回流：當(dāng)我們對(duì)?DOM?的修改引發(fā)了?DOM?幾何尺寸的變化（比如修改元素的寬、高或隱藏元素等）時(shí)，瀏覽器需要重新計(jì)算元素的幾何屬性（其他元素的幾何屬性和位置也會(huì)因此受到影響），然后再將計(jì)算的結(jié)果繪制出來(lái)。這個(gè)過(guò)程就是回流（也叫重排）
我們知道，當(dāng)網(wǎng)頁(yè)生成的時(shí)候，至少會(huì)渲染一次。在用戶訪問(wèn)的過(guò)程中，還會(huì)不斷重新渲染。重新渲染會(huì)重復(fù)回流+重繪或者只有重繪。回流必定會(huì)發(fā)生重繪，重繪不一定會(huì)引發(fā)回流。重繪和回流會(huì)在我們?cè)O(shè)置節(jié)點(diǎn)樣式時(shí)頻繁出現(xiàn)，同時(shí)也會(huì)很大程度上影響性能。回流所需的成本比重繪高的多，改變父節(jié)點(diǎn)里的子節(jié)點(diǎn)很可能會(huì)導(dǎo)致父節(jié)點(diǎn)的一系列回流。
1）常見(jiàn)引起回流屬性和方法
任何會(huì)改變?cè)貛缀涡畔?元素的位置和尺寸大小)的操作，都會(huì)觸發(fā)回流，
-
添加或者刪除可見(jiàn)的DOM元素；
-
元素尺寸改變——邊距、填充、邊框、寬度和高度
-
內(nèi)容變化，比如用戶在input框中輸入文字
-
瀏覽器窗口尺寸改變——resize事件發(fā)生時(shí)
-
計(jì)算 offsetWidth 和 offsetHeight 屬性
-
設(shè)置 style 屬性的值
2）常見(jiàn)引起重繪屬性和方法
3）如何減少回流、重繪
-
使用 transform 替代 top
-
使用?visibility?替換?display:?none?，因?yàn)榍罢咧粫?huì)引起重繪，后者會(huì)引發(fā)回流（改變了布局）
-
不要把節(jié)點(diǎn)的屬性值放在一個(gè)循環(huán)里當(dāng)成循環(huán)里的變量。
-
不要使用 table 布局，可能很小的一個(gè)小改動(dòng)會(huì)造成整個(gè) table 的重新布局
-
動(dòng)畫實(shí)現(xiàn)的速度的選擇，動(dòng)畫速度越快，回流次數(shù)越多，也可以選擇使用 requestAnimationFrame
-
CSS 選擇符從右往左匹配查找，避免節(jié)點(diǎn)層級(jí)過(guò)多
-
將頻繁重繪或者回流的節(jié)點(diǎn)設(shè)置為圖層，圖層能夠阻止該節(jié)點(diǎn)的渲染行為影響別的節(jié)點(diǎn)。比如對(duì)于?video?標(biāo)簽來(lái)說(shuō)，瀏覽器會(huì)自動(dòng)將該節(jié)點(diǎn)變?yōu)閳D層。
?
性能優(yōu)化策略
基于上面介紹的瀏覽器渲染原理，DOM?和?CSSOM?結(jié)構(gòu)構(gòu)建順序，初始化可以對(duì)頁(yè)面渲染做些優(yōu)化，提升頁(yè)面性能。
-
JS優(yōu)化：?<script>?標(biāo)簽加上?defer屬性?和?async屬性?用于在不阻塞頁(yè)面文檔解析的前提下，控制腳本的下載和執(zhí)行。?defer屬性：?用于開(kāi)啟新的線程下載腳本文件，并使腳本在文檔解析完成后執(zhí)行。?async屬性：?HTML5新增屬性，用于異步下載腳本文件，下載完畢立即解釋執(zhí)行代碼。
-
CSS優(yōu)化：?<link>?標(biāo)簽的?rel屬性?中的屬性值設(shè)置為?preload?能夠讓你在你的HTML頁(yè)面中可以指明哪些資源是在頁(yè)面加載完成后即刻需要的,最優(yōu)的配置加載順序，提高渲染性能
?
總結(jié)
綜上所述，我們得出這樣的結(jié)論：
-
瀏覽器工作流程：構(gòu)建DOM?->?構(gòu)建CSSOM?->?構(gòu)建渲染樹(shù)?->?布局?->?繪制。
-
CSSOM會(huì)阻塞渲染，只有當(dāng)CSSOM構(gòu)建完畢后才會(huì)進(jìn)入下一個(gè)階段構(gòu)建渲染樹(shù)。
-
通常情況下DOM和CSSOM是并行構(gòu)建的，但是當(dāng)瀏覽器遇到一個(gè)不帶defer或async屬性的script標(biāo)簽時(shí)，DOM構(gòu)建將暫停，如果此時(shí)又恰巧瀏覽器尚未完成CSSOM的下載和構(gòu)建，由于JavaScript可以修改CSSOM，所以需要等CSSOM構(gòu)建完畢后再執(zhí)行JS，最后才重新DOM構(gòu)建。
參考文章
-
async 和 defer 的區(qū)別 | SegmentFault
-
瀏覽器的渲染原理簡(jiǎn)介
-
前端面試之道
-
關(guān)鍵渲染路徑
-
前端性能優(yōu)化原理與實(shí)踐
-
由入門到專家：前端全鏈路開(kāi)發(fā)實(shí)踐手冊(cè)
-
Web 前端面試指南與高頻考題解析
作者：浪里行舟，碩士研究生，專注于前端，運(yùn)營(yíng)有個(gè)人公眾號(hào)前端工匠，致力于打造適合初中級(jí)工程師能夠快速吸收的一系列優(yōu)質(zhì)文章。
聲明：本文為作者投稿，版權(quán)歸對(duì)方所有，如需轉(zhuǎn)載請(qǐng)聯(lián)系原作者。
總結(jié)
以上是生活随笔為你收集整理的前端开发这么多年，你真的了解浏览器页面渲染机制吗？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 如何在面试中介绍自己的项目经验，很重要！
- 下一篇： 并发的核心：CAS 是什么？Java8是