最近接触页面性能的东西，有很多细微又原始的内容，比如浏览器渲染。资料非常多，所以选一些做节译，备忘。
JavaScript多次写、读DOM就会发生「布局颠簸」，引起文档重排(reflow – the process of constructing a render tree
| 代码如下 | 复制代码 |
|
from a DOM tree1)。 // 读 var h1 = element1.clientHeight; // 写 (布局作废) // 读 (触发布局) // 写 (布局作废) // 读 (触发布局) // 写 (布局作废) |
|
DOM被写时，布局就作废了，需要在某个时间点重排。但浏览器很懒，它想等到当前操作(或说帧)结束前再来重排。
不过，如果我们在当前操作(或说帧)结束前从DOM中读取几何数值，那么我们就强制浏览器提前重排布局，这就是所谓的「强制同步布局」(forced synchonous layout)，它会要了性能的命。
在现代的桌面浏览器上，布局颠簸的副作用可能并不明显；但放到低端移动设备上，问题就很严重了。
快速解决办法？#
在一个理想世界里，我们只要简单地重新排列代码执行顺序，就可以批量读DOM、批量写DOM。这意味着，文档只需一次重排。
| 代码如下 | 复制代码 |
|
// 读 var h1 = element1.clientHeight; var h2 = element2.clientHeight; var h3 = element3.clientHeight; // 写 (布局作废) // 文档在帧末重排 |
|
现实世界又如何？#
现实中可就没那么简单。大型程序中，代码散播各处，个个都存在这类危险的DOM。我们没法轻松(显然也不应该)把我们漂亮的、解藕的代码揉合一块，就只是为了控制住执行顺序。那么为了优化性能，我们怎样把读和写做批量处理？
来认识requestAnimationFrame#
window.requestAnimationFrame安排一个函数在下一帧执行，类似于setTimout(fn, 0)。这非常有用，因为我们可以用它来排定所有的DOM写操作在下一帧一同执行，DOM读操作就按现在的顺序同步执行。
| 代码如下 | 复制代码 |
|
// 读 var h1 = element1.clientHeight; // 写 // 读 // 写 |
|