对众多应用程序而言，动画对提供友好的用户体验有着关键的作用，我们有很多方式生成 web 动画，比如 CSS {{cssxref("transition","transitions")}}/{{cssxref("animation","animations")}} 或者 JavaScript 动画 (使用 {{domxref("Window.requestAnimationFrame","requestAnimationFrame()")}}).
在这篇文章中，我们分析 CSS 动画和 JavaScript 动画的性能差异
CSS 中过渡和动画都可以用于编写动画，它们都有各自的使用场景：
就性能方面来说, 无论通过CSS animations 还是 transitions 创造动画，都没有区别。在这篇文章中二者都归类为基于CSS的动画.
{{domxref("Window.requestAnimationFrame","requestAnimationFrame()")}}提供了一种用JavaScript代码制作动画的高效方式。本方法的回调函数在绘制下一帧之前由浏览器调用。与需要一个延迟参数的{{domxref("WindowTimers.setTimeout","setTimeout()")}}/{{domxref("WindowTimers.setInterval","setInterval()")}}相比，requestAnimationFrame()效率高得多。开发人员可以在requestAnimationFrame回调函数中通过简单地改变元素的样式(或者更新画布绘制，等等)来创建动画。
注意:像CSS转换和动画一样，当页面在后台运行时，requestAnimationFrame()会暂停。
更多细节请阅读 animating with JavaScript from setinterval to requestAnimationFrame.
事实上，大多数场景下, 基于 CSS 的 动画几乎是跟 JavaScript 动画表现一致 — 至少在 FireFox 上是如此. 一些基于 Javascript 的动画库, 像 GSAP and Velocity.JS, 甚至声称他们在性能上可以做得比 native CSS transitions/animations （原生的 CSS transitions/animations）更好. 这是可能的，因为在重绘事件发生之前，CSS transitions/animations 在主的 UI 线程仅仅是重新采集元素的样式, 这跟通过 requestAnimationFrame() 回调，获取重新采集元素样式是一样的, 也是在下一次重绘之前触发. 假如二者都是在主 UI 线程创建的动画，那它们在性能方面没有差异.
在这一节，我们将会使用 FireFox 通过一个性能测试，去看看哪种动画方式更好
在进行示例之前，请启用FPS工具先查看当前帧速率:
开始在下面的测试中，总共1000个{{htmlelement("div")}}元素通过css动画进行坐标转换。
{{JSFiddleEmbed("https://jsfiddle.net/zt94oew2/1/","","480")}}
动画可以通过点击"toggle"按钮切换到 requestAnimationFrame() 。
试着两个都运行一下，比较两者的FPS值（第一个紫色框），可以看到CSS动画和requestAnimationFrame()是非常接近的。
即使是上面给出的测试结果，我们仍然认为CSS动画是更好的选择。为什么？关键是只要动画涉及的属性不引起reflow（重新布局）（参考CSS triggers获得更多信息），我们可以把采用操作移出主线程。最常见的属性是CSS transform。如果一个元素被提升为一个layer，transform属性动画就可以在GPU中进行。这意味着更好地性能，特别实在移动设备上。在OffMainThreadCompositing上寻找更多细节。
要在火狐中激活OMTA (脱离主线程的动画) ，你需要前往about:config然后搜索 layers.offmainthreadcomposition.async-animations 。切换到 true.
激活之后，再次运行上面的例子。可以看到CSS动画的帧速率现在高多了。
注意: 在Nightly/Developer 版本，你可能看到OMTA缺省就是激活的，所以你需要反过来测试。（先测试激活OMTA的情况，然后是没有激活的情况）
浏览器可以优化渲染流程。总之，我们总是可以尽可能通过CSS过渡/动画创建动画。如果你的动画真的很复杂，你可能不得不依赖于JavaScript动画。