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