作为一名web开发，总是希望自己开发web页面具有交互性并且运行顺畅，为了顺畅运行，滚动应与手指的滑动一样快，并且动画和交互应如丝绸般顺滑
60fps与设备刷新率
目前大多数设备的屏幕刷新率为 60 次/秒。因此，如果在页面中有一个动画或渐变效果，或者用户正在滚动页面，那么浏览器渲染动画或页面的每一帧的速率也需要跟设备屏幕的刷新率保持一致。
其中每个帧的预算时间仅比 16 毫秒多一点 (1 秒/ 60 = 16.66 毫秒)。但实际上，浏览器有整理工作要做，因此您的所有工作需要在 10 毫秒内完成。如果无法符合此预算，帧率将下降，并且内容会在屏幕上抖动。 此现象通常称为卡顿，会对用户体验产生负面影响。
像素管道
web页面其实就是把html、css、js中写的逻辑，映射到屏幕上的像素，主要包括一下五个主要区域
-
JavaScript。一般来说，我们会使用 JavaScript 来实现一些视觉变化的效果。比如用 jQuery 的 animate 函数做一个动画、对一个数据集进行排序或者往页面里添加一些 DOM 元素等。当然，除了 JavaScript，还有其他一些常用方法也可以实现视觉变化效果，比如：CSS Animations、Transitions 和 Web Animation API。 -
样式计算。此过程是根据匹配选择器（例如 .headline 或 .nav > .nav__item）计算出哪些元素应用哪些 CSS 规则的过程。从中知道规则之后，将应用规则并计算每个元素的最终样式。 -
布局。在知道对一个元素应用哪些规则之后，浏览器即可开始计算它要占据的空间大小及其在屏幕的位置。网页的布局模式意味着一个元素可能影响其他元素，例如 <body> 元素的宽度一般会影响其子元素的宽度以及树中各处的节点，因此对于浏览器来说，布局过程是经常发生的。 -
绘制。绘制是填充像素的过程。它涉及绘出文本、颜色、图像、边框和阴影，基本上包括元素的每个可视部分。绘制一般是在多个表面（通常称为层）上完成的。 -
合成。由于页面的各部分可能被绘制到多层，由此它们需要按正确顺序绘制到屏幕上，以便正确渲染页面。对于与另一元素重叠的元素来说，这点特别重要，因为一个错误可能使一个元素错误地出现在另一个元素的上层。
整个绘制过程中，页面都有机会产生卡顿，因为我们必须保证代码触发链路上的那部分逻辑
在网页合成的过程中，也许听过“栅格化”，这是因为绘制过程中分为两个步骤
- 创建绘图调用的列表
- 填充像素（栅格化）
不一定每一帧都是会经过这个管道的每一个部分，实际上不管是使用js，css，还是网络动画，在实现视觉变化时，管道针对指定帧运行通常有三种方式
：
1. JS/CSS >样式 > 布局 > 绘制 > 合成
如果您修改元素的“layout”属性，也就是改变了元素的几何属性（例如宽度、高度、左侧或顶部位置等），那么浏览器将必须检查所有其他元素，然后“自动重排”页面。任何受影响的部分都需要重新绘制，而且最终绘制的元素需进行合成。
2. JS / CSS > 样式 > 绘制 > 合成
如果您修改“paint only”属性（例如背景图片、文字颜色或阴影等），即不会影响页面布局的属性，则浏览器会跳过布局，但仍将执行绘制。
3. JS / CSS > 样式 > 合成
如果您更改一个既不要布局也不要绘制的属性，则浏览器将跳到只执行合成。
这个最后的版本开销最小，最适合于应用生命周期中的高压力点，例如动画或滚动。
性能在多数情况下，我们必须和浏览器配合，也不是跟他对着干，值得注意的是，上面列出的各管道工作，在计算开销上有所不同，一些任务比其他任务开销要大的多。
接下来，持续分析渲染过程中每一部分
JS执行优化
JS会经常触发视觉变化，有时是直接通过样式操作，有时是会产生视觉变化的计算，例如搜索数据或将其排序，时机不当或长时间运行的JS可能导致性能问题的常见原因。
- 对于动画实现，避免使用setTimeout或setInterval，请使用requestAnimateFrame
- 将长时间运行的javascript从主线程移动Web Worker
- 请使用微任务来执行对多个帧的DOM更改
- 使用 chrome Devtools的Timeline 和javascript分析器来评估对Javascript的影响
使用 requestAnimationFrame 来实现视觉变化
使用 setTimeout 或 setInterval 来执行动画之类的视觉变化，但这种做法的问题是，回调将在帧中的某个时点运行，可能刚好在未尾，而这可能经常会使我们丢失帧，导致卡顿
requestAnimationFrame 的基本思想让页面重绘的频率与这个刷新频率保持同步，比如显示器屏幕刷新率为 60Hz，使用requestAnimationFrame API，那么回调函数就每1000ms / 60 ≈ 16.7ms执行一次；如果显示器屏幕的刷新率为 75Hz，那么回调函数就每1000ms / 75 ≈ 13.3ms执行一次。
降低复杂性或使用 Web Worker
JavaScript 在浏览器的主线程上运行，恰好与样式计算、布局以及许多情况下的绘制一起运行。如果 JavaScript 运行时间过长，就会阻塞这些其他工作，可能导致帧丢失。
因此，您要妥善处理 JavaScript 何时运行以及运行多久。例如，如果在滚动之类的动画中，最好是想办法使 JavaScript 保持在 3-4 毫秒的范围内。超过此范围，就可能要占用太多时间。如果在空闲期间，则可以不必那么斤斤计较所占的时间。
在许多情况下，可以将纯计算工作移到 Web Worker，例如，如果它不需要 DOM 访问权限。数据操作或遍历（例如排序或搜索）往往很适合这种模型，加载和模型生成也是如此。
并非所有工作都适合此模型：Web Worker 没有 DOM 访问权限。如果您的工作必须在主线程上执行，请考虑一种批量方法，将大型任务分割为微任务，每个微任务所占时间不超过几毫秒，并且在每帧的 requestAnimationFrame 处理程序内运行。
了解 JavaScript 的“帧税”
在评估一个框架、库或您自己的代码时，务必逐帧评估运行 JavaScript 代码的开销。当执行性能关键的动画工作（例如变换或滚动）时，这点尤其重要。
测量 JavaScript 开销和性能情况的最佳方法是使用 Chrome DevTools。通常，您将获得如下的简单记录：
如果发现有长时间运行的 JavaScript，则可以在 DevTools 用户界面的顶部启用 JavaScript 分析器：
以这种方式分析 JavaScript 会产生开销，因此一定只在想要更深入了解 JavaScript 运行时特性时才启用它。启用此复选框后，现在可以执行相同的操作，您将获得有关 JavaScript 中调用了哪些函数的更多信息：
有了这些信息之后，您可以评估 JavaScript 对应用性能的影响，并开始找出和修正函数运行时间过长的热点。如前所述，应当设法移除长时间运行的 JavaScript，或者若不能移除，则将其移到 Web Worker 中，腾出主线程继续执行其他任务。
避免微优化 JavaScript
知道浏览器执行一个函数版本比另一个函数要快 100 倍可能会很酷，比如请求元素的offsetTop比计算getBoundingClientRect()要快，但是，您在每帧调用这类函数的次数几乎总是很少，因此，把重点放在 JavaScript 性能的这个方面通常是白费劲。您一般只能节省零点几毫秒的时间。
