🤩 There’s a very – VERY! – exciting animations/performance change available in Chrome Canary:

Under the right conditions, width/height animations will no longer automatically force a Main Thread animation, but can be allowed to run on the Compositor.

~

So, we’ve always been told that animating CSS width and height is bad from a performance perspective, as that causes Layout to happen. This still is true.

Animating width or height requires Layout … but perhaps that’s not always needed?

~

Taking a step back: to determine if an animation can run on the compositor or not, Blink (Chrome’s engine) does a bunch of checks. One of those is a check for the presence of width or height in the keyframes. If you are animating those, the animation is forced to run on the Main Thread.

(Simplified) Flowchart of one of the checks Blink (Chrome’s engine) does to determine if an animation can run on the Compositor or not (pre-Chrome 144.0.7512.0 behavior).

As you can see, that’s quite a rough check because when width or height don’t actually change throughout the animation, you end up with an unnecessarily forced Main Thread animation.

~

So, you can probably see where this is headed: In Chrome 144.0.7512.0 (current Canary) we have extended the check to check whether the `width` or `height` actually change or not.

💡 If they don’t change, then we don’t need Layout, so then we don’t need to force it on the Main Thread.

Flowchart of the adjusted check Blink does from Chrome 144.0.7512.0 onwards.

It took some time to get this check right, as there’s a bunch of various scenarios. The simple one is simply checking all the values across all keyframes and compare those. But what about implicit keyframes? Or what when there’s a keyword like `auto` at play? Well, those are all covered by Blink 😊

~

This change is very exciting as it immediately optimizes a lot of View Transitions animations: the ::view-transition-group(*) pseudos have width and height in their keyframes … but most often these don’t ever change.

(Of course I had to turn this into something about View Transitions 😛)

Here’s before and after screenshots of Chrome DevTools showing a trace of the https://view-transitions.chrome.dev/cards/spa-auto/ demo. From Chrome 144.0.7512.0 onwards, the ::view-transition-group(*) animations run¹ on the compositor! Yay! 🎉

(¹ In this demo that is, because their width and height don’t change)

~

So, what about keyframes whose width and height do change? Can Blink optimize those? The answer is: not automatically, as there are some things to consider. One the (rough) ideas we have here, is to give you control of what needs to happen. This is being proposed in https://github.com/w3c/csswg-drafts/issues/13064.

In the meantime, you can optimize the keyframes yourself by translating the width/height into a scale animation. I have detailed this before here on my blog, applied to View Transitions. This approach is used by Google Search itself in production.

If you are using an animation framework, it can most likely do this for you as well. Motion for example does this quite cleverly as it can also counteract distortions.

~

Chrome no longer forces width/height animations to run on the Main Thread, in case those values don’t actually change throughout an animation.

~

# Spread the word

Feel free to reshare one of the following posts on social media to help spread the word:

• 🦋 BlueSky
• 🦣 Mastodon
• 📘 LinkedIn

~

I’m hoping that other browsers will also implement this optimization over time, as I think this is change is a huge performance win for the web as a whole.

~

Bramus is a frontend web developer from Belgium, working as a Chrome Developer Relations Engineer at Google. From the moment he discovered view-source at the age of 14 (way back in 1997), he fell in love with the web and has been tinkering with it ever since (more …) View more posts

Post navigation