requestAnimationFrame API

Screenreader Text Goes Here

The requestAnimationFrame API gives web developers a means to create power efficient and smooth animations. This API will take page visibility and the display's refresh rate into account to determine how many frames per second to allocate to the animation. In this demo, the left clock animation is powered by setTimeout, and the right clock animation is powered by requestAnimationFrame. The time shown is the same as both clocks are animated using time based animation. However, the requestAnimationFrame based clock is smoother and more efficient. Try changing the setTimeout period or minimizing your browser to see the difference in efficiency.

setTimeout based animations - 1ms / 10ms / 15ms
Expected callbacks: 0
Actual callbacks: 0
Callback Efficiency: 100%
CPU Efficiency: Medium
Power Consumption: Medium
Background Interference: High

requestAnimationFrame based animations
Actual callbacks: 0
Expected callbacks: 0
Callback Efficiency: 100%
CPU Efficiency: High
Power Consumption: Low
Background Interference: Low

Your browser does not currently support the requestAnimationFrame API, an emerging specification in the Web Performance Working Group.

About the requestAnimationFrame API

Until now, the web platform did not provide an efficient means for web developers to schedule graphics timers for animations. Animations are commonly overdrawing causing choppier animations and increased power consumption. Further efficiency is lost as animations are drawn without knowledge of whether the page is visible to the user.

For example, most animations use a timer period of less than 16.7ms to draw animations, even though most monitors can only display at 60Hz frequency or 16.7ms periods. For example, using setTimeout with a 10ms period results in every third callback not being painted, as another callback occurs prior to the display refresh. This overdrawing results in not only choppy animations, as every third frame being lost, but an overall increased resource consumption. This can be seen in the power consumption and CPU efficiency ratings above. Try changing the setTimeout period; you will be able to see that the animation on the left is slightly choppy and has a higher resource consumption than the animation on the right.

The requestAnimationFrame API also takes the visibility of the page into account. Without knowing the visibility state of a page, timers typically fire as if the page is always visible. Try minimizing the browser for a few moments and then return to this demo. You will notice that the animation using requestAnimationFrame has had fewer callbacks than the animation using setTimeout. This is because requestAnimationFrame will automatically throttle callbacks when the page is not visible, to be more power conscious. Because of this reason, setTimeout always has higher background interference than requestAnimationFrame.

The requestAnimationFrame API is being designed in the Web Performance Working Group. As this API is an emerging standard, this interface has been implemented with a ms vendor prefix. Special thanks to the Google, Mozilla and other members of the working group in helping design this interface.