当DOM十分庞大的时候，就不得不考虑网页的性能问题。浏览器的重绘(repaint)及重排版(reflow)的代价是昂贵的，尤其是重排版，因为重排版会影响元素本身及周围一批元素的位置。什么是重绘和重排版？应该怎样降低重绘和重排版带来的性能问题？
浏览器的渲染过程
浏览器从下载文档到显示页面的过程是个复杂的过程，这里包含了重绘和重排。各个浏览器引擎的工作原理略有差别，但也有一定规则。简单讲，通常在文档初次加载时，浏览器引擎会解析HTML文档来构建DOM树，之后根据DOM元素的几何属性构建一棵用于渲染的树。渲染树的每个节点都有大小和边距等属性，类似于盒子模型（由于隐藏元素不需要显示，渲染树中并不包含DOM树中隐藏的元素）。当渲染树构建完成后，浏览器就可以将元素放置到正确的位置了，再根据渲染树节点的样式属性绘制出页面。由于浏览器的流布局，对渲染树的计算通常只需要遍历一次就可以完成。但table及其内部元素除外，它可能需要多次计算才能确定好其在渲染树中节点的属性，通常要花3倍于同等元素的时间。这也是为什么我们要避免使用table做布局的一个原因。
再具体一些，就是：
1，浏览器解析html源码，然后创建一个 DOM树。
在DOM树中，每一个HTML标签都有一个对应的节点，并且每一个文本也都会有一个对应的文本节点。
DOM树的根节点就是 documentElement，对应的是html标签。
2，浏览器解析CSS代码，计算出最终的样式数据。
对CSS代码中非法的语法她会直接忽略掉。
解析CSS的时候会按照如下顺序来定义优先级：浏览器默认设置，用户设置，外链样式，内联样式，html中的style。
3，构建出DOM树，并且计算出样式数据后，下一步就是构建一个 渲染树（rendering tree）。
渲染树和DOM树有点像，但是是有区别的。DOM树完全和html标签一一对应，但是渲染树会忽略掉不需要渲染的元素，比如head、display:none的元素等。
而且一大段文本中的每一个行在渲染树中都是独立的一个节点。
渲染树中的每一个节点都存储有对应的css属性。
4，一旦渲染树创建好了，浏览器就可以根据渲染树直接把页面绘制到屏幕上。
一个例子：
<html> <head> <title>Beautiful page</title> </head> <body> <p> Once upon a time there was a looong paragraph... </p> <div style="display: none"> Secret message </div> <div><img src="..." /></div> ... </body> </html>
DOM树是完全和HTML标签一一对应的，如下所示：
documentElement (html)
head
title
body
p
[text node]
div
[text node]
div
img
...
而渲染树就不同了，她只有哪些需要绘制出来的元素，所以head 以及被隐藏的div都不会出现在渲染树中。
root (RenderView)
body
p
line 1
line 2
line 3
...
div
img
...
这样就可以比较清晰的了解DOM Tree和Render Tree了。
重绘及重排版
每个页面至少在初始化的时候会有一次重排操作。任何对渲染树的修改都有可能会导致下面两种操作：
1，重排
就是渲染树的一部分必须要更新 并且节点的尺寸发生了变化。这就会触发重排操作。
2，重绘
部分节点需要更新，但是没有改变他的集合形状，比如改变了背景颜色，这就会触发重绘。
那么，问题来了，什么情况下会发生重绘和重排版？
会引起重排的一些操作：
1. DOM元素的几何属性变化
当DOM元素的几何属性变化时，渲染树中的相关节点就会失效，浏览器会根据DOM元素的变化重新构建渲染树中失效的节点。之后，会根据新的渲染树重新绘制这部分页面。而且，当前元素的重排也许会带来相关元素的重排。例如，容器节点的渲染树改变时，会触发子节点的重新计算，也会触发其后续兄弟节点的重排，祖先节点需要重新计算子节点的尺寸也会产生重排。最后，每个元素都将发生重绘。可见，重排一定会引起浏览器的重绘，一个元素的重排通常会带来一系列的反应，甚至触发整个文档的重排和重绘，性能代价是高昂的。
2. DOM树的结构变化
当DOM树的结构变化时，例如节点的增减、移动等，也会触发重排。浏览器引擎布局的过程，类似于树的前序遍历，是一个从上到下从左到右的过程。通常在这个过程中，当前元素不会再影响其前面已经遍历过的元素。所以，如果在body最前面插入一个元素，会导致整个文档的重新渲染，而在其后插入一个元素，则不会影响到前面的元素。
3. 获取某些属性
浏览器引擎可能会针对重排做了优化。比如Opera，它会等到有足够数量的变化发生，或者等到一定的时间，或者等一个线程结束，再一起处理，这样就只发生一次重排。但除了渲染树的直接变化，当获取一些属性时，浏览器为取得正确的值也会触发重排。这样就使得浏览器的优化失效了。这些属性包括：offsetTop、offsetLeft、 offsetWidth、offsetHeight、scrollTop、scrollLeft、scrollWidth、scrollHeight、clientTop、clientLeft、clientWidth、clientHeight、getComputedStyle() (currentStyle in IE)。所以，在多次使用这些值时应进行缓存。
此外，改变元素的一些样式，调整浏览器窗口大小等等也都将触发重排。
会引起重绘的操作：
重绘是一个元素外观的改变所触发的浏览器行为，例如改变visibility、outline、背景色等属性。浏览器会根据元素的新属性重新绘制，使元素呈现新的外观。重绘不会带来重新布局，并不一定伴随重排。
可以看一个 具体的例子：
var bstyle = document.body.style; // cache bstyle.padding = "20px"; // reflow, repaint bstyle.border = "10px solid red"; // another reflow and a repaint bstyle.color = "blue"; // repaint only, no dimensions changed bstyle.backgroundColor = "#fad"; // repaint bstyle.fontSize = "2em"; // reflow, repaint // new DOM element - reflow, repaint document.body.appendChild(document.createTextNode('dude!'));
有些重绘操作会比其他操作昂贵很多。比如你修改了body的子元素，不一定会导致大量的其他节点更新，但是你把一个元素移动到页面顶部去，可能就会导致全部其他节点进行重排操作，这个代价就非常昂贵。
浏览器对重绘及重排版的一些优化
因为渲染树的改变导致的重绘或重排操作都可能代价很高，浏览器会对这个改动做很多优化。
一个策略就是不要立即做操作，而是批量进行。比如把你的脚本对DOM的修改放入一个队列，在队列所有操作结束后只需要进行一次绘制即可。
但是有的时候脚本可能会导致浏览器的批量优化无法进行，可能在清空队列之前就需要重新绘制（绘制意思是重绘或者重排）页面。比如你通过脚本获取这些样式：
offsetTop, offsetLeft, offsetWidth, offsetHeight等
因为浏览器必须给你最新的值，所以当你进行这些取值操作的时候会立刻触发一次页面的绘制。这样本来可以批量修改样式然后一次性绘制的方法就无法使用了。
减少重绘和重排版
1，对于需要使用脚本改变样式的元素，最好先写好一个class，通过添加class来减少重绘及重排版。例子：
// bad var left = 10, top = 10; el.style.left = left + "px"; el.style.top = top + "px"; // better el.className += " theclassname";
2，把对节点的大量修改操作放在页面之外
用 documentFragment来做修改
clone 节点，在clone之后的节点中做修改，然后直接替换掉以前的节点
通过 display: none 来隐藏节点（直接导致一次重排和重绘），做大量的修改，然后显示节点（又一次重排和重绘），总共只会有两次重排。
3，不要频繁获取计算后的样式。如果你需要使用计算后的样式，最好暂存起来而不是直接从DOM上读取。
4，总的来说，总是考虑到渲染树得存在，考虑到你的一次修改会导致多大的绘制操作。
比如绝对定位元素的动画就不会影响其他大部分元素。
