摘要：首先，對(duì)象本身也是一個(gè)對(duì)象，所以嚴(yán)格來(lái)說(shuō)，并不是操作這個(gè)對(duì)象慢，而是說(shuō)操作了這個(gè)對(duì)象后，會(huì)觸發(fā)一些瀏覽器行為，比如布局和繪制。一般被稱為布局，這個(gè)操作是用來(lái)計(jì)算文檔中元素的位置和大小，是渲染前重要的一步。

也可以在這里看：http://leozdgao.me/why-dom-slow/

一直都聽(tīng)說(shuō)DOM很慢，要盡量少的去操作DOM，于是就想進(jìn)一步去探究下為什么大家都會(huì)這樣說(shuō)，在網(wǎng)上學(xué)習(xí)了一些資料，這邊整理出來(lái)。

首先，DOM對(duì)象本身也是一個(gè)js對(duì)象，所以嚴(yán)格來(lái)說(shuō)，并不是操作這個(gè)對(duì)象慢，而是說(shuō)操作了這個(gè)對(duì)象后，會(huì)觸發(fā)一些瀏覽器行為，比如布局（layout）和繪制（paint）。下面主要先介紹下這些瀏覽器行為，闡述一個(gè)頁(yè)面是怎么最終被呈現(xiàn)出來(lái)的，另外還會(huì)從代碼的角度，來(lái)說(shuō)明一些不好的實(shí)踐以及一些優(yōu)化方案。

一個(gè)瀏覽器有許多模塊，其中負(fù)責(zé)呈現(xiàn)頁(yè)面的是渲染引擎模塊，比較熟悉的有WebKit和Gecko等，這里也只會(huì)涉及這個(gè)模塊的內(nèi)容。

先用文字大致闡述下這個(gè)過(guò)程：

解析HTML，并生成一棵DOM tree

解析各種樣式并結(jié)合DOM tree生成一棵Render tree

對(duì)Render tree的各個(gè)節(jié)點(diǎn)計(jì)算布局信息，比如box的位置與尺寸

根據(jù)Render tree并利用瀏覽器的UI層進(jìn)行繪制

其中DOM tree和Render tree上的節(jié)點(diǎn)并非一一對(duì)應(yīng)，比如一個(gè)display:none的節(jié)點(diǎn)就在會(huì)存在與DOM tree上，而不會(huì)出現(xiàn)在Render tree上，因?yàn)檫@個(gè)節(jié)點(diǎn)不需要被繪制。

上圖是Webkit的基本流程，在術(shù)語(yǔ)上和Gecko可能會(huì)有不同，這里貼上Gecko的流程圖，不過(guò)文章下面的內(nèi)容都會(huì)統(tǒng)一使用Webkit的術(shù)語(yǔ)。

影響頁(yè)面呈現(xiàn)的因素有許多，比如link的位置會(huì)影響首屏呈現(xiàn)等。但這里主要集中討論與layout相關(guān)的內(nèi)容。

paint是一個(gè)耗時(shí)的過(guò)程，然而layout是一個(gè)更耗時(shí)的過(guò)程，我們無(wú)法確定layout一定是自上而下或是自下而上進(jìn)行的，甚至一次layout會(huì)牽涉到整個(gè)文檔布局的重新計(jì)算。

但是layout是肯定無(wú)法避免的，所以我們主要是要最小化layout的次數(shù)。

在考慮如何最小化layout次數(shù)之前，要先了解什么時(shí)候?yàn)g覽器會(huì)進(jìn)行l(wèi)ayout。

layout（reflow）一般被稱為布局，這個(gè)操作是用來(lái)計(jì)算文檔中元素的位置和大小，是渲染前重要的一步。在HTML第一次被加載的時(shí)候，會(huì)有一次layout之外，js腳本的執(zhí)行和樣式的改變同樣會(huì)導(dǎo)致瀏覽器執(zhí)行l(wèi)ayout，這也是本文的主要要討論的內(nèi)容。

一般情況下，瀏覽器的layout是lazy的，也就是說(shuō)：在js腳本執(zhí)行時(shí)，是不會(huì)去更新DOM的，任何對(duì)DOM的修改都會(huì)被暫存在一個(gè)隊(duì)列中，在當(dāng)前js的執(zhí)行上下文完成執(zhí)行后，會(huì)根據(jù)這個(gè)隊(duì)列中的修改，進(jìn)行一次layout。

然而有時(shí)希望在js代碼中立刻獲取最新的DOM節(jié)點(diǎn)信息，瀏覽器就不得不提前執(zhí)行l(wèi)ayout，這是導(dǎo)致DOM性能問(wèn)題的主因。

如下的操作會(huì)打破常規(guī)，并觸發(fā)瀏覽器執(zhí)行l(wèi)ayout：

通過(guò)js獲取需要計(jì)算的DOM屬性

添加或刪除DOM元素

resize瀏覽器窗口大小

改變字體

css偽類的激活，比如:hover

通過(guò)js修改DOM元素樣式且該樣式涉及到尺寸的改變

我們來(lái)通過(guò)一個(gè)例子直觀的感受下：

// 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";

這里涉及一個(gè)屬性clientHeight，這個(gè)屬性是需要計(jì)算得到的，于是就會(huì)觸發(fā)瀏覽器的一次layout。我們來(lái)利用chrome（v47.0）的開(kāi)發(fā)者工具看下（截圖中的timeline record已經(jīng)經(jīng)過(guò)篩選，僅顯示layout）：

上面的例子中，代碼首先修改了一個(gè)元素的樣式，接下來(lái)讀取另一個(gè)元素的clientHeight屬性，由于之前的修改導(dǎo)致當(dāng)前DOM被標(biāo)記為臟，為了保證能準(zhǔn)確的獲取這個(gè)屬性，瀏覽器會(huì)進(jìn)行一次layout（我們發(fā)現(xiàn)chrome的開(kāi)發(fā)者工具良心的提示了我們這個(gè)性能問(wèn)題）。

優(yōu)化這段代碼很簡(jiǎn)單，預(yù)先讀取所需要的屬性，在一起修改即可。

// 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";

看下這次的情況：

下面再介紹一些其他的優(yōu)化方案。

上面提到的一個(gè)批量讀寫是一個(gè)，主要是因?yàn)楂@取一個(gè)需要計(jì)算的屬性值導(dǎo)致的，那么哪些值是需要計(jì)算的呢？

這個(gè)鏈接里有介紹大部分需要計(jì)算的屬性：http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-webkit.html

再來(lái)看看別的情況：

針對(duì)一系列DOM操作（DOM元素的增刪改），可以有如下方案：

documentFragment

display: none

cloneNode

比如（僅以documentFragment為例）：

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);

這類優(yōu)化方案的核心思想都是相同的，就是先對(duì)一個(gè)不在Render tree上的節(jié)點(diǎn)進(jìn)行一系列操作，再把這個(gè)節(jié)點(diǎn)添加回Render tree，這樣無(wú)論多么復(fù)雜的DOM操作，最終都只會(huì)觸發(fā)一次layout。

針對(duì)樣式的改變，我們首先需要知道并不是所有樣式的修改都會(huì)觸發(fā)layout，因?yàn)槲覀冎纋ayout的工作是計(jì)算RenderObject的尺寸和大小信息，那么我如果只是改變一個(gè)顏色，是不會(huì)觸發(fā)layout的。

這里有一個(gè)網(wǎng)站CSS triggers，詳細(xì)列出了各個(gè)CSS屬性對(duì)瀏覽器執(zhí)行l(wèi)ayout和paint的影響。

像下面這種情況，和上面講優(yōu)化的部分是一樣的，注意下讀寫即可。

elem.style.height = "100px"; // mark invalidated
elem.style.width = "100px";
elem.style.marginRight = "10px";

elem.clientHeight // force layout here

但是要提一下動(dòng)畫，這邊講的是js動(dòng)畫，比如：

function animate (from, to) {
  if (from === to) return

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

animate(100, 500)

動(dòng)畫的每一幀都會(huì)導(dǎo)致layout，這是無(wú)法避免的，但是為了減少動(dòng)畫帶來(lái)的layout的性能損失，可以將動(dòng)畫元素絕對(duì)定位，這樣動(dòng)畫元素脫離文本流，layout的計(jì)算量會(huì)減少很多。

任何可能導(dǎo)致重繪的操作都應(yīng)該放入requestAnimationFrame

在現(xiàn)實(shí)項(xiàng)目中，代碼按模塊劃分，很難像上例那樣組織批量讀寫。那么這時(shí)可以把寫操作放在requestAnimationFrame的callback中，統(tǒng)一讓寫操作在下一次paint之前執(zhí)行。

// 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觸發(fā)的時(shí)機(jī)，MDN上說(shuō)是在paint之前觸發(fā)，不過(guò)我估計(jì)是在js腳本交出控制權(quán)給瀏覽器進(jìn)行DOM的invalidated check之前執(zhí)行。

除了由于觸發(fā)了layout而導(dǎo)致性能問(wèn)題外，這邊再列出一些其他細(xì)節(jié)：

緩存選擇器的結(jié)果，減少DOM查詢。這里要特別體下HTMLCollection。HTMLCollection是通過(guò)document.getElementByTagName得到的對(duì)象類型，和數(shù)組類型很類似但是每次獲取這個(gè)對(duì)象的一個(gè)屬性，都相當(dāng)于進(jìn)行一次DOM查詢：

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

比如上面的這段代碼會(huì)導(dǎo)致無(wú)限循環(huán)，所以處理HTMLCollection對(duì)象的時(shí)候要最些緩存。

另外減少DOM元素的嵌套深度并優(yōu)化css，去除無(wú)用的樣式對(duì)減少layout的計(jì)算量有一定幫助。

在DOM查詢時(shí)，querySelector和querySelectorAll應(yīng)該是最后的選擇，它們功能最強(qiáng)大，但執(zhí)行效率很差，如果可以的話，盡量用其他方法替代。

下面兩個(gè)jsperf的鏈接，可以對(duì)比下性能。

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

上面的內(nèi)容理論方面的東西偏多，從實(shí)踐的角度來(lái)看，上面討論的內(nèi)容，正好是View層需要處理的事情。已經(jīng)有一個(gè)庫(kù)FastDOM來(lái)做這個(gè)事情，不過(guò)它的代碼是這樣的：

fastdom.read(function() {
  console.log("read");
});

fastdom.write(function() {
  console.log("write");
});

問(wèn)題很明顯，會(huì)導(dǎo)致callback hell，并且也可以預(yù)見(jiàn)到像FastDOM這樣的imperative的代碼缺乏擴(kuò)展性，關(guān)鍵在于用了requestAnimationFrame后就變成了異步編程的問(wèn)題了。要讓讀寫狀態(tài)同步，那必然需要在DOM的基礎(chǔ)上寫個(gè)Wrapper來(lái)內(nèi)部控制異步讀寫，不過(guò)都到了這份上，感覺(jué)可以考慮直接上React了......

總之，盡量注意避免上面說(shuō)到的問(wèn)題，但如果用庫(kù)，比如jQuery的話，layout的問(wèn)題出在庫(kù)本身的抽象上。像React引入自己的組件模型，用過(guò)virtual DOM來(lái)減少DOM操作，并可以在每次state改變時(shí)僅有一次layout，我不知道內(nèi)部有沒(méi)有用requestAnimationFrame之類的，感覺(jué)要做好一個(gè)View層就挺有難度的，之后準(zhǔn)備學(xué)學(xué)React的代碼。希望自己一兩年后會(huì)過(guò)來(lái)再看這個(gè)問(wèn)題的時(shí)候，可以有些新的見(jiàn)解。

http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/

https://dev.opera.com/articles/efficient-javascript/?page=3

http://wilsonpage.co.uk/preventing-layout-thrashing/

https://www.nczonline.net/blog/2009/02/03/speed-up-your-javascript-part-4/

http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-webkit.html