一直都聽說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上的節點并非一一對應,比如一個”<code>display:none"</code>的節點就隻會存在于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元素樣式且該樣式涉及到尺寸的改變
我們來通過一個例子直覺的感受下:
// read
var h1 = element1.clientheight;
// write (invalidates layout)
element1.style.height = (h1 * 2) + 'px';
// read (triggers layout)
var h2 = element2.clientheight;
element2.style.height = (h2 * 2) + 'px';
var h3 = element3.clientheight;
element3.style.height = (h3 * 2) + 'px';
clientheight,這個屬性是需要計算得到的,于是就會觸發浏覽器的一次layout。我們來利用chrome(v47.0)的開發者工具看下(截圖中的timeline record已經經過篩選,僅顯示layout):
上面的例子中,代碼首先修改了一個元素的樣式,接下來讀取另一個元素的<code>clientheight</code>屬性,由于之前的修改導緻目前dom被标記為髒,為了保證能準确的擷取這個屬性,浏覽器會進行一次layout(我們發現chrome的開發者工具良心的提示了我們這個性能問題)。
優化這段代碼很簡單,預先讀取所需要的屬性,在一起修改即可。
var h1 = element1.clientheight;
var h2 = element2.clientheight;
element1.style.height = (h1 * 2) + 'px';
element2.style.height = (h2 * 2) + 'px';
看下這次的情況:
下面再介紹一些其他的優化方案。
最小化layout的方案
上面提到的一個批量讀寫是一個,主要是因為擷取一個需要計算的屬性值導緻的,那麼哪些值是需要計算的呢?
再來看看别的情況:
面對一系列dom操作
針對一系列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);
這類優化方案的核心思想都是相同的,就是先對一個不在render tree上的節點進行一系列操作,再把這個節點添加回render tree,這樣無論多麼複雜的dom操作,最終都隻會觸發一次layout。
面對樣式的修改
針對樣式的改變,我們首先需要知道并不是所有樣式的修改都會觸發layout,因為我們知道layout的工作是計算renderobject的尺寸和大小資訊,那麼我如果隻是改變一個顔色,是不會觸發layout的。
像下面這種情況,和上面講優化的部分是一樣的,注意下讀寫即可。
elem.style.height = "100px"; // mark invalidated
elem.style.width = "100px";
elem.style.marginright = "10px";
elem.clientheight // force layout here
但是要提一下動畫,這邊講的是js動畫,比如:
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
任何可能導緻重繪的操作都應該放入<code>requestanimationframe</code>
在現實項目中,代碼按子產品劃分,很難像上例那樣組織批量讀寫。那麼這時可以把寫操作放在<code>requestanimationframe</code>的callback中,統一讓寫操作在下一次paint之前執行。
// write
requestanimationframe(function() {
element1.style.height = (h1 * 2) + 'px';
});
element2.style.height = (h2 * 2) + 'px';
可以很清楚的觀察到animation frame觸發的時機,mdn上說是在paint之前觸發,不過我估計是在js腳本交出控制權給浏覽器進行dom的invalidated check之前執行。
其他注意點
除了由于觸發了layout而導緻性能問題外,這邊再列出一些其他細節:
緩存選擇器的結果,減少dom查詢。這裡要特别提下htmlcollection。htmlcollection是通過<code>document.getelementbytagname</code>得到的對象類型,和數組類型很類似但是每次擷取這個對象的一個屬性,都相當于進行一次dom查詢:
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查詢時,<code>queryselector</code>和<code>queryselectorall</code>應該是最後的選擇,它們功能最強大,但執行效率很差,如果可以的話,盡量用其他方法替代。
下面兩個jsperf的連結,可以對比下性能。
自己對view層的想法
上面的内容理論方面的東西偏多,從實踐的角度來看,上面讨論的内容,正好是view層需要處理的事情。已經有一個庫fastdom來做這個事情,不過它的代碼是這樣的:
fastdom.read(function() {
console.log('read');
fastdom.write(function() {
console.log('write');
問題很明顯,會導緻<code>callback hell</code>,并且也可以預見到像fastdom這樣的imperative的代碼缺乏擴充性,關鍵在于用了<code>requestanimationframe</code>後就變成了異步程式設計的問題了。要讓讀寫狀态同步,那必然需要在dom的基礎上寫個wrapper來内部控制異步讀寫,不過都到了這份上,感覺可以考慮直接上react了……
總之,盡量注意避免上面說到的問題,但如果用庫,比如jquery的話,layout的問題出在庫本身的抽象上。像react引入自己的元件模型,用過virtual dom來減少dom操作,并可以在每次state改變時僅有一次layout,我不知道内部有沒有用<code>requestanimationframe</code>之類的,感覺要做好一個view層就挺有難度的,之後準備學學react的代碼。希望自己一兩年後會過來再看這個問題的時候,可以有些新的見解。
作者:leozdgao
來源:51cto