Add a rows parameter to the URL to try different amounts of elements. (e.g. 10 rows)

A head to head comparison of CSS transitions and jQuery's animate. Rather than setting a timer to run repeatedly, transitions are handled natively by the browser. In my rather unscientific testing, transitions are always quicker, running with a higher frame rate, especially with high numbers of elements. They also have the advantage that colours can be animated easily, rather than having to rely on plugins.

Demo 1 - CSS3 transitioning multiple elements

Click the button to toggle the transition. Scroll down to see the jQuery version.

Click me!


Demo 2 - jQuery animate multiple elements

Click below to see the animation. Scroll up to see the CSS3 transitions version.

Click me!

Why such a huge difference?

A short answer is that jQuery is written in javascript, where as transitions are written in C++. However, that doesn't really do justice for the differences in the implementation.

To examine more closely what happens here, I used the Timeline view in the Webkit Inspector, and recorded the section whilst I clicked the buttons.

CSS Transitions

CSS3 transitions timeline

The image above shows the full extent of the animation above. There are a couple of things to notice here. Firstly the frame rate has been capped so unnecessary calculations and repaints aren't done. Secondly, only the area needed is repainted, in this case, the 712px × 652px rectangle surrounding the squares. The browser is able to decide on the number of frames, and how much things should change up front, and is able to sensibly decide what to do. The animation is either going to complete, or pause/stop part way through - we aren't going to suddenly be animating different properties part way through.

In this animation, only around 40 events happened.

jQuery Animate

jQuery animate timeline

A different story is shown here. Recalculate Style is run for every element that needs to be animated. This means that literally thousands (around 9,500) styles are recalculated during the animation, even though they are all identical. Because of this, on my machine, only a small number of repaints are completed. The browser can't predict up front what is going to happen, as the JS could do anything at any time - there is no guarantee that the animation is a simple tweening animation.

Reducing the number of elements by a large margin shows that usually, the order is: 1) Calculate all styles, 2) Set timers and Paint. With 10 rows of squares above, the first step takes around 0.4 seconds, meaning there is a fairly noticeable lag before the animation starts. For 10 rows of elements just over 1000 events (paints, calculate style etc) occur.

For a look at another example in javascript with a much more optimised animate function, have a look at this example which was written using the d3.js library. This provides some evidence that the jQuery animate function could be optimised somewhat.

Conclusion

Javascript animations based on timers can never be as quick as native animations, as they don't have access to enough of the browser to make the same optimisations. These animations should be used as a fallback only in legacy browsers. Now that browser support is so universal, there is rarely a case where javascript animations are preferable.

Comments/Questions?

Please add any questions/corrections/extra info below. Please be courteous to other users.

blog comments powered by Disqus

avenue-origin