首先仍然不得不提的是 “在客戶端拿到 HTML 后的處理”：
-
從上到下解析 HTML 文檔生成DOM樹；
-
加載解析樣式構(gòu)建CSSOM樹；
-
加載并執(zhí)行JavaScript代碼；
-
根據(jù)DOM樹和CSSOM樹，生成 render 樹；
-
渲染；
-
布局；
-
繪制
我們可能很多次聽到過：“要盡可能地減少重排和重繪，因?yàn)樗鼈儠?huì)影響瀏覽器性能。”
但，為什么呢？
事實(shí)上，一個(gè)頁面是由許多層級(jí)組成的（就像千層餅一樣） —— 這里的“層級(jí)”指的是“ DOM 元素渲染層（Layer）”。一個(gè)頁面在構(gòu)建完 render tree 到展現(xiàn)在我們面前還經(jīng)歷了一個(gè)“特別的流程”：
-
瀏覽器會(huì)先獲取DOM樹并依據(jù)樣式將其分割成多個(gè)獨(dú)立的渲染層
-
CPU 將每一層繪制進(jìn)位圖中
-
將位圖作為紋理上傳至 GPU（顯卡）繪制
-
GPU 將所有的渲染層緩存并復(fù)合多個(gè)渲染層最終形成我們的圖像（如果下次上傳的渲染層沒有發(fā)生變化，GPU 就不需要對(duì)其進(jìn)行重新繪制）
（：從上面的步驟我們可以知道：布局是CPU處理的，而繪制是由GPU完成的。
就像這張圖說的（from Firefox的3D View插件的頁面Layers層級(jí)圖）
問題就發(fā)生在上面所說流程的第2、4步中。大家試想一下：如果我們把那些會(huì)發(fā)生復(fù)雜運(yùn)動(dòng)/變化或一直發(fā)生大量重排重繪的元素提起出來，單獨(dú)放在一個(gè)渲染層觸發(fā)，那它就不會(huì)連累其他元素了！
那什么情況下會(huì)觸發(fā)渲染層呢？
比如 video 、WebGL 、Canvas 、CSS3 3D 、CSS濾鏡 、z-index大于某個(gè)相鄰節(jié)點(diǎn)的值 的元素都會(huì)觸發(fā)新的Layer —— 這里要理解一點(diǎn)：它并不單單指 z-index！這里極力推薦張鑫旭大大的這一篇文章：深入理解CSS中的層疊上下文和層疊順序
比較簡單的方法是，給元素加上下面的樣式：
transform: translateZ(0); backface-visibility: hidden;
我們把容易觸發(fā)重排重繪的元素單獨(dú)觸發(fā)渲染層，讓它與那些“靜態(tài)”元素隔離，讓 GPU 分擔(dān)更多的渲染工作，我們通常把這樣的措施成為硬件加速，或者是 GPU 加速。大家之前肯定聽過這個(gè)說法 —— 就比如CSS中的 will-change 。
不論是重排還是重繪，都會(huì)阻塞瀏覽器。要提高網(wǎng)頁性能，就要降低重排和重繪的頻率和成本，近可能少地觸發(fā)重新渲染。正如我們上面提到的：重排是由 CPU 處理的，而重繪是由 GPU 處理的，CPU 的處理效率遠(yuǎn)不及 GPU，并且重排一定會(huì)引發(fā)重繪，而重繪不一定會(huì)引發(fā)重排。所以在性能優(yōu)化工作中，我們更應(yīng)當(dāng)著重減少重排的發(fā)生。
還有什么可以優(yōu)化的？
-
CSS 屬性讀寫分離：瀏覽器沒次對(duì)元素樣式進(jìn)行讀操作時(shí)，都必須進(jìn)行一次重新渲染（重排 + 重繪），所以我們?cè)谑褂?JS 對(duì)元素樣式進(jìn)行讀寫操作時(shí)，最好將兩者分離開，先讀后寫，避免出現(xiàn)兩者交叉使用的情況
-
通過切換 class 或者
style.csstext 屬性去批量操作元素樣式
-
DOM 元素離線更新：當(dāng)對(duì) DOM 進(jìn)行相關(guān)操作時(shí)，例、
appendChild 等都可以使用 documentFragment 對(duì)象進(jìn)行離屏操作，帶元素“組裝”完成后再一次插入頁面，或者使用 display:none 對(duì)元素隱藏，在元素“消失”后進(jìn)行相關(guān)操作，然后再顯示出來
-
visibility: hidden 是個(gè)好東西，它既有display的隱藏，又有opacity的占位。而且它還支持移動(dòng)動(dòng)畫
-
圖片在渲染前指定大小：因?yàn)?img 元素是內(nèi)聯(lián)元素，所以在加載圖片后會(huì)改變寬高，嚴(yán)重的情況會(huì)導(dǎo)致整個(gè)頁面重排，所以最好在渲染前就指定其大小，或者讓其脫離文檔流
