Don't animate height

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:

https://news.ycombinator.com/item?id=33223080

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.

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.

How about just not using that site?

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.

`contain: strict` is much better than `overflow: hidden` for this case, and implies `overflow: hidden`.

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.

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.

Is there a good way to learn techniques like this from first principles other than trying to become an employed frontend dev?

CSS contain has made so many performance "truths" obsolete, but so few developers realize it. I've seen massive efforts to do things like port text editors to WebGL where rasterizing text is a huge pain where putting `contain: content` on the individual elements in the DOM version would have delivered most of the perf improvements.

Browser rendering engines are now sophisticated GPU-accelerated compositors. Absolute positioning with contain: strict removes basically all CSS layout from the perf equation, and you don't have to write your own compositor or line-layout! `* {contain: content}` and flex/grid gets you the good parts of HTML and very good performance.

I was just starting a comment on this but you beat me to it! I believe

  contain: strict;

It’s literally the sliding doors technique from, uh, two decades ago https://alistapart.com/article/slidingdoors/

I had a similar problem trying to animate a book flipping pages. At the half way point I had to update the text to show the backside and update the back pages.

However no matter what I did, I could not get the update to sync correctly with the page being exactly half way. There's probably a solution but I just gave up

Videos game rarely do any complex dynamic layout. That is where all the time is going

Well, raw graphical content is the easy part.

A live layout tree that has to be repainted and composited yet intersect with arbitrary layers like an accessibility tree and what would naively be N:N style calculations is completely different architecture.

Consider examples where people toy with the concept of replacing the DOM with a canvas but basic things like text selection don't even work anymore.

Keep in mind that the percentage in Activity Monitor is 100 % per core, so a 10 core CPU can go up to 1000 % usage. So 60 % means 60 % of a single core not of the whole CPU.

If the bars are not related to actual data and are purely just pre-canned animation, the gif would just come with additional file size for a one time cached type of download. If the bars do need to be animated to real-time data coming in, then the gif would not be the right fit for that need.

Personally, I'd be annoyed by both the resource-consuming animations and the blurry GIFs/canvas. Infisical does use the latter (canvas) for icons in their UI, and I somewhat hate it. I'd rather look at crisp, but static icons.

Or if you need to actually control it, an SVG or <canvas> based animation

GIFs historically were pretty unoptimized from a display perspective (as anyone with a moderately-active Tumblr dashboard could tell you), so I wouldn't be surprised if it was worse.

It's really simple. Don't animate layout, especially if your DOM is huge.

If your element floats absolutely positioned outside the layout flow, animating height would not be a problem.

And if the browser facilities for animating height/max-height, especially to/from auto, get better, it surely will become more common.

Right now, I wouldn't call it common. It's a common requirement, but only until you start to consider layout.

Fwiw, animating margin and padding is possible and has the capability to cause the same amount of jank as animating height.

The heart of the issue isn't that animating height is expensive, it's the downstream effect of that animation repeatedly changing the page's layout and forcing redraws.

But it wasn't expensive twenty years ago. Twenty years ago people actually knew how to efficiently use their limited computational resources.

I created a little CSS-pulsing 'live' button and give it a fixed number of cycles of pulsing to cap worst-case resource consumption. But it took me a while to work out that that was the right thing to do!