Making CSS animations as smooth as it gets

When you start to animate with CSS you might find yourself in a situation where the animations are not as smooth as you would like them to be, this could be caused by some bad practices that overcomplicate the process of rendering your content - so, let’s start with the fundamentals

Understanding the pipeline

The rendering pipeline

There are basically three types of operations that a browser does after changes made to the styles to render the content on your website, those are:

1. Layout: The browser needs to calculate how much space your element takes up on the screen and if changes to the layout have to be done. It then needs to repaint those affected elements and composite them again. Properties that trigger layout (for example: top, left etc.)are generally to be avoided and they are usually guilty for page janking
2. Paint: After calculating how much space your browser needs for each element and how to position them — it has to fill those elements with pixels. This generally needs the most resources and is the reason why changes to layout that trigger mass repainting cause page jank
3. Compositing: After the elements are drawn the browser needs to determine which layers go on the top and which go on the bottom, this is generally the go-to point in css animating, because it does not trigger the two previous tasks and is the most resource-efficient, to be sure that the site is not going to freeze it’s best to use properties that skip the previous two and trigger only compositing

But how do I know which ones are the “good” properties for animating?

Generally speaking, you want to go for two properties, as they trigger only compositing and base your animations on them, they are:

• transform (usage: transform: [translate / rotate / skew / matrix / scale] and much more, go to MDN Article on Transform if you want to learn more about it)
• opacity (usage: opacity: [0–1] e.g. opacity: 0.65 for 65% opacity)

Those are the best optimized properties that most definitely won’t jank your page

If you want to learn more about which CSS properties trigger which operations — check out https://csstriggers.com/

Screenshot from https://csstriggers.com/

Making use of GPU Acceleration — will-change property

will-change is a CSS property that takes the optimization up a notch telling the browser that an element is going to be changed and allowing it to prepare to make use of hardware acceleration.

It needs to be used wisely though, as it could do more harm than good — it would sound logical to apply the property that optimizes your animation as often as possible, but that practice could eat up a lot of your application memory. Here are some tips:

• Don’t apply it too often. Your browser already does its best to optimize rendering, so overdoing it and telling it to optimize even more will just result in more memory consumption
• If you can predict users behaviour — apply will-change to elements that are going to change in a short amount of time, for example if an animation happens after a click — apply will-change on hover, the browser will have enough time to make the optimizations and prevent memory cluttering
• Make sure will-change is removed after animation is executed. You can do it with creating a css class and removing it with javascript or in some cases (for example applying it on hover on an element that triggers the animation on click) — plain css. This is important as it frees up memory and removes unused optimizations that unnecessarily use resources.

Removing will-change with javascript on animation end

If you want to go more in-depth with the will-change property — check out this article on official dev.opera website