Don't animate height
granola.ai456 points by birdculture 6 days ago
456 points by birdculture 6 days ago
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.
Firefox already has a monitor module that AFAIU tracks UI stalls and prompts the user to stop the website if it hangs for a long period [1]. It probably can be further developed to also track resource consumption and show a warning if some threshold is reached.
[1]: https://searchfox.org/mozilla-central/source/browser/modules...
100% of the CPU for 5 seconds seems unreasonably long for a random webpage.
For a news article, absolutely. But I think it needs to be able to handle JavaScript-heavy webapps too.
My suggestion wasn't really about promoting maximum best practices, but just avoiding total runaway excess.
MS word on a 133mhz pentium and 16mb of ram needed less than 5s to start.
Websites don't need that much resources and should be optimized.... if somehow web developers could read, maybe they'd start doing that.
There are full on CAD apps nowadays on the web. Also, this "looking down" on such a huge group of people is pretty questionable behavior.
There were those apps on pentium 133mhz era computers too, even started in faster tha 5 seconds.
For 99% of the people, word 97 was good enough then and is still good enough now to do whatever they need. They can literally still use it today. (yes yes, docx compatibility, i'm just making an example).
Web stuff is one of the few things where the amount of useful data on an eg. weather report site (webmail, news site, bus timetable site,...) hasn't changed, the cpu requirements have gone way way higher for no useful reason (except to serve more ads), and the users can't use the "old versio" of the site anymore. It's literally gigabytes of ram and multiple seconds of 100% cpu usage to service 5kB of article text and a 50kB article photo.
There were full-on CAD packages for 133MHz Pentiums.
Yes, and they had perhaps 1% of the features you'd expect these days. Though of course, they were the important 1%..
This isn’t unsolvable. A CAD app or similar could ask for permission to use extra resources. There’s already one for storage, extending this to CPU and MEMory is not far fetched.
Your browser should allow you to override all CSS on the web. Here's how I disable CSS animations in Firefox:
This is a level too deep. I don’t want to dictate what a website can and can’t do to limit resource usage; I just want to limit resource usage.
Sure, noodling with content blockers has its own advantages, but for this particular case they cut at the wrong abstraction matter.
They should put in something that allows users to electroshock web designers for wasting their battery.
I don't think combined energy output of every power station on Earth would be enough after we have Electron apps for so long. (edit: typo)
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?
I wish. But some sites we are stuck with. EG: bank, HR App, etc.
How about not living in society and instead going into the wild?
Consuming 100% of my cpu for a stupid animation is the opposite of living in a society.
Yes, because we should never ever try to improve the society we live in. Our only options should be to a) run away, and b) shut up and take it.
That's not what I was trying to say. But the fault lies with me for being sarcastic and silly.
> 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.
I'm with you 100%. Although I'd go one step further and say CSS just isn't needed at all, and should be removed from all browsers. Same goes for WebGL (if you want to play a game, download Steam).
This would fix all of your issues and save an unbelievable amount of energy across the planet. Unfortunately people like us are a dying breed!
No css at all is pretty extreme, but I'd be on board with disabling css animations
That's very very sad. Animations can make UX much better when used correctly.
…how? How do they improve the user experience, at all?
Answering because I know the answer, even though I disagree:
There are some situations where having some animation can "attract attention" to parts of the UI, for guidance ("there's some info text here"), feedback ("operation complete"), state changes, timing. All this of course doesn't apply to decorative animations.
With that said: a lot of the situations I mention above are manufactured. They are often because of changes happening away from the mouse, or because the interface is brittle or too slow, and the user doesn't have confidence that something really happened, or because the organization of elements is not functional and things are too far apart that the user might miss something in a totally different part of the screen.
IMO, with enough thinking you can come up with alternative interfaces that don't require animations at all.
Imagine a list of 10 items that gets shuffled so that the order is completely rearranged. With no animation, it would take a lot of additional cognitive load to find where each item went. With animation, your brain would track the general movement of each item much more easily.
Basically, animation provides additional information about object state. Removing that extra information increases cognitive load.
This isn't to say all animations are useful. Many animations are excessive or completely unnecessary, which is probably what has given you a negative view of them.
Absolutely, without question. Do you think that humans, who evolved in a physical word where basically everything happens in an incremental way don't extract valuable information from in-flight state?
Also, as an example just try to use a window manager that just switches instantly to a new desktop, vs a very short animation. I find the former easily disorienting, and it is even more so when you have a more direct gesture controlling the action (e.g. touch or mousepad). Of course there is too much of everything, and too much animation sucks, no question. So is too much fat, but that doesn't make normal amounts any bad.
People are different, I guess. I remove those animations whenever I can. A desktop manager that switches virtual displays in a single frame is exactly what I want.
I disagree. The first thing I do on a new phone is to disable all animations. It makes the phone feel so much faster.
I'm doing something similar. I set them all to 2x the speed. That is much better than disabling them imo.
You can disable CSS in your browser. The fact that you even complain about this tells me that you didn't didable, yet you damned it to be removed. Pretty hypocritical of you.
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>.
As an old-school webguy, fixes like this article make me sad.
The average front-end person these days has so little respect for the DOM and then gets mystified about why the McMaster-Carr website is so good despite being build with ancient practices.
Well, and especially because the “fixed” version is still - if I’ve read correctly - consuming 12% CPU before any user interaction on a page that’s otherwise substantially a plain or possibly RTFish text editor.
How is that considered acceptable? It’s still going to drain the battery faster than is justified, even if at a somewhat reduced rate from the pre-fixed case.
The acceptable range would be something like 0 - 1% when no interactions are taking place.
I’d still deploy the fix in the article as an interim solution - better is after all better - but I wouldn’t stop there.
Front-end web devs need to have more respect for power consumption and battery life (proxies by CPU and GPU usage).
> Front-end web devs need to have more respect for power consumption and battery life
they need to understand and believe that their wishes are not everyone's wishes, and that they alone are the cause of their own problems. Everyone else works hard to give them the creative freedom they demand, but for multiple decades now they have demonstrated over and over how they love shooting themselves in the foot at every opportunity.
> consuming 12% CPU before any user interaction on a page that’s otherwise substantially a plain or possibly RTFish text editor. How is that considered acceptable?
It's not acceptable, unless you are a front-end web developer. If you are a front-end web developer, you don't consider this a problem in any way because the page looks as it is intended to look.
Couldn't they just have used an animated gif or png, the amount of CPU used probably wouldn't even be measurable
You might be surprised at the CPU usage of rendering a GIF. I'm not sure why, but I've previously noticed Slack takes noticeably more CPU when there's an animated emoji on screen.
A few years ago a client that I hadn't spoken to in half a decade called me to thank me. He wanted to update his website to work with tablets, checked before calling me, and realized that his website just simply worked. Being the caveman that I am, I wrote the damn thing using the simplest CSS possible. Simple equals compatibility in this field.
I just went to the McMaster-Carr home page and right-clicked for "View Page Source". There's a LOT of code there.
Looks like its using YUI (a yahoo UI library) that was deprecated in 2011 in favor of YUI 3 (which is now deprecated as well). https://yui.github.io/yui2/docs/yui_2.5.0/docs/index.html
Im seeing a lighthouse mobile performance of 64 with Javascript execution time, unused js, legacy js on modern browsers, etc. as some of the top reasons.
`contain: strict` is much better than `overflow: hidden` for this case, and implies `overflow: hidden`.
https://developer.mozilla.org/en-US/docs/Web/CSS/contain
Yes, looks like this property isn't just a hack, but was designed with exactly the performance considerations laid out in the article in mind. Animating height is only expensive when the element’s height affects layout, which it doesn't have to!
Thank you! This is what I am looking for in HN comments. Layout engine cannot be that stupid per the article. I guess it is not once you give it enough hint.
This likely more effective quite a few years ago, but not particularly important today.
Changing height typically only shifts elements, and browser engines typically wont relayout them due to position changes.
"overflow: clip" is also much more lightweight than "overflow: hidden"
This is the answer. I thought this was fairly common knowledge, height is animated quite often (think dropdowns), no need for the over complications.
Is there a good way to learn techniques like this from first principles other than trying to become an employed frontend dev?
You need to think about what the browser is actually doing when it displays a web page. You need to think about what happens when you type the URL in and what the browser is doing conceptually.
If you have any experience programming 2D graphics with SDL this will help you to understand what is happening as well.
There is an old school talk by Nikolas Zakas on JavaScript Performance from 2009 which while some of it is out of date now due to improvements in Browser engines, the fundamental ideas are still the same.
https://www.youtube.com/watch?v=mHtdZgou0qU
If you skip to the 35 minute mark he speaks about reflow specifically. Generally I still use many of these techniques when writing vanilla JS (which is unfortunately rare these days). There are other talks where he talks about many other performance specific topics.
Obviously none of this is as good as real world experience of dealing with a thorny issue.
> If you have any experience programming 2D graphics with SDL this will help you to understand what is happening as well.
No. No it will not. Nothing in 2D graphics will help you understand things like "simple animation required full layout re-calculation and re-painting of the entire page"
Yes it will. Most of the CSS styling is literally wrappers around draw calls.
Which draw calls result in "changing border width will cause a full page re-flow in some browsers, and bot others"?
Which draw calls are "literally any animation will cause the full re-flow of the document unless you make sure an element is not a part of the document, but then you'll have issues with positioning, weird gaps etc."
Which draw calls teach you that "well, this primitive animation consumes 15% of CPU, but will only consume 6% if you go out of your way to make it 'performant'"?
You are being disingenuous. I can always use some hyper specific example to disprove any statement about what is generally true. That doesn't mean that understanding what is typically happening is useless. Which is essentially what your claim is.
> You are being disingenuous. I can always use some hyper specific example
These are not hyperspecific examples. We're literally discussing under an article which has a primitive animation which was, quote, "using 60% CPU and 25% GPU on [a] M2 MacBook"
How is 2D graphics programming helping there?
The article goes on to describe, correctly, layout properties ("The W3C spec is full of these!"), paint properties ("this tiny "bikeshed" SVG which you can find on lots of W3C spec pages. It costs ~30% CPU!") and composite properties.
These are not specific examples. These are literally footguns upon footguns that literally have no corresponding counterpart anywhere.
> That doesn't mean that understanding what is typically happening is useless. Which is essentially what your claim is.
Yes, knowing 2D graphics programming is 100% useless to understand what's happening with CSS and DOM.
> These are not hyperspecific examples. We're literally discussing under an article which has a primitive animation which was, quote, "using 60% CPU and 25% GPU on [a] M2 MacBook".
No we are not. Someone asked about how one learns some techniques that the OP mentioned (that were simpler than the ones given in the article). I gave some general advice on how one should think about what is happening and some general advice about how to think about performance.
Then you are pretending that none of this is relevant because you are concentrating on the hyper specific stuff in the article (which we are no longer talking about).
I also disagree that this cannot be reasoned about by learning a bit about how graphics works, Cartesian coordinate system and literally turning on the paint flashing tool that is in dev tools. It is literally obvious what is happening when you see it.
> Yes, knowing 2D graphics programming is 100% useless to understand what's happening with CSS and DOM.
In fact it was very helpful to help me to understand what was happening. I literally said to myself "wait a minute, that is kinda like this thing I did in SDL 1.2 in university". You are literally telling me, that something I know to be useful isn't, because you say so. That is unreasonable.