▲ 460 points
back
268 comments
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.
Seriously. It seems pretty reasonable to allow a web page a total amount of processing that is something like 100% CPU or GPU for 5 seconds. (E.g. can be 25% for 20 seconds.) And beyond that it gets throttled to 3% CPU cumulative max for however long it's been open so far.
And make that the default for popular browsers, so sites are forced to be efficient or else be super super janky and stuttering. And allow a permission for unrestricted processing that things like WebGPU demos or games can ask for.
Your browser should allow you to override all CSS on the web. Here's how I disable CSS animations in Firefox:
They should put in something that allows users to electroshock web designers for wasting their battery.
A bookmarklet that injects custom CSS and selects all/certain items and applies the `contain: content` and `content-visibility: auto;` rules could do to trick.
Additionally, the pseudo `:empty { display: none; }` selector may get you additional mileage.
Probably too late, but uBlock Origin can disable animations (technically fast-forwards to the end, less likely to break the page) for all websites. In the Settings > My Filters tab, add:
!Disable CSS animations globally
*,com##*, ::before, ::after :style(animation-timing-function: step-start !important;transition-timing-function: step-start !important)
!Disable text shadow globally
*,com##*, ::before, ::after :style(text-shadow: none !important)
!Disable image filters globally
*,com##*, ::before, ::after :style(filter: none !important)
!Disable rounded corners globally
*,com##*, ::before, ::after :style(border-radius: 0px !important)Yes, with StopTheMadness https://underpassapp.com/StopTheMadness/
It works on Safari, Chrome, and Firefox, but you must buy it.
ChromeOS has logic that restricts background tabs to 1% CPU use I think.
To take matters in my own hand I wrote "tabdouse", a tiny kill-at-high-cpu script: https://www.bugsink.com/blog/tabdouse/
Quite unreliable and more a joke than anything, of course...
How about just not using that site?
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>.
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.
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?
Wondering what the performance of a simple animated gif would be, instead of the composite layer transformations.
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.
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.
> 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.
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?
Ok, but we can all agree that even 6% constant CPU usage is way too high for a note-taking app, right?
The final CPU/GPU usage is still totally unacceptable.
>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."
Modern devs are fucking hogs.
dumb question: would putting the parent div in absolute positioning solve the compositing?
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.
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?!
"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
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.
> 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.
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?
> On my M2 MacBook, the renderer process is now using 6% CPU
Damn, is this 6% of the whole CPU?!
> 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'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.
Yeah it really helps knowing CSS when doing frontend dev...
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.
You’re still okay with wasting 6% CPU and 1% gpu time on a simple note taking app?
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.
> 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.
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
Is the information conveyed by this animation actually useful?
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].
--
Previous discussions / submissions: https://hn.algolia.com/?query=Don%27t%20animate%20height