渲染性能=数量*时间
数量：每次渲染影响到的元素数量
时间：每次渲染周期耗时。
衡量动画渲染是否流畅的标准是FPS（每秒画面更新的次数）。我们的目标是，60帧动画——尽可能的在1秒内做更多次的渲染。算下来每一帧拥有16ms的时间，考虑到浏览器自身的工作也需要时间。留给我们的可能只有10ms!
方法：
javascript方面
在JavaScript阶段时机不当或长时间运行的 JavaScript 是导致性能问题的主要原因。
·节流函数
·善用requestAnimationFrame
·用web worker分担计算压力
style方面
在Style阶段50%的时间用于匹配选择器，另外50%用于计算最终样式。
·降低选择器的复杂度：参考bem规范
·减少必须计算其样式的元素数量：Computed Style会将所有css选择器中的数值转换为屏幕上的真实像素值。
诸如Calc()都会影响计算效率。
！除非涉及到密集的动态样式计算，否则不应当先从计算样式这块入手进行性能优化。
layout方面
布局的开销主要在于需要布局的DOM数量和布局结构的复杂度。layout应当尽量避免，在无法避免时也应当尽量减少需要layout的元素数量。
·减少布局操作：任何对“几何属性”（如宽度、高度、左侧或顶部）的更改都需要布局计算。
·避免强制同步布局：在一般流程下，首先 JavaScript 运行，然后计算样式，然后布局。但是，JavaScript可以强制浏览器提前执行布局。这被称为强制同步布局。
console.log(dom.offsetHeight);dom.classList.add("add-height");
为了回答console中的问题，浏览器必须立刻计算布局，并返回新的dom信息。
某些条件下我们确实需要最新的信息，但是在不少情况下，我们所需的信息和所改变的样式无关。即使是前一帧的数据也可以满足需求。
·避免布局抖动:布局抖动发生在JavaScript中短期内反复读写DOM，导致文档重排。
1,分离读写操作
2,可以尝试了解fastDOM
3,或者在requestAnimationFrame中执行
Paint方面
该阶段往往是整个渲染链路中最耗时的部分，应当尽力避开此阶段
·尽力避开paint阶段：善用transform和opacity属性
·不会影响到文档流
·不依赖于文档流
·不会引起重绘
·减少paint区域：没有在可视区域的dom应减少绘制数量。如果某一块dom，时常变化，而后面dom几乎不变，把这块dom添加到gpu
·降低paint的复杂度：带阴影效果和不带阴影效果性能消耗不一样的。
参考链接：
chrome中的GPU加速合成：
https://dev.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome
关键渲染路径：
https://www.chromium.org/developers/the-rendering-critical-path
从内部观察浏览器：
https://developers.google.com/web/updates/2018/09/inside-browser-part1#browser-architecture
