根据Google Developer，Chromium项目里，渲染线程分为main thread和compositor thread。

如果CSS动画只是改变transforms和opacity，这时整个CSS动画得以在compositor thread完成（而JS动画则会在main thread执行，然后触发compositor进行下一步操作）
在JS执行一些昂贵的任务时，main thread繁忙，CSS动画由于使用了compositor thread可以保持流畅，可参考]adobe的博客](http://blogs.adobe.com/webplatform/2014/03/18/css-animations-and-transitions-performance/)。

在主线程中，维护了一棵Layer树（LayerTreeHost），管理了TiledLayer，在compositor thread，维护了同样一颗LayerTreeHostImpl，管理了LayerImpl，这两棵树的内容是拷贝关系。因此可以彼此不干扰，当Javascript在main thread操作LayerTreeHost的同时，compositor thread可以用LayerTreeHostImpl做渲染。当Javascript繁忙导致主线程卡住时，合成到屏幕的过程也是流畅的。

为了实现防假死，鼠标键盘消息会被首先分发到compositor thread，然后再到main thread。这样，当main thread繁忙时，compositor thread还是能够响应一部分消息，例如，鼠标滚动时，加入main thread繁忙，compositor thread也会处理滚动消息，滚动已经被提交的页面部分（未被提交的部分将被刷白）。

CSS动画比JS流畅的前提：

在Chromium基础上的浏览器中
JS在执行一些昂贵的任务
同时CSS动画不触发layout或paint
在CSS动画或JS动画触发了paint或layout时，需要main thread进行Layer树的重计算，这时CSS动画或JS动画都会阻塞后续操作。
参考CSS Triggers，只有如下属性的修改才符合“仅触发Composite，不触发layout或paint”：

backface-visibility
opacity
perspective
perspective-origin
transfrom
所以只有用上了3D加速或修改opacity时，才有机会用得上CSS动画的这一优势。

因此，在大部分应用场景下，效率角度更值得关注的还是下列问题。

• 是否导致layout
  repaint的面积
  是否是有高消耗的属性（css shadow等）
  是否启用硬件加速
  那么Chromium以外的其他浏览器呢？CSSTrick里比较了一次效率。

CSS3的动画的优点：

• 在性能上会稍微好一些，浏览器会对CSS3的动画做一些优化（比如专门新建一个图层用来跑动画）
  代码相对简单
  但其缺点也很明显：

• 在动画控制上不够灵活
  兼容性不好
  部分动画功能无法实现（如滚动动画，视差滚动等）
  JavaScript的动画正好弥补了这两个缺点，控制能力很强，可以单帧的控制、变换，同时写得好完全可以兼容IE6，并且功能强大。但想想CSS动画的transform矩阵是C++级的计算，必然要比javascript级的计算要快。另外对库的依赖也是一个很让人头疼的问题。

所以，对于一些复杂控制的动画，使用javascript会比较靠谱。而在实现一些小的交互动效的时候，就多考虑考虑CSS吧