你是否是常常聽師兄或一些前端前輩說不能用
CSS
通配符*
,CSS
選擇器層疊不能超過三層,CSS
儘可能使用類選擇器,書寫HTML
少使用table
,結構要儘可能簡單-DOM
樹要小....等這些忠告,之前我就大概知道使用通配符或者CSS
選擇器層次過多可能會下降性能,至於爲何不使用table
標籤我一直是迷迷糊糊,也就跟着那樣作了,但我認識了Repain
和Reflow
以後,原來這些還真不能用太多。 ok,但願這篇文章對你有幫助!css
Repaint
/Reflow
?好,先上一張圖:瀏覽器解析大概的工做流程html
這張圖應該能夠很好理解,概括爲四個步驟:前端
一、解析HTML以構建DOM樹:
渲染引擎開始解析HTML文檔,轉換樹中的html標籤或js生成的標籤到DOM節點,它被稱爲 -- 內容樹。二、構建渲染樹:
解析CSS(包括外部CSS文件和樣式元素以及js生成的樣式),根據CSS選擇器計算出節點的樣式,建立另外一個樹 —- 渲染樹。三、佈局渲染樹:
從根節點遞歸調用,計算每個元素的大小、位置等,給每一個節點所應該出如今屏幕上的精確座標。四、繪製渲染樹:
遍歷渲染樹,每一個節點將使用UI後端層來繪製。web
好,咱們能夠看到Repain 和 Reflow 分別出如今了第三和第四步。所以咱們給出下面的定義:後端
對於DOM結構中的各個元素都有本身的盒子(模型),這些都須要瀏覽器根據各類樣式(瀏覽器的、開發人員定義的等)來計算並根據計算結果將元素放到它該出現的位置,這個過程稱之爲reflow;當各類盒子的位置、大小以及其餘屬性,例如顏色、字體大小等都肯定下來後,瀏覽器因而便把這些元素都按照各自的特性繪製了一遍,因而頁面的內容出現了,這個過程稱之爲repaint。
可見這兩個東東對瀏覽器渲染頁面是很重要的啊,都是會影響性能的,所以咱們須要瞭解一些常見的會引發repaint和reflow的一些操做,而且應該儘可能減小以提升渲染速度。瀏覽器
Repain
和Reflow
的一些操做Reflow
的成本比 Repaint
的成本高得多的多。DOM Tree
裏的每一個結點都會有 reflow
方法,一個結點的 reflow
頗有可能致使子結點,甚至父點以及同級結點的 reflow。在一些高性能的電腦上也許還沒什麼,可是若是 reflow
發生在手機上,那麼這個過程是很是痛苦和耗電的。
因此,下面這些動做有很大可能會是成本比較高的。佈局
注:display:none 會觸發 reflow,而 visibility:hidden 只會觸發 repaint,由於沒有發現位置變化。性能
Reflow是不可避免的,只能將Reflow對性能的影響減到最小,給出下面幾條建議:字體
不要一條一條地修改 DOM
的樣式。與其這樣,還不如預先定義好 css
的 class
,而後修改 DOM
的 className
:優化
// 很差的寫法 var left = 10, top = 10; el.style.left = left + "px"; el.style.top = top + "px"; // 推薦寫法 el.className += " theclassname";
把 DOM 離線後修改。如:a>
使用 documentFragment
對象在內存裏操做 DOM
。b>
先把 DOM
給 display:none
(有一次 repaint
),而後你想怎麼改就怎麼改。好比修改 100
次,而後再把他顯示出來。c>
clone
一個 DOM
節點到內存裏,而後想怎麼改就怎麼改,改完後,和在線的那個的交換一下。
不要把 DOM
節點的屬性值放在一個循環裏當成循環裏的變量。否則這會致使大量地讀寫這個結點的屬性。
儘量的修改層級比較低的 DOM
節點。固然,改變層級比較底的 DOM
節點有可能會形成大面積的 reflow
,可是也可能影響範圍很小。
爲動畫的 HTML
元件使用 fixed
或 absoult
的 position
,那麼修改他們的 CSS
是會大大減少 reflow
。
千萬不要使用 table
佈局。由於可能很小的一個小改動會形成整個 table
的從新佈局。
認識了這些是否是對瀏覽器的原理有更大興趣了?OK,後面會更新關於瀏覽器原理的文章,或者大家能夠先去搜搜別人的,由於我以爲理解瀏覽器的原理確實是很重要,能夠幫助咱們寫出性能更好的website
。