關(guān)鍵渲染路徑
瀏覽器從接收到頁面開始到頁面顯示，這整個(gè)過程中的所有步驟楔绞，稱為關(guān)鍵渲染路徑欠雌。用戶看到頁面實(shí)際上可以分為兩個(gè)階段：頁面內(nèi)容加載完成和頁面資源完成半等，分別對應(yīng)于DOMContentLoaded和Load褂痰。從DevTool-Network面板上看运授，如下圖：
DOMContentLoaded和Load
TL;DR
整個(gè)關(guān)鍵渲染路徑包括以下幾個(gè)步驟：
- 解析HTML剖膳，生成DOM樹（DOM）
- 解析CSS碘举，生成CSSOM樹（CSSOM）
- 將DOM和CSSOM合并，生成渲染樹（Render-Tree）
- 計(jì)算渲染樹的布局（Layout）
- 將布局渲染到屏幕上（Paint）
從上面看出蜈敢，我們并沒有提到腳本JS的處理辜荠，并不是腳本處理不在關(guān)鍵渲染路徑中汽抚，而是因?yàn)镴S的處理會對1抓狭、2產(chǎn)生影響，我們需要單獨(dú)去解釋造烁。
DOM生成
瀏覽器在獲取HTML后否过，解析HTML代碼，將HTML的元素關(guān)系轉(zhuǎn)換成一個(gè)數(shù)據(jù)結(jié)構(gòu)惭蟋，就是我們所熟知的DOM（Document Object Model）苗桂。
在解析HTML過程中，會碰到幾類特殊的節(jié)點(diǎn)需要特殊的處理：
- style告组、link元素以及具有內(nèi)聯(lián)樣式的元素：交給“CSSOM生成”
- script（無論是否外鏈）元素：見“Script標(biāo)簽的處理”
P.S. 思考：碰到img煤伟、video、audio等資源性標(biāo)簽怎么辦木缝？
解析完HTML便锨，單純使用DOM，瀏覽器并不知道如何渲染這棵樹我碟，DOM只是存儲了元素的關(guān)系放案，并沒有任何渲染信息，如寬高矫俺、顏色吱殉、背景、定位等厘托。存儲這些信息友雳，就需要CSSOM了。扒一張Chrome內(nèi)部文章的例子來總結(jié)：
<html>
<head>
<meta name="viewport" content="width=device-width,initial-scale=1">
<link href="style.css" rel="stylesheet">
<title>Critical Path</title>
</head>
<body>
<p>Hello <span>web performance</span> students!</p>
<div></div>
</body>
</html>
DOM生成
CSSOM生成
上面簡單提到了铅匹，在HTML的解析過程中押赊，會碰到style、link和內(nèi)聯(lián)樣式伊群，這時(shí)考杉，瀏覽器會將解析DOM換成解析CSSOM策精，CSSOM和DOM是兩個(gè)獨(dú)立的數(shù)據(jù)結(jié)構(gòu)。
style和內(nèi)聯(lián)樣式
對這兩類樣式崇棠，瀏覽器會直接根據(jù)樣式聲明生成CSSOM咽袜，因?yàn)樗鼈儽旧砭椭苯雍袠邮絻?nèi)容。
link
對外聯(lián)樣式枕稀，瀏覽器會首先發(fā)送請求询刹，待請求成功，獲取外聯(lián)樣式后萎坷，瀏覽器便會解析該外聯(lián)樣式凹联，并生成相應(yīng)的CSSOM。
由于CSSOM負(fù)責(zé)存儲渲染信息哆档，瀏覽器就必須保證在合成渲染樹之前蔽挠，CSSOM是完備的，這種完備是指所有的CSS（內(nèi)聯(lián)瓜浸、內(nèi)部和外部）都已經(jīng)下載完澳淑，并解析完，只有CSSOM和DOM的解析完全結(jié)束插佛，瀏覽器才會進(jìn)入下一步的渲染杠巡，這就是傳說中的CSS阻塞渲染。
CSS阻塞渲染意味著雇寇，在CSSOM完備前氢拥，頁面將一直處理白屏狀態(tài)，這就是為什么樣式放在head中锨侯，僅僅是為了更快的解析CSS嫩海，保證更快的首次渲染。
需要注意的是识腿，即便你沒有給頁面任何的樣式聲明出革，CSSOM依然會生成，默認(rèn)生成的CSSOM自帶瀏覽器默認(rèn)樣式（default styles）渡讼。
樣式解析生成的CSSOM便含有渲染信息骂束，這些信息會與DOM一起，生成渲染樹Render-Tree成箫。最后展箱，一樣附上Chrome官方的事例來個(gè)總結(jié)：
body { font-size: 16px }
p { font-weight: bold }
span { color: red }
p span { display: none }
img { float: right }
CSSOM生成
在講渲染樹前，我們還需要講講一直被我們擱置的script蹬昌。
Script標(biāo)簽的處理
JS可以操作DOM來修改DOM結(jié)構(gòu)混驰，可以操作CSSOM來修改節(jié)點(diǎn)樣式，這就導(dǎo)致了瀏覽器在解析HTML時(shí)，一旦碰到script栖榨，就會立即停止HTML的解析（而CSS不會）昆汹，執(zhí)行JS，再返還控制權(quán)婴栽。
事實(shí)上满粗，JS執(zhí)行前不僅僅是停止了HTML的解析，它還必須等待CSS的解析完成愚争。當(dāng)瀏覽器碰到script元素時(shí)映皆，發(fā)現(xiàn)該元素前面的CSS還未解析完，就會等待CSS解析完成轰枝，再去執(zhí)行JS捅彻。
JS阻塞了HTML的解析，也阻塞了其后的CSS解析鞍陨，整個(gè)解析進(jìn)程必須等待JS的執(zhí)行完成才能夠繼續(xù)步淹，這就是所謂的JS阻塞頁面。一個(gè)script標(biāo)簽湾戳，推遲了DOM的生成贤旷、CSSOM的生成以及之后的所有渲染過程广料，從性能角度上講砾脑，將script放在頁面底部，也就合情合理了艾杏。
渲染樹
當(dāng)DOM和CSSOM構(gòu)建完成韧衣，它們一個(gè)存儲了節(jié)點(diǎn)信息，一個(gè)存儲了節(jié)點(diǎn)渲染信息购桑，都不能直接用來渲染畅铭，為此瀏覽器會將兩者結(jié)合，生成渲染樹（Render-Tree）勃蜘，這棵樹就包含了頁面所有可見元素及其渲染信息硕噩。仍以上述同樣的例子：
渲染樹
生成渲染樹，瀏覽器做了這些工作：
- 從DOM的根節(jié)點(diǎn)開始缭贡，遍歷每個(gè)可視節(jié)點(diǎn)：script炉擅、link、meta都屬于不可視節(jié)點(diǎn)阳惹，另外谍失，display: none的節(jié)點(diǎn)也屬于不可視節(jié)點(diǎn)
- 從CSSOM中搜索可視節(jié)點(diǎn)的樣式
- 計(jì)算這些樣式，將計(jì)算值應(yīng)用到可視節(jié)點(diǎn)上
渲染樹生成后莹汤，還是沒有辦法渲染到屏幕上快鱼，渲染到屏幕需要得到各個(gè)節(jié)點(diǎn)的位置信息，這就需要布局（Layout）的處理了。
布局
渲染樹生成后抹竹，瀏覽器便可以根據(jù)渲染樹中的樣式信息线罕，結(jié)合設(shè)備的屏幕信息，計(jì)算每個(gè)元素的位置和尺寸窃判。
渲染
得到了渲染樹及其節(jié)點(diǎn)的布局信息闻坚，瀏覽器便可以將最終的頁面渲染到屏幕。
整個(gè)關(guān)鍵渲染路徑主要就包括了以上這些步驟兢孝，每個(gè)步驟的快慢都決定著頁面的性能窿凤，或者說網(wǎng)站的性能，因此跨蟹，談到首屏或者首渲的性能優(yōu)化雳殊，就不得不從關(guān)鍵渲染路徑著手，每一步都是有或多或少的可優(yōu)化點(diǎn)窗轩。一些優(yōu)化建議什么的夯秃，就不在本文范圍了。
當(dāng)我們的頁面首渲完成后痢艺，會有很多頁面交互仓洼，例如：動(dòng)畫、用戶點(diǎn)擊堤舒、滾屏色建。所有的交互都會引發(fā)瀏覽器新的渲染操作，這些操作直接影響著用戶交互性能舌缤，Chrome官網(wǎng)里直接稱作渲染性能箕戳。
渲染流程
對于渲染，我們首先需要了解一個(gè)概念：設(shè)備刷新率国撵。
設(shè)備刷新率是設(shè)備屏幕渲染的頻率陵吸，通俗一點(diǎn)就是，把屏幕當(dāng)作墻介牙，設(shè)備刷新率就是多久重新粉刷一次墻面壮虫。基本我們平常接觸的設(shè)備环础，如手機(jī)囚似、電腦，它們的默認(rèn)刷新頻率都是60FPS喳整，也就是屏幕在1s內(nèi)渲染60次谆构，約16.7ms渲染一次屏幕。
這就意味著框都，我們的瀏覽器最佳的渲染性能就是所有的操作在一幀16.7ms內(nèi)完成搬素，能否做到一幀內(nèi)完成直接決定著渲染性呵晨，影響用戶交互，這就要求我們需要了解瀏覽器的一個(gè)渲染過程熬尺，包括了哪些操作摸屠。
完整的渲染流程由以下幾步組成：
完整的渲染流程
- JS：渲染引擎會等待所有的JS操作完成，收集JS對DOM和CSSOM的操作結(jié)果
- Style：樣式計(jì)算粱哼，計(jì)算交互引起的樣式變更季二，并應(yīng)用到相應(yīng)的節(jié)點(diǎn)上
- Layout：布局，根據(jù)新的Style揭措，計(jì)算出新的節(jié)點(diǎn)位置和尺寸信息
- Paint：渲染胯舷，計(jì)算最終的渲染信息（與上述的關(guān)鍵渲染路徑-渲染好像不同，其實(shí)是一樣的绊含，只是上面直接跳到了渲染到屏幕這一步）桑嘶，在實(shí)際的渲染中，瀏覽器會盡可能地在多個(gè)層上去渲染躬充，這個(gè)層類似PS里的圖層概念
- Composite：合成逃顶，將每個(gè)渲染層合并，生成最終的一層渲染畫面充甚。Paint階段以政，每個(gè)層獨(dú)立渲染，并不關(guān)心與其他層之間的關(guān)系伴找，Composite就需要將這些層以正確的關(guān)系合成盈蛮，有點(diǎn)像PS的導(dǎo)出PNG。合成發(fā)生在GPU上
完整的渲染流程就這樣疆瑰，但是眉反，并不是所有的交互都要走一遍這個(gè)流程，事實(shí)上穆役，從性能角度講，我們更希望的是每個(gè)交互都能省它幾個(gè)步驟梳凛。確實(shí)耿币，也是做得到的，不管你是無意識還是有意識韧拒，某些交互可以省這么一兩個(gè)步驟淹接，除了這種走遍天下的渲染流程，“缺胳膊少腿”的渲染流程有以下兩種：
- 缺Layout
缺少Layout的渲染流程
Layout是計(jì)算節(jié)點(diǎn)的布局信息——位置和尺寸叛溢，當(dāng)我們修改的樣式里不涉及布局塑悼，瀏覽器就會省略這個(gè)步驟。例如：color楷掉。通常來講厢蒜，Layout是很耗渲染性能的，從性能優(yōu)化角度講，能避免Layout就避免斑鸦。除了修改布局屬性會觸發(fā)Layout外愕贡，很多獲取布局信息的JS操作也會引發(fā)Layout，如offsetHeight巷屿，getComputedStyle固以。
- 缺Layout和Paint
缺少Layout和Paint的渲染流程
缺Layout我們知道，只要不觸發(fā)布局屬性修改及獲取布局信息就可以避免嘱巾。而避免Paint呢憨琳，就是讓瀏覽器將渲染直接交給合成，目前transform和opacity兩類樣式屬性是可以直接跳過Paint的旬昭。至于將translate2D變3D栽渴，實(shí)際上是觸發(fā)了層提升，使得相應(yīng)的元素渲染可以在獨(dú)立層上與其他層并行處理稳懒，間接提升了渲染性能闲擦。至于別人說的觸發(fā)GPU加速，也只是因?yàn)楸恍陆艘粋€(gè)層场梆。
似乎提升層來提升性能是個(gè)很不錯(cuò)的玩法墅冷，但是，你的硬件不是無限的或油，每多一個(gè)層寞忿，就會多一份內(nèi)存，因此顶岸，控制層數(shù)腔彰，也是很重要的性能提升。
除了將2D變3D可以達(dá)到層的提升辖佣，現(xiàn)代瀏覽器也加上了一個(gè)新的樣式屬性霹抛，來“預(yù)先”告知瀏覽器，提升層來處理相應(yīng)元素的渲染卷谈，這個(gè)屬性名字也是很不錯(cuò)的：will-change
使用該屬性杯拐，你不必translate3d，只需要：
.my-class {
will-change: transform;
}
當(dāng)然世蔗，兼容性是個(gè)問題端逼，自行caniuse。
正因?yàn)閠ransform和opacity可以跳過Paint污淋，并且可以在某種形式下告知瀏覽器優(yōu)先以GPU來渲染顶滩，才有了現(xiàn)代CSS動(dòng)畫推崇優(yōu)先使用transform，避免使用position寸爆、height等屬性的變更來處理動(dòng)畫礁鲁。一些流行的動(dòng)畫庫盐欺，如iScroll、Swiper.js等救氯，都是使用transform來處理位置偏移找田，而非top、left等着憨，就是因?yàn)樾阅芨摺?/p>
OK墩衙，渲染機(jī)制就是這么個(gè)事，怎么做性能優(yōu)化甲抖，就要根據(jù)不同的渲染步驟漆改，配相應(yīng)的策略，還是那句話准谚，怎么做性能優(yōu)化挫剑，不是本文的目的。
