Is it possible to restrict this as a user? Like to force webpages to use under a certain amount of render/paint time/resources or else just break so that one dumb tab doesn't use up all my battery? Then I can opt-in to greater resources usage if it's a webpage I actually care about.
I've seen the "This webpage is using alot of resources" popup before but I don't think it would happen in this case.
Because honestly I think this is horrifying. I would rather it switch from grey to red "recording" dot than use even the 6% the author decided was "fixed". In 99% of cases I do not care at all about the "artistic vision" of the UI designer and in the other 1% of cases (say an in-browser game or some useful data-viz) I could choose to allow the tab to go crazy with my resources.
Just wrap it in a container with fixed height and "overflow: hidden".
Now the layout engine knows that it doesn't need to recalculate positions of elements outside that wrapper, and it's much faster.
By the way, the same trick was speeding up large <table> rendering back in the day. As long as you know the size of your rows or columns ahead of time, which kinda defeats the purpose of <table>.
What amazes me is that so much a M2 Mac's resources would be used to render a website even if it rendered everything from scratch. There is almost no graphic content compared to a video game produced decades ago, and they would easily render a frame in 1/2 the time on decades old hardware
> On my M2 MacBook, the renderer process is now using 6% CPU (down from 15%), and the GPU process is now using 6% CPU and less than 1% GPU (down from 25% and 20%).
Wait, this is supposed to be an improvement? 6% CPU for a lame animation?
Does a note taking app need such an animation if apparently it's that easy to accidentally drain the users battery?
The UI of this app literally only has a piece of text, a button and this animated indicator. To render this it needs an entire chromium browser loaded into memory, and still it has performance issues.
I will always prefer software written in native graphics toolkits. I understand the benefits of using electron but the only electron based software I've ever liked was vscode.
> Instead, we can create the illusion of a changing height by using two rectangles, applying translate to each.
Its a very clever solution and props to the engineer, but this being the fix makes me truly despair at where we are as an industry around web UI. That html and css won despite these sorts of counter-intuitive horrors.
UI layers that make me feel good reflect intent. I can take an image and write some code to darken that image (any image) and show that to the end user. It makes sense. However, in html+css I have to introduce a third element, another rectangle, slap it infront, paint it entirely black and set its opacity to something low. Sure, it works the same but it just feels so conceptually ugly.
My head is sort of reeling from this. If height animations are that expensive today, imagine how expensive (and still commonplace) they were twenty years ago.
I fortunately quit animating height quite a long time ago in favor of similar transform techniques, but… wow, still crazy to learn the magnitude of this common operation.
I read this article because just last week I set up CSS height transitions to show/hide divs in a form which displays conditional content (based on radio button selection). "Why shouldn't I do this?", I thought.
It looks like the point of this article is that you should avoid continuous animation for CPU performance reasons. These performance reasons are probably inconsequential for occasional transitions.
For many of us in the target demographic of "people who animate height", the scary title of this article is misleading.
How about we create tools that don't consume 5+ % of user's CPU (and keep it busy, not allowing it to sleep, decreasing battery life significantly) when idling or doing some background work?
>On my M2 MacBook, the renderer process is now using 6% CPU (down from 15%), and the GPU process is now using 6% CPU and less than 1% GPU (down from 25% and 20%).
I honestly can't imagine typing this out and patting myself on the back rather than thinking "wtf am I doing? It's 2025, I have a high end laptop, and this is a note taking app. The total resource utilization should be close to zero."
So good to see a developer who actually cares about resources. Thank you!
I usually develop my apps on a 1300 MHz single-core Intel Atom mini PC from 10 years ago. When something like this goes wrong, the app becomes unusable and I immediately notice it.
This helped explain why my PC uses so many resources "with just a few webpages open". I didn't realise that graphical updates that seem so simple could be so resource-intensive.
The worst modern invention. HTML/CSS is so bloody awful at rendering user interfaces. We should if at least contained it, if not killed it outright. But instead it’s a contagion that has spread far and wide.
How the hell does the optimized version use 6% of CPU? It should render at roughly 5000 frames per second.
I'm not 100% convinced. Likely because the article doesn't show the difference between animations that are announced with 'will-change' and/or elements that are animated with position absolute. Also, it looks related to the browser and there was no evidence that this is also a issue in FF or Chrome.
> On my M2 MacBook, the renderer process is now using 6% CPU (down from 15%), and the GPU process is now using 6% CPU and less than 1% GPU (down from 25% and 20%).
This still feels way too much compute for a tiny animation updating a couple times a second.
> On my M2 MacBook, the renderer process is now using 6% CPU (down from 15%), and the GPU process is now using 6% CPU and less than 1% GPU (down from 25% and 20%)
Ouch. All of this for a tiny visualizer animation.
This article doesn't apply to every single use case and should not be taken purely at face value.
A few week ago I needed to animate height for a banner like message that appeared in the layout (e.g. it was not absolutely positioned) once a user clicked a button. This banner message would cause a layout shift no matter what because its height was being added to the layout and shifting the elements underneath it down. Thus, to mitigate a jumpy layout, making the height animate made the layout shift easier on the eyes.
And before you say "well design it differently" - I didn't design this.
An alternative solution to this is to place the height animated objects inside of containers with a static vertical size that is equal to the maximum height of the animation
here's an idea - don't animate anything on a webpage.
Just. Don't.
NO ONE needs animation to convey information, unless that information is an animation, such as in an educational context, where interactive things demonstrate what is being taught.
I don't need to see your widget spin in 3d while I scroll down the page. I really don't. I don't even want to see that.
Web pages are slow because people make them slow. Stop making them slow.
I'm not sure how it's implemented on the JS side, but I can imagine the CSS getting a lot of updates per second as the voice level changes, constantly interrupting the current animation.
Might be worth it to buffer the input until animationEnd() event fires. That might reduce the amount of calculations and redrawing that needs to be done.
Or the CSS engine is robust enough to handle continual updates and this won't solve a thing. I'd have to test it.
CSS animations can sometimes cause weird performance issues or even crashes. 10 years back, animating box-shadow caused browsers to crash for our some of users by consuming a lot of memory: https://www.sheshbabu.com/posts/my-binary-search-debugging-s...
Does anyone have the courage to perform a similar inspection on the Cloudflare homepage like the author did? On my M4 Mac mini, Safari lagged with single-digit frames per second (FPS), which scared me so much that I had to close the page as quickly as possible.
Not just height, anything that causes continuous repaints can become expensive. Search for "jank free" to find more resources on the subject, or check this oldish website [1].
I’d be interested to see the performance of the same visualizer in a canvas or animated svg instead. Forcing these animations through the dom seems a little absurd to me, but I’ve been surprised by web performance before.
My personal call would be to use SVG for this - you can do CSS animations there just fine without triggering layout. Not a frontend expert but don't see why that wouldn't work.
Is it just me, or have a lot of modern startups lost the plot? Imagine doing all this work for an element of your app which has nothing to do with its feature set. No one cares (certainly no customer) about an audio visualizer bar animation.
The post is also riddled with all kinds of misunderstandings, as well. For example, the authoritative language used to describe the differences between layout/painting/compositing is just simply untrue generally speaking (though it might be w.r.t. Electron/Chromium). The W3C does not care how you implement your rendering engine, and even bringing up the spec betrays a misunderstanding of how these things work.
In typical fashion, we see yet another grandiose blog post about fixing a "perf issue" for your hipster new startup that is essentially notepad.exe. Who funds this shit?
The fact that this little animation can have such heavy performance impact tells us one thing: CSS design is flawed. That‘s it. That‘s the whole story.
Why do browsers even allow this shit. I was trying out a scheduling app the other day, and it was using 3% of CPU just sitting there doing nothing. That’s a Pentium 1 level of computing power to do jack shit.
This looks like a clever implementation of a useful feature. I enjoyed that the developer was able to link the streaming audio API to a useful visualizer, recognize problems with his approach, debug issues in that visualizer, and find a clever solution using graphics fundamentals like masking.
I'm less than impressed with the general consensus that he's somehow negligent for launching a feature that needed a fix, or that users don't want or need feedback about audio connectivity, or that the poster did something much better sometime back in `02.
Great writeup. With LLMs doing an increasing amount of the coding now, it would be great for the browser or development environment to have built-in validations that enforce good performance. The coding agent (or human) would get direct, immediate feedback at development time that there's a performance threshold violation, at development time.
... Why does a "note-taking app" have an "audio volume visualizer"???
Edit: kinda funny how I asked what I thought was a reasonable question and expressed entirely understandable confusion; got an upvote almost right away; then got multiple downvotes after people answered the question — as if it somehow suddenly became obvious why I should have expected such a feature a priori.
Man, I hate what the web has become in 2025. There is absolutely no respect from frontend developers for their users. It's obscene the amount of wasted CPU cycles, energy, battery life, bandwidth, and time we have in aggregate due to horrible frontend development practices.
Here's the part that makes me confused/angry: this is a flat style icon with maybe 4 or 8 colors displayed on a static flat green background. I could have built this 25 years ago with a single GIF with about 6 frames, that was a couple of kilobytes and would be performant on the (relative) potato computers we had then. With CSS you can easily make that GIF a background image and position it correctly in the <button> or whatever. Do it at 2x and scale it for retina sharpness.
But modern "web designers" feel the need to spend how long carefully crafting that CSS animation which adds dozens of lines of code to the codebase and burns a ton of CPU...why? Just because you can, I assume? The same reason the same people use embedded <svg> documents inside the HTML for simple icons like "edit pencil" or "close", wasting bandwidth instead of at least putting them into asset files that can be cached.
Frontend web "advancements" of the last 10-15 years, at least the way they are used, are mostly cancer in my opinion. I will allow for the usefulness of display: flex, and that's about it.
ironic that the benefit of using web tech (platform abstractions) can be totally negated by such a small footgun, which then requires insane knowledge of the browser rendering pipeline to solve
Don't animate height
(granola.ai)456 points by birdculture 19 July 2025 | 267 comments
Comments
I've seen the "This webpage is using alot of resources" popup before but I don't think it would happen in this case.
Because honestly I think this is horrifying. I would rather it switch from grey to red "recording" dot than use even the 6% the author decided was "fixed". In 99% of cases I do not care at all about the "artistic vision" of the UI designer and in the other 1% of cases (say an in-browser game or some useful data-viz) I could choose to allow the tab to go crazy with my resources.
Now the layout engine knows that it doesn't need to recalculate positions of elements outside that wrapper, and it's much faster.
By the way, the same trick was speeding up large <table> rendering back in the day. As long as you know the size of your rows or columns ahead of time, which kinda defeats the purpose of <table>.
https://developer.mozilla.org/en-US/docs/Web/CSS/contain
https://developer.mozilla.org/en-US/docs/Web/CSS/will-change
There are hints you can provide to the browser that may have an impact in scenarios where you are animating layout properties.
Wait, this is supposed to be an improvement? 6% CPU for a lame animation?
The UI of this app literally only has a piece of text, a button and this animated indicator. To render this it needs an entire chromium browser loaded into memory, and still it has performance issues.
I will always prefer software written in native graphics toolkits. I understand the benefits of using electron but the only electron based software I've ever liked was vscode.
Its a very clever solution and props to the engineer, but this being the fix makes me truly despair at where we are as an industry around web UI. That html and css won despite these sorts of counter-intuitive horrors.
UI layers that make me feel good reflect intent. I can take an image and write some code to darken that image (any image) and show that to the end user. It makes sense. However, in html+css I have to introduce a third element, another rectangle, slap it infront, paint it entirely black and set its opacity to something low. Sure, it works the same but it just feels so conceptually ugly.
I fortunately quit animating height quite a long time ago in favor of similar transform techniques, but… wow, still crazy to learn the magnitude of this common operation.
Looking at the animation, I'd wager it's still way too much CPU use for what it is.
There has to be more optimal ways to do this.
It looks like the point of this article is that you should avoid continuous animation for CPU performance reasons. These performance reasons are probably inconsequential for occasional transitions.
For many of us in the target demographic of "people who animate height", the scary title of this article is misleading.
I honestly can't imagine typing this out and patting myself on the back rather than thinking "wtf am I doing? It's 2025, I have a high end laptop, and this is a note taking app. The total resource utilization should be close to zero."
Modern devs are fucking hogs.
I usually develop my apps on a 1300 MHz single-core Intel Atom mini PC from 10 years ago. When something like this goes wrong, the app becomes unusable and I immediately notice it.
But it's vector graphics!, you might say. Yeah, like Flash, which ran fine on Pentium II, with plenty CPU cycles to spare.
Pardon me, and I don't say it lightly, but... WTF?!
Yup. Matches my experience with pretty much every Electron app. Great that the dev tracked it down, but every Electron app is a waste of...electrons
There, I fixed it. I have a custom CSS that kills all animations whenever I'm forced to use a "modern" browser, and it definitely tames the web.
> Less expensive are paint properties. A paint property does trigger layout, but it does repaint a layer, and then re-composites.
It doesn't trigger a layout step?
Damn, is this 6% of the whole CPU?!
The worst modern invention. HTML/CSS is so bloody awful at rendering user interfaces. We should if at least contained it, if not killed it outright. But instead it’s a contagion that has spread far and wide.
How the hell does the optimized version use 6% of CPU? It should render at roughly 5000 frames per second.
What a tragic state of affairs we live in.
> On my M2 MacBook, the renderer process is now using 6% CPU (down from 15%), and the GPU process is now using 6% CPU and less than 1% GPU (down from 25% and 20%).
This still feels way too much compute for a tiny animation updating a couple times a second.
Ouch. All of this for a tiny visualizer animation.
A few week ago I needed to animate height for a banner like message that appeared in the layout (e.g. it was not absolutely positioned) once a user clicked a button. This banner message would cause a layout shift no matter what because its height was being added to the layout and shifting the elements underneath it down. Thus, to mitigate a jumpy layout, making the height animate made the layout shift easier on the eyes.
And before you say "well design it differently" - I didn't design this.
Just. Don't.
NO ONE needs animation to convey information, unless that information is an animation, such as in an educational context, where interactive things demonstrate what is being taught.
I don't need to see your widget spin in 3d while I scroll down the page. I really don't. I don't even want to see that.
Web pages are slow because people make them slow. Stop making them slow.
Might be worth it to buffer the input until animationEnd() event fires. That might reduce the amount of calculations and redrawing that needs to be done.
Or the CSS engine is robust enough to handle continual updates and this won't solve a thing. I'd have to test it.
--
1: http://jankfree.org/
The post is also riddled with all kinds of misunderstandings, as well. For example, the authoritative language used to describe the differences between layout/painting/compositing is just simply untrue generally speaking (though it might be w.r.t. Electron/Chromium). The W3C does not care how you implement your rendering engine, and even bringing up the spec betrays a misunderstanding of how these things work.
In typical fashion, we see yet another grandiose blog post about fixing a "perf issue" for your hipster new startup that is essentially notepad.exe. Who funds this shit?
I'm less than impressed with the general consensus that he's somehow negligent for launching a feature that needed a fix, or that users don't want or need feedback about audio connectivity, or that the poster did something much better sometime back in `02.
From my first try, I immediately had the performance monitor visible because I knew this could be RAM intensive.
I iterated a few times until I settled on SKIA and boy, the performance was night and day.
Edit: kinda funny how I asked what I thought was a reasonable question and expressed entirely understandable confusion; got an upvote almost right away; then got multiple downvotes after people answered the question — as if it somehow suddenly became obvious why I should have expected such a feature a priori.
1. making a note-taking app in 2025: 1st mistake. cuz well solved space with great existing tools/options going back to the 80s/90s
2. as a GUI
3. with animations (in a note taking app?!)
4. in a browser
He could had stopped there.
But modern "web designers" feel the need to spend how long carefully crafting that CSS animation which adds dozens of lines of code to the codebase and burns a ton of CPU...why? Just because you can, I assume? The same reason the same people use embedded <svg> documents inside the HTML for simple icons like "edit pencil" or "close", wasting bandwidth instead of at least putting them into asset files that can be cached.
Frontend web "advancements" of the last 10-15 years, at least the way they are used, are mostly cancer in my opinion. I will allow for the usefulness of display: flex, and that's about it.