2018前端效能優化原理

dom 為什麼這麼慢？

當我們用 js 去操作 dom 時，本質上是 js 引擎和渲染引擎之間進行了「跨界交流」。這個「跨界交流」的實現並不簡單，它依賴了橋接介面作為「橋梁」（如下圖）。

過「橋」要收費——這個開銷本身就是不可忽略的。我們每操作一次 dom（不管是為了修改還是僅僅為了訪問其值），都要過一次「橋」。過「橋」的次數一多，就會產生比較明顯的效能問題。因此「減少 dom 操作」的建議，並非空穴來風。

對 dom 的修改引發樣式的更迭：

當我們對 dom 的修改會引發它外觀（樣式）上的改變時，就會觸發回流或重繪。

這個過程本質上還是因為我們對 dom 的修改觸發了渲染樹（render tree）的變化所導致的。

回流：當我們對 dom 的修改引發了 dom 幾何尺寸的變化（比如修改元素的寬、高或隱藏元素等）時，瀏覽器需要重新計算元素的幾何屬性（其他元素的幾何屬性和位置也會因此受到影響），然後再將計算的結果繪製出來。這個過程就是回流（也叫重排）。

重繪：當我們對 dom 的修改導致了樣式的變化、卻並未影響其幾何屬性（比如修改了顏色或背景色）時，瀏覽器不需重新計算元素的幾何屬性、直接為該元素繪製新的樣式（跳過了上圖所示的回流環節）。這個過程叫做重繪。

由此我們可以看出，重繪不一定導致回流，回流一定會導致重繪。硬要比較的話，回流比重繪做的事情更多，帶來的開銷也更大。但這兩個說到底都是吃效能的，所以都不是什麼善茬。我們在開發中，要從**層面出發，盡可能把回流和重繪的次數最小化。