渲染性能=数量*时间

数量：每次渲染影响到的元素数量

时间：每次渲染周期耗时。

衡量动画渲染是否流畅的标准是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