One obvious tool that this article doesn't mention is Chrome's performance monitor. Many techniques in the article only have to be applied once you can verify that they are running slow.
The browser's main thread is expensive
41–50 of 156 posts
Re: The browser's main thread is expensive
#42> So what if off-screen posts were left as empty shells that only take up their height, and got filled with real content as they approach the screen? Yeah fuck everyone doing that, hello Reddit, Outlook for Web or Bluesky. It makes searching on such "feed" pages with the browser's search function an utter pain in the ass, made worse by the fact that the platforms' own search functions are outright braindead.
what's your solution to the performance hit that you get when you load up the dom with a zillion things? long, unvirtualized threads will bring every decent computer to its knees.
the sites could implement their own search to make it all work if they wanted to. they just dont. but blaming virtualization is not tit.
Re: The browser's main thread is expensive
#43I want to do a blanket response to people calling this AI slop: the post was written in korean and translated to english. Calling this slop is judgment slop.
Re: The browser's main thread is expensive
#44Superb article.
There was very little new information for me as I have applied some of these techniques myself based on having developed an intuitive understanding on how a rendering "thread" works and blocks, but for a less experienced developer this article should be incredibly enlightening and provide a solid understanding of what's happening.
I employed use of yielding on a hobby project [0] I made about 15 years ago, particularly when it had to do lots of draw operations on a canvas. I also experimented with using worker threads to render pieces of it on a background thread, but at the time there was no way to copy the data efficiently between them and the main thread, one had to send the data as a base64 encoded PNG and the overhead of encoding, decoding and then copying it onto the canvas made it perform far worse than just doing it all on the main thread.
The website also does Gzip decoding of uploaded files in JavaScript and the library I found at the time did all the work synchronously so could lock up the UI thread easily for 10+ seconds. I tweaked it to be able to yield every 200ms or something, the process of which was very educational, particularly due to it convincing me to never omit the curly braces after an if statement, I spent a very long time trying to understand why it wasn't working until eventually I realized a statement I added wasn't in the if statement's block. It's not that I didn't understand how if statements worked, it's that in my mind the lack of curly braces was initially invisible to me.
Re: The browser's main thread is expensive
#45[flagged]
Re: The browser's main thread is expensive
#46Yeah, but if your website with, you know, text and stuff, doesn't do any stupid and unnecessary crap, it doesn't matter where the nonexistent unnecessary yet expensive code doesn't run.
You'd be surprised how expensive it is to render text, although unless your page is very large you won't see it being slow on modern systems.
Re: The browser's main thread is expensive
#47I want to do a blanket response to people calling this AI slop: the post was written in korean and translated to english. Calling this slop is judgment slop.
The basic Firefox "translate this page" on the original is more readable to me.
Re: The browser's main thread is expensive
#48Earlier quoted context omitted.
What signs of slop are people seeing here? Or is it just a knee-jerk reaction to encountering lots of text? I’ve worked in the field for a long time and see a carefully written, correct, calm article. No obvious AÍ tells in wording or sentence construction. It is a bit long - might have been inspired by ciechanow.ski
"and there’s a reason for that" "The code isn’t slow. It just happens to be the code that’s holding the main thread." "dealing with the main thread becomes the important part" "What to remember for now is that holding the main thread for a long time is the same thing as freezing the screen." "One thing not to misread here is" I realize the author may not write native English, but this is not translation slop, it's AI…
Somewhere along the line "machine translation" became conflated with "machine translation + LLM editing"
Re: The browser's main thread is expensive
#49Good article and I wish this was much better known.
The issue is though that it's too focused on interactivity. In reality, 90%++ of slow sites are not slow because of interactivity really, they are slow because they ship enormous react/nextjs bundles and have extremely heavy hydration work to do.
_so many_ sites have bundles >10MB that need to be downloaded, parsed and hydrated.
I've even seen (many) sites which have multiple SPAs stacked inside of them.
If you're on a slow internet connection and/or CPU the page is basically unusable for many tens of seconds and no amount of yielding post bundle hydrate will really solve that.
Re: The browser's main thread is expensive
#50I learned these lessons from many separate places and have always wished to see them in one place. This was an incredibly great article that I very much enjoyed reading and will be sending to anyone who's in need of ideas about speed. Thanks a lot!