这是官方网址，貌似GSAP在chrome or firefox or opera等浏览器是调用HTML5原生的动画变换，但在官方给出的示例页面中（http://www.greensock.com/js/speed.html）,GSAP在IE下跑的帧数也明显高于jquery，GSAP官方也狂妄号称“20x faster than jQuery”，在IE下GSAP是如何做到比jquery更快的？
虽然我在实际测试中，比如一个div在animate的过程中，无论在chrome还是在IE下肉眼也无法区分到底哪个快，目前很想在项目中加入这个GSAP（虽然有91.6kb，挺大的，和jquery共存于footer中），还有何利弊？有再加GSAP的必要么？
老实说我第一次看到这么骇人的数字——“最多比jQuery快20倍！”——时，第一反应是，用例造假了。前端的优化很少能出现这么大幅度，这么明显的优化。
每当有这样的问题的时候，我们可以通过以下步骤来确定一个未知的框架的性能优化是怎么做到/伪造的：
- 黑盒：从官方用例来看，究竟有多快，快在哪儿
- 白盒：看看官方用例之内，框架怎么做到优化的
- do { 提出假设，自己构建用例测试 } while (假设没有得到验证);
- 得出结论
我在文章《“GSAP的动画快于jQuery吗？”》中记录了初步探究的路径，并在续文中做了若干实验，得出了结论：
GSAP的用例是否说明了GSAP快于jQuery呢？
是的，这可以说明GSAP更快。但并非是在任何时候都更快。在我们需要粒子系统时快，在我们只需要绘制一两个小交互时，它没有提供非常明显的性能优化的可能性。后者可以直接用CSS3 Animation/Translation做，或者用jQuery达到全浏览器兼容。若出现了粒子系统这样的大量元素重绘的需求，用GSAP是很好的选择。setInterval是否比requestAnimationFrame更慢？
不是的。在短的回调里，造成重绘的相关代码，requestAnimationFrame比setInterval稍微快一些；但是在长回调函数（多次构造requestAnimationFrame，它们会被合到一个里面）里，requestAnimationFrame不比setInterval快。集中定时器造成重绘是否比分散定时器造成重绘快？
是的。这也是GSAP更快的原因。
授人以鱼和授人以渔的大道理不多说，上文写出了得出结论的整个过程，建议LZ自己走一遍，体会一下工具与方法，而不是眼巴巴地看着，等到结论出来再死记结论，这样对于LZ的提高才真正有帮助。
p.s.（jQuery哭了，是个库就欺负他，全兼容有多不容易你知道嘛）