Maintain 60fps whenever you are animating, because any less results in stutters or stalls that will be noticeable to your users and negatively impact their experiences.
- Take care that your animations don’t cause performance issues; ensure that you know the impact of animating a given CSS property.
- Animating properties that change the geometry of the page (layout) or cause painting are particularly expensive.
- Where you can, stick to changing transforms and opacity.
will-changeto ensure that the browser knows what you plan to animate.
Animating properties is not free, and some properties are cheaper to animate than others. For example, animating the
height of an element changes its geometry and may cause other elements on the page to move or change size. This process is called layout (or reflow in Gecko-based browsers like Firefox), and can be expensive if your page has a lot of elements. Whenever layout is triggered, the page or part of it will normally need to be painted, which is typically even more expensive than the layout operation itself.
Where you can, you should avoid animating properties that trigger layout or paint. For most modern browsers, this means limiting animations to
will-change property #
will-change to ensure the browser knows that you intend to change an element’s property. This allows the browser to put the most appropriate optimizations in place ahead of when you make the change. Don't overuse
will-change, however, because doing so can cause the browser to waste resources, which in turn causes even more performance issues.
The general rule of thumb is that if the animation might be triggered in the next 200ms, either by a user’s interaction or because of your application’s state, then having
will-change on animating elements is a good idea. For most cases, then, any element in your app’s current view that you intend to animate should have
will-change enabled for whichever properties you plan to change. In the case of the box sample we’ve been using throughout the previous guides, adding
will-change for transforms and opacity looks like this:
will-change: transform, opacity;
Now the browsers that support it, currently most modern browsers, will make the appropriate optimizations under the hood to support changing or animating those properties.
Other changes to transforms and opacity can, in many cases, also be handled by the compositor thread.
For more information about which work is triggered by animating a given property, see CSS Triggers.