jQuery
With jQuery animations went mainstream. But jQuery.animate is possibly the less efficient way for animating elements nowadays:- it doesn't use requestAnimationFrame
- it doesn't relay on css transitions and css animations
CSS transitions and animations
Native animations runs usually faster than JS ones. So it is quite obvious to use them when possible. There are plenty of tutorial on how to use them so google for it!Composite layer css properties
When you change a CSS property you trigger some operations in the browser. These are:- recalculating sizes and positions (layout)
- redrawing elements on the screen (paint)
- composite all elements together (composite)
The topmost operations triggers the ones below. Furthermore the more elements are involved the worst the animation is , performance wise.
You can visualize and debug this process in the useful timeline panel (inside Chrome developer tools).
The trick here is to use css properties that triggers only the composite step. These are opacity
and transform. This is article contains what you need to know.
Sadly it is not enough to use these for getting the performance jump, you should also trigger the creation of a new composite layer using these CSS rules:
.will-change{
transform: translate3d(0, 0, 0);
perspective: 1000;
backface-visibility: hidden;
}
For a better support you can add these browser prefixes:
.will-change{
-webkit-transform: translate3d(0, 0, 0); /*old chrome and safari*/
-o-transform: translate3d(0, 0, 0); /*old opera*/
-moz-transform: translate3d(0, 0, 0); /*old FF*/
-ms-transform: translate3d(0, 0, 0); /*IE9*/
transform: translate3d(0, 0, 0);
-webkit-perspective: 1000;
-o-perspective: 1000; /*old opera*/
perspective: 1000;
-webkit-backface-visibility: hidden;
-o-backface-visibility: hidden; /*old opera*/
backface-visibility: hidden;
}
Doing this opacity and transform are managed by the GPU if possible.
This can be a bit awkward and for this reason browser vendors have created a new css rules: will-change.
This will make the browser know that an element is going to change and to put it inside a compositing layer (this is not yet widely available so sadly, for now, it is better to stick with the hack).
Request Animation Frame
The way js animations work is changing a numeric CSS property over time. The only way to schedule an event in js was setTimeout (and its brother setInterval). As I mentioned they are still used by jQuery.
A while ago browser vendors introduced "requestAnimationFrame". It is a much better way to do it as it execute a piece of code right before the page refresh (approximately 60 times a second).
This is a polyfill for any browser (in the worst case it uses setTimeout).
If your animation depends on user interactions it can be a good idea to throttle the changes to the CSS using requestAnimationFrame. In this example I am using a queue with a simple policy that returns only the last function discarding the others.
function lastOne(q){
return q.length ? [q.pop()] : [];
}
function getRenderingQueue(policy){
var queue = [];
var isRunning = false;
policy = policy || function (q){return q;};
var render = function (){
var f;
queue = policy(queue);
isRunning = false;
while (f = queue.shift()){
f();
}
};
return {
empty: function (){
queue = [];
},
push: function (func){
queue.push(func);
if (!isRunning){
isRunning = true;
window.requestAnimationFrame(render);
}
}
}
}
var renderingQueue = getRenderingQueue(lastOne);
renderingQueue.push(function (){
//changing a piece of CSS
});
Depending on your application you can decide using a different policy.
This is it, I'll soon put this in context.
