爲何說DOM操做很慢

一直都據說DOM很慢，要儘可能少的去操做DOM，因而就想進一步去探究下爲何你們都會這樣說，在網上學習了一些資料，這邊整理出來。

首先，DOM對象自己也是一個js對象，因此嚴格來講，並非操做這個對象慢，而是說操做了這個對象後，會觸發一些瀏覽器行爲，好比佈局（layout）和繪製（paint）。下面主要先介紹下這些瀏覽器行爲，闡述一個頁面是怎麼最終被呈現出來的，另外還會從代碼的角度，來講明一些很差的實踐以及一些優化方案。

瀏覽器是如何呈現一張頁面的

一個瀏覽器有許多模塊，其中負責呈現頁面的是渲染引擎模塊，比較熟悉的有WebKit和Gecko等，這裏也只會涉及這個模塊的內容。

先用文字大體闡述下這個過程：

• 解析HTML，並生成一棵DOM tree
• 解析各類樣式並結合DOM tree生成一棵Render tree
• 對Render tree的各個節點計算佈局信息，好比box的位置與尺寸
• 根據Render tree並利用瀏覽器的UI層進行繪製

其中DOM tree和Render tree上的節點並不是一一對應，好比一個display:none的節點就在會存在與DOM tree上，而不會出如今Render tree上，由於這個節點不須要被繪製。

上圖是Webkit的基本流程，在術語上和Gecko可能會有不一樣，這裏貼上Gecko的流程圖，不過文章下面的內容都會統一使用Webkit的術語。

影響頁面呈現的因素有許多，好比link的位置會影響首屏呈現等。但這裏主要集中討論與layout相關的內容。

paint是一個耗時的過程，然而layout是一個更耗時的過程，咱們沒法肯定layout必定是自上而下或是自下而上進行的，甚至一次layout會牽涉到整個文檔佈局的從新計算。

可是layout是確定沒法避免的，因此咱們主要是要最小化layout的次數。

什麼狀況下瀏覽器會進行layout

在考慮如何最小化layout次數以前，要先了解何時瀏覽器會進行layout。

layout（reflow）通常被稱爲佈局，這個操做是用來計算文檔中元素的位置和大小，是渲染前重要的一步。在HTML第一次被加載的時候，會有一次layout以外，js腳本的執行和樣式的改變一樣會致使瀏覽器執行layout，這也是本文的主要要討論的內容。

通常狀況下，瀏覽器的layout是lazy的，也就是說：在js腳本執行時，是不會去更新DOM的，任何對DOM的修改都會被暫存在一個隊列中，在當前js的執行上下文完成執行後，會根據這個隊列中的修改，進行一次layout。

然而有時但願在js代碼中馬上獲取最新的DOM節點信息，瀏覽器就不得不提早執行layout，這是致使DOM性能問題的主因。

以下的操做會打破常規，並觸發瀏覽器執行layout：

• 經過js獲取須要計算的DOM屬性
• 添加或刪除DOM元素
• resize瀏覽器窗口大小
• 改變字體
• css僞類的激活，好比:hover
• 經過js修改DOM元素樣式且該樣式涉及到尺寸的改變

咱們來經過一個例子直觀的感覺下：

JavaScript

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

// Read var h1 = element1 . clientHeight ;   // Write (invalidates layout) element1 . style . height = ( h1 * 2 ) + 'px' ;   // Read (triggers layout) var h2 = element2 . clientHeight ;   // Write (invalidates layout) element2 . style . height = ( h2 * 2 ) + 'px' ;   // Read (triggers layout) var h3 = element3 . clientHeight ;   // Write (invalidates layout) element3 . style . height = ( h3 * 2 ) + 'px' ;

這裏涉及一個屬性clientHeight，這個屬性是須要計算獲得的，因而就會觸發瀏覽器的一次layout。咱們來利用chrome（v47.0）的開發者工具看下（截圖中的timeline record已經通過篩選，僅顯示layout）：

上面的例子中，代碼首先修改了一個元素的樣式，接下來讀取另外一個元素的clientHeight屬性，因爲以前的修改致使當前DOM被標記爲髒，爲了保證能準確的獲取這個屬性，瀏覽器會進行一次layout（咱們發現chrome的開發者工具良心的提示了咱們這個性能問題）。

優化這段代碼很簡單，預先讀取所須要的屬性，在一塊兒修改便可。

JavaScript

1 2 3 4 5 6 7 8 9

// Read var h1 = element1 . clientHeight ;    var h2 = element2 . clientHeight ;    var h3 = element3 . clientHeight ;   // Write (invalidates layout) element1 . style . height = ( h1 * 2 ) + 'px' ;    element2 . style . height = ( h2 * 2 ) + 'px' ;    element3 . style . height = ( h3 * 2 ) + 'px' ;

看下此次的狀況：

下面再介紹一些其餘的優化方案。

最小化layout的方案

上面提到的一個批量讀寫是一個，主要是由於獲取一個須要計算的屬性值致使的，那麼哪些值是須要計算的呢？

這個連接裏有介紹大部分須要計算的屬性：http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-webkit.html

再來看看別的狀況：

面對一系列DOM操做

針對一系列DOM操做（DOM元素的增刪改），能夠有以下方案：

• documentFragment
• display: none
• cloneNode

好比（僅以documentFragment爲例）：

JavaScript

1 2 3 4 5 6 7

var fragment = document . createDocumentFragment ( ) ;    for ( var i = 0 ; i < items . length ; i ++ ) {       var item = document . createElement ( "li" ) ;    item . appendChild ( document . createTextNode ( "Option " + i ) ;    fragment . appendChild ( item ) ; } list . appendChild ( fragment ) ;

這類優化方案的核心思想都是相同的，就是先對一個不在Render tree上的節點進行一系列操做，再把這個節點添加回Render tree，這樣不管多麼複雜的DOM操做，最終都只會觸發一次layout。

面對樣式的修改

針對樣式的改變，咱們首先須要知道並非全部樣式的修改都會觸發layout，由於咱們知道layout的工做是計算RenderObject的尺寸和大小信息，那麼我若是隻是改變一個顏色，是不會觸發layout的。

這裏有一個網站CSS triggers，詳細列出了各個CSS屬性對瀏覽器執行layout和paint的影響。

像下面這種狀況，和上面講優化的部分是同樣的，注意下讀寫便可。

JavaScript

1 2 3 4 5

elem . style . height = "100px" ; // mark invalidated   elem . style . width = "100px" ;    elem . style . marginRight = "10px" ;   elem . clientHeight // force layout here

可是要提一下動畫，這邊講的是js動畫，好比：

JavaScript

1 2 3 4 5 6 7 8 9 10 11

function animate ( from , to ) {       if ( from === to ) return      requestAnimationFrame ( function ( ) {      from += 5      element1 . style . height = from + "px"      animate ( from , to )    } ) }   animate ( 100 , 500 )

動畫的每一幀都會致使layout，這是沒法避免的，可是爲了減小動畫帶來的layout的性能損失，能夠將動畫元素絕對定位，這樣動畫元素脫離文本流，layout的計算量會減小不少。

使用requestAnimationFrame

任何可能致使重繪的操做都應該放入requestAnimationFrame

在現實項目中，代碼按模塊劃分，很難像上例那樣組織批量讀寫。那麼這時能夠把寫操做放在requestAnimationFrame的callback中，統一讓寫操做在下一次paint以前執行。

JavaScript

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

// Read var h1 = element1 . clientHeight ;   // Write requestAnimationFrame ( function ( ) {       element1 . style . height = ( h1 * 2 ) + 'px' ; } ) ;   // Read var h2 = element2 . clientHeight ;   // Write requestAnimationFrame ( function ( ) {       element2 . style . height = ( h2 * 2 ) + 'px' ; } ) ;

能夠很清楚的觀察到Animation Frame觸發的時機，MDN上說是在paint以前觸發，不過我估計是在js腳本交出控制權給瀏覽器進行DOM的invalidated check以前執行。

其餘注意點

除了因爲觸發了layout而致使性能問題外，這邊再列出一些其餘細節：

緩存選擇器的結果，減小DOM查詢。這裏要特別體下HTMLCollection。HTMLCollection是經過document.getElementByTagName獲得的對象類型，和數組類型很相似可是每次獲取這個對象的一個屬性，都至關於進行一次DOM查詢：

JavaScript

1 2 3 4

var divs = document . getElementsByTagName ( "div" ) ;    for ( var i = 0 ; i < divs . length ; i ++ ) {    //infinite loop      document . body . appendChild ( document . createElement ( "div" ) ) ; }

好比上面的這段代碼會致使無限循環，因此處理HTMLCollection對象的時候要最些緩存。

另外減小DOM元素的嵌套深度並優化css，去除無用的樣式對減小layout的計算量有必定幫助。

在DOM查詢時，querySelector和querySelectorAll應該是最後的選擇，它們功能最強大，但執行效率不好，若是能夠的話，儘可能用其餘方法替代。

下面兩個jsperf的連接，能夠對比下性能。

https://jsperf.com/getelementsbyclassname-vs-queryselectorall/162
http://jsperf.com/getelementbyid-vs-queryselector/218

本身對View層的想法

上面的內容理論方面的東西偏多，從實踐的角度來看，上面討論的內容，正好是View層須要處理的事情。已經有一個庫FastDOM來作這個事情，不過它的代碼是這樣的：

JavaScript

1 2 3 4 5 6 7

fastdom . read ( function ( ) {       console . log ( 'read' ) ; } ) ;   fastdom . write ( function ( ) {       console . log ( 'write' ) ; } ) ;

問題很明顯，會致使callback hell，而且也能夠預見到像FastDOM這樣的imperative的代碼缺少擴展性，關鍵在於用了requestAnimationFrame後就變成了異步編程的問題了。要讓讀寫狀態同步，那必然須要在DOM的基礎上寫個Wrapper來內部控制異步讀寫，不過都到了這份上，感受能夠考慮直接上React了……

總之，儘可能注意避免上面說到的問題，但若是用庫，好比jQuery的話，layout的問題出在庫自己的抽象上。像React引入本身的組件模型，用過virtual DOM來減小DOM操做，並能夠在每次state改變時僅有一次layout，我不知道內部有沒有用requestAnimationFrame之類的，感受要作好一個View層就挺有難度的，以後準備學學React的代碼。但願本身一兩年後會過來再看這個問題的時候，能夠有些新的看法。