Don't animate height
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>.
> 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?
I would also suggest looking into the following in this case:
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.
> On my M2 MacBook, the renderer process is now using 6% CPU
Looking at the animation, I'd wager it's still way too much CPU use for what it is.
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
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.
Wondering what the performance of a simple animated gif would be, instead of the composite layer transformations.
> 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.
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?
It seems beyond absurd to me, that this tiny animation should be costing as much as 6% of CPU.
There has to be more optimal ways to do this.
The final CPU/GPU usage is still totally unacceptable.
Cool article!
> 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.
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.
> 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.
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.
I think there's a typo?
> 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?
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.
dumb question: would putting the parent div in absolute positioning solve the compositing?
Seems like a great use case for a tiny canvas instead.
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.
I recently created a voice notes app in react-native / expo. And I have a waveform that updates according to the multimeter (audio input)
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.
So, after all the optimization, they're using 6% of the CPU to display what amounts to a tiny animated GIF that 1990s PCs would have no problem with.
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?!
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...
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.
Excellent dive that covers a bunch of stuff, thanks for this. The brevity, tho. Masterful and very appreciated
Is the information conveyed by this animation actually useful?
"What is Granola spending those cycles on? It's an Electron app"
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
> Don't animate
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.
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].
--
> On my M2 MacBook, the renderer process is now using 6% CPU
Damn, is this 6% of the whole CPU?!
You’re still okay with wasting 6% CPU and 1% gpu time on a simple note taking app?
Wouldn’t the real fix be to use an animated gif?
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.
Yeah it really helps knowing CSS when doing frontend dev...
Why are the bars on a little button animated in the first place? I don't get it.
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.
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?
> It's an Electron app
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.
I seem to recall reading that Chrome has height transition optimizations coming.
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.
You can animate height without forcing a relayout, as long as the element is out of the document flow.
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.
... 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.
I love all things perf but stopped reading pretty early once I saw enough foundation mistakes (after which all else is folly anyway, haha):
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
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.
> What is Granola spending those cycles on? It's an Electron app
He could had stopped there.
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
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.
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.