I don't see a CPU usage spike on Safari Technology Preview Release 214.

Nope. I leave javascript turned off like with every other website. No CPU use issues.

Found the arch user ;-)

I have an old system with simple older firefox -- It can collapse the given example without even noticing ... well not perceptible to myself ... I'd call it near instantaneous, also tried repeatedly as well as going though collapsing the rest but was unable to cause a falter. I do though have a deny list of sites that provide / contain scripts that snoop too hard as well as a couple I'm suspected set up as resident in the background where the behaviour was only corrected with quit and restart. Mind that deny list results in a few innocent sites not loading up, but I can live with that.

Not for me - CPU usage remains indistinguishable from idle and any blocking of the main thread is imperceptible. (Firefox 137 on Fedora Gnome 41)

It's not just you, it happened to me a few times today. This is the first time this has happened.

The javascript that hides collapsed layers probably isn't optimized and doesn't scale up to thousands of DOM nodes well.

As ever, there's no need to guess what's happening when one has a Profiler on hand.

It takes approx 13 seconds to finish loading the page with CPU spike and firefox occupies more memory as long as the page remains opened. But then opening/collapsing the thread is not noticeable.

Chrome and Firefox are instant for me in Windows. No CPU spike.

Funny enough just this morning, I inspected the memory usage of several of my Firefox tabs, and even though I thought HN as a quite lightweight website, I was surprised to find out that there was about 200 MB per HN tab allocated!

I use Edge on both mobile and desktop. I haven't noticed any spike when collapsing a thread.

Judging from the other commeters who didn't noticed spikes, I think there might be something related to your hardware and software combo that is causing it.

I can reproduce this consistently in both Edge and Chrome. I've been assuming that it was a change to how Chromium redraws pages that was introduced a few months ago, but I haven't really looked into it. I just started hitting Next instead of collapsing anything.

I just timed it real quick in Edge 134.0.3124.93 and collapsing svara's top level thread hangs the browser and lags my system for 1 minute 36 seconds.

Interesting, I can't reproduce it. I've got Chrome 134.0.6998.166 on macos and with profiling turned on, it's about 55ms for me (3ms of that is spent in scripting).

I don't see it. It's probably an addon issue. Have you tried running the browser without addons?

I know, for instance, that Dark Reader seems to affect my CPU usage when mass updating DOM elements like that.

And I suppose it depends on your CPU, if you're running modern browsers on a fifteen year old laptop you're going to see CPU spikes all over the place.

This reminds me that one time on one Czech Linux portal when someone posted blog about crocodile infested river, there were several characters and you were supposed to decide who is more or less moral and judge their behavior in the story. The whole thread became so massive that it brought portal down and even today when you open it it loads half a minute.

link please? I want to see this

Computers have gotten much faster since 2009, but I wanted to experience the original pain, so I made Firefox translate it offline. It huffed and puffed for a few minutes on my weak corporate VD, and it was strangely satisfying.

I still use an older firefox - the thread loaded in less than 10 seconds - I'd say 7 or 8. Maybe they've sorted loading issues, or changed their JS and APIs source / sets. I have an older computer that would have been newish in 2009, so IMHO nothing to do with old computers.

Collapsing the top comment (by svara) in that thread is essentially instant for me, with Chrome 134.0.6998.166 on macOS.

The Javascript is surprisingly readable (not minimized, not using any framework). It looks like all the comments are peers according to the DOM structure. When it collapses a comment, it loops through all the following DOM siblings until returning to the same indent level (so all the semantic descendants) and hides them one-by-one. I could see why this could be a bit slow even though it isn't for me. I'm not really a frontend person so I don't know why they might have chosen this structure. One could imagine if the DOM structure were set up such that the comment's descendants were DOM descendants, it wouldn't have to do this at all. It could just use a CSS selector that would hide elements (and thus their descendants also) if their direct parent were collapsed.

it is indeed sluggish on my phone the first time i collapse, speeds up after