#AnAwesomeCSSLinkADay #YouDontMessWithCSS #CSS
Animating width and height has always been the classic "do not touch" for performance sensitive UI. Today we look at a Chrome change that makes some of those animations compositor friendly under the right conditions, and what that means for your CSS and View Transitions.
Chrome has quietly made a very big change to how it decides whether width and height animations must run on the main thread or can be promoted to the compositor. Here is what is going on behind the scenes.
- The old rule of thumb still stands: animating width or height normally forces Layout on every frame, which means the animation runs on the main thread and can easily jank if that thread is busy.
- Blink does a series of checks to decide if an animation is modular, and historically, the presence of width or height in keyframes was an automatic "main thread only" flag, even if the values in those keyframes never actually changed.
- Starting in Chrome 144 Canary, the engine now compares the effective width and height across all keyframes (including implicit keyframes and resolved values from things like auto) and, if the values do not change, the animation is allowed to run on the compositor instead of being forced onto the main thread.
- Initially this check was very strict, so tiny floating point differences like 97.984px vs 97.9844px still counted as "different", but a follow up patch added fuzzy matching so those near identical values are now treated as the same, keeping the animation modular.
- This is especially impactful for View Transitions, where ::view-transition-group(*) keyframes often include width and height that never change, so many of those transitions now automatically move to the compositor in recent Chrome Canary builds.
- The optimization currently exists only in Chrome and Chromium; other engines like Firefox and Safari still treat width and height animations as main thread work, although there is active discussion and bug tracking around similar improvements.
- When you really do need to change size, you still want to think like a performance engineer: consider converting width and height animations into transform: scale(...) based animations, or let your animation library do that mapping for you, so the compositor can stay in charge as much as possible.
- A concrete explanation of how Blink decides whether an animation can run on the compositor or must live on the main thread.
- The exact conditions under which width and height are now "safe" and compositable when their values stay constant across keyframes.
- Insight into the fuzzy matching patch that treats tiny numeric differences as equivalent in practice.
- A real world impact story for View Transitions, where ::view-transition-group(*) animations benefit immediately without code changes.
- Practical guidance on when to stick with size animations and when to rewrite as transform based scale animations.
- Lets you keep more of your existing keyframes and still get buttery smooth compositor level performance in Chrome.
- Automatically upgrades many View Transition powered UIs without touching a single line of CSS.
- Encourages a more nuanced mental model of "what is actually expensive" in the rendering pipeline, instead of blanket "never animate X" rules.
- Helps you debug performance using Chrome DevTools, where non composited animations are clearly surfaced, so you can iterate like an adult animation engineer.
- Signals where the platform is going: smarter engines that optimize common patterns, and standards discussions to give authors more control over main thread vs compositor trade offs.
- Will this change how comfortable you feel about animating width and height in your components?
- How do you currently decide between animating transform: scale(...) vs changing width or height directly?
- Have you profiled your View Transitions to see which animations are still stuck on the main thread?
- What kind of author facing API would you like to see for "please convert this size animation into a compositor friendly scale" in future CSS specs?
Today's link: https://www.bram.us/2025/11/13/animating-css-width-or-height-no-longer-force-a-main-thread-animation-in-chrome-under-the-right-conditions/