Animation performance and frame rate
This page is not complete.
Animation on the web can be done via
<video>, animated gifs and even animated PNGs and other image types. The performance cost of animating a CSS property can vary from one property to another, and animating expensive CSS properties can result in jank as the browser struggles to hit a smooth frame rate.
While performance is sensitive to the particular system and its load, performance tools can help you understand the work the browser's doing to render your site, and help you prevent and diagnose problems when they occur.
Users expect all interface interactions to be smooth and all user interfaces to be responsive. Animation can help make a site feel faster and responsive, but animations can also make a site feel slower and janky if not done correctly. Responsive user interfaces have a frame rate of 60 frames per second (fps). While it is not always possible to maintain 60fps, it is important to maintain a high and steady frame rate for all animations. Let's take a look at how we can use browser tools to inspect the frame rate. We'll also discuss some tips to create and maintain a fast and steady frame rate.
The developer tool's frame rate and waterfall charts provide insight into the work the browser is performing to animate code. Using these tools you can measure an application's animation frame rate, and diagnose performance bottlenecks if any are found.
With CSS animations you specify a number of keyframes, each of which uses CSS to define the appearance of the element at a particular stage of the animation. The browser creates the animation as a transition from each keyframe to the next.
However, the performance cost of modifying a CSS property can vary from one property to another. It's commonly accepted that 60 frames per second is the rate at which animations will appear smooth. For a rate of 60 frames per second, the browser has 16.7 milliseconds to execute scripts, recalculate styles and layout if needed, and repaint the area being updated. Slow scripts and animating expensive CSS properties can result in jank as the browser struggles to hit a smooth frame rate.
The process a browser uses to paint changes to a page when an element is animating CSS properties can be described as a waterfall consisting of the following steps:
- Recalculate Style: when a property for an element changes, the browser must recalculate computed styles.
- Layout: next, the browser uses the computed styles to figure out the position and geometry for the elements. This operation is labeled "layout" but is also sometimes called "reflow".
- Paint: finally, the browser needs to repaint the elements to the screen. One last step is not shown in this sequence: the page may be split into layers, which are painted independently and then combined in a process called "Composition".
These sequenced need to fit into a single frame, since the screen isn't updated until it is complete.
In the context of the rendering waterfall, some properties are more expensive than others:
|Properties that affect an element's geometry or position trigger a style recalculation, a layout and a repaint.|
Properties that don't affect geometry or position, but are not rendered in their own layer, do not trigger a layout.
|Properties that are rendered in their own layer don't even trigger a repaint, because the update is handled in composition.||
The CSS Triggers website shows how much of the waterfall is triggered for each CSS property, with information for most CSS properties by browser engine.
The intention of this scenario isn't to convince you that animating using
margin is always a bad idea. It's to demonstrate how the tools can give you insight into the work the browser is doing to render your site, and how you can apply that insight to diagnose and fix performance problems.
If you want to play along, the demo website is here. It looks like this:
It has two controls: a button to start/stop the animation, and a radio group to choose to animate using
margin, or to animate using
There's also a video version of this walkthrough:
Leaving the "Use margin" option set, start the animation, open the Performance tool, and make a recording. You'll only need to record a few seconds.
Open up the first recording. Exactly what you'll see depends a lot on your machine and system load, but it will be something like this:
This is showing three distinct views: (a) an overview of the Waterfall, (b) the frame rate, and (c) the timeline details.
This is showing frame rate. Average frame rate here is 46.67fps, well below the target of 60fps. Worse, though, is that the frame rate is very jagged, with lots of dips into the twenties and teens. It's unlikely you'll see a smooth animation here, especially when you add in user interaction.
The rest of the recording shows the Waterfall view. If you scroll through this, you'll see a pattern like this:
This is showing us the rendering waterfall. In each animation frame, we recalculate styles for every element, then perform a single layout, then a repaint.
You can see that paint especially is hurting performance here. In the screenshot above we've highlighted a paint operation, and the box on the right tells us it took 13.11ms. With only 16.7ms in our total budget, it's not surprising we are missing a consistently high frame rate.
You can experiment with this: try removing the box shadow using the Page Inspector, and see how that affects paint time. But next, we'll see how using
transform instead of
margin eliminates those expensive paints entirely.
Now switch the radio button in the web page to "Use transform", and make a new recording. It will look something like this:
Compared with the version that uses margin, this is looking pretty good. We're averaging nearly 60fps, and apart from one dip near the start, we're getting a consistently high frame rate.
The timeline view shows the reason for the improved frame rate. Compared with the version that uses margin, we're not spending any time in layout or (more importantly in this case) in paint:
In this case, using
transform significantly improved the site's performance, and the performance tools were able to show how and why it did.