HTML 5: Speed Up Your JavaScript-Animations with requestAnimationFrame

Thanks to CSS3 we no longer need Flash to produce good-looking animations. In general we do not even need JavaScript. But CSS3 falls short for some use cases. If you need to calculate or recalculate your animations, there's no getting round JavaScript. You do not have to use setTimeout and setInterval though. These do carry the disadvantage of simply repeating a function in defined intervals. Looking at animations, defined intervals are not the best way to make them work. If you have been using these two functions, you probably already experienced difficulties in finding the values for intervals in match with the required animation steps. Furthermore, setTimeout and setInterval rarely are in sync with the display refresh rate, which leads to the effect, that animations cannot be precisely presented.

requestAnimationFrame Shifts Responsibility To The Browser

With HTML 5 an alternative by the name of requestAnimationFrame was introduced. Its mode of operation is very similar to the before-known functions, with one big exception. Instead of defining the interval of the refresh rate, with all the above-mentioned down-sides, we leave that up to the browser. This is especially noticeable in comparison to setTimeout and setInterval, when you have more than one animation running parallel in the browser. These will not be felt as fluid and contemporary. The alternative, requestAnimationFrame reduces the frame rate, if necessary, thus keeping the animation fluid:

var schritt = 0;
function animation() {
 schritt += 10;
 document.getElementById("element").style.left = schritt + "px";
 window.requestAnimationFrame(animation);
}
window.requestAnimationFrame(animation);

In this example we animate an HTML element in steps of ten pixels from left to right. The default refresh rate usually is around sixty frames per second, but may vary due to cpu workloads. The browser does not try to stick to a fixed frame-rate. Another advantage of requestAnimationFrame is, that only animations in visible windows or tabs are run. As soon as the animation is detected in a window or tab that is not active at the moment, the animation is halted, but automatically resumed after the window or tab becomes active again. To stop animations manually, the function cancelAnimationFrame can be used.

Browser-Support Only With Vendor-Prefixing

At the time of this writing, only Webkit, Mozilla and the most recent Internet Explorer support the function requestAnimationFrame. The cancel-function cancelAnimationFrame is limited to Mozilla at the time being. As the functions are relatively new, a different syntax is needed for each browser. You can use a variable to set the corresponding prefixes:

var requestAnimationFrame = window.requestAnimationFrame || window.mozRequestAnimationFrame || window.webkitRequestAnimationFrame || window.msRequestAnimationFrame;

Conclusion: The performance of animations realized with requestAnimationFrame speaks for itself. They simply are much faster and more reliable. Thus, whenever possible, you should prefer this method over the conventional methods of the past, perhaps with a fallback for older browsers implemented. Especially users on mobile clients will profit from this method as mobile clients usually have lower processing power anyway. If you are looking for a well-made comparison, head over to Microsoft's Test Drive of the Internet Explorer! They of all people... (dpe)