Good 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.
Ignoring for a moment that most websites don't need any interactivity: Even for those that need it, for almost any of them something JQuery-like is more than enough. You really, really, really don't need the latest super big framework.
The jQuery spaghetti of the past seems worse than the React spaghetti of today. Too many unpredictable side effects. Changing one thing breaks something else. On business-scale timeframes, you can't clean it up.
React enjoyed its spot in the limelight. Then, unskilled people wrote bad React and the framework, not rank-and-file developers, took the credibility hit. It is more difficult, I suppose, to make a user-perceived slow webpage in jQuery.
I dispute this. I don't have any statistics either, but my subjective experience is that most websites are not like newspapers or blogs. Even shopping websites have pretty heavy interactivity these days.
Also, most boring pure-information-presentation problems are mostly solved by ancient technologies like wordpress. If you're working in web development in 2026, you probably aren't making static websites or blogs. You're doing something novel that probably has much higher interactivity demands.
If you can tolerate the (fairly minor) SEO consequences, just render on the client exclusively and fetch data via http calls. I've made small but quite interactive websites with entirely static Svelte + some router (routify/sveltekit/etc.) SPA that just uses http calls for whatever the server needs to be involved in. It's not the right choice for everything, but for some things it works excellently. With a relatively lightweight frontend like Svelte, as well as splitting the SPA into multiple bundles (so it's in some ways not an SPA anymore) makes it perfectly usably snappy even over 200+ms latency, and very fast over a normal connection.
I expect soon each website will have its own browser, compiled as WASM which will be launched in order to render the JavaScript and HTML on the website.
It comes down the web browser being used for two different use cases and two camps arguing past one another.
Documents vs Programs
The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity. You are rightfully pointing out that VanillaJS is insufficient to build software in the browser.
Where I imagine you lose some people is that comboboxes can be done natively with the datalist attribute.
> The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity.
Where does that html come from, then? Do you honestly believe all pages could be static html+css served from some bucket? Or do they need to be rendered by a programm running on a server? Because once you start talking about servers generating pages then all this talk about JavaScript frameworks boils down to arguing where the complexity should be in place A or B.
Yes? Users often prefer a nice GUI but CMSs are effectively what you describe and run the majority of content oriented sites. Static site generators are just the dev-centric version of that. The more common situation is that you're generating pages on the server and shipping a massive JS bundle just to display what could have been rendered once.
But even given your position you see no difference between shipping the user a binary and shipping source code plus a compiler in terms of the user's experience? Surely the existence of server side react points to the server doing the initial lift being an improvement.
> Yes? Users often prefer a nice GUI but CMSs are effectively what you describe and run the majority of content oriented sites.
I don't think you understood my question. I stressed the fact that complaining about the complexity of a page implemented with a JavaScript framework is a red herring, because said complexity doesn't go away by moving it to a server.
And the old "dynamic HTML" approach is not easier to maintain and developm. By far.
In the meantime, what goes away is performance and perceived performance. Your dynamic HTML pages need to travel all around the world until clients see an update, and a page reload is far heavier and time consuming than doing a fetch to get data.
Try to ask yourself this simple question: why do software engineers bother with JavaScript frameworks? Do you think everyone has absolutely no idea about what they are doing?
> 99% of the time those sites could be plain HTML and CSS
Some of that css and html doesn't run reliably and consistently on all browsers. A visit to sites such as canIuse helps build up an idea of the extent of the problem.
Also, you seem to ignore the fact that JavaScript frameworks use said html and CSS extensively, and provide the necessary abstractions to bridge the unreliability gap in addition to introducing features that html and css do not support.
What I really find funny about this issue is the fact that this type of claim implies that virtually all software engineers who for some reason aren't html+css purists are utterly incompetent and completely unable to assess any technical tradeoffs. Imagine yourself walking around with the belief that an entire field is manned by people who don't have a clue about what they are doing.
The article acknowledges this in the very first paragraph:
> For most of us it’s things like reducing network requests, shrinking the bundle, or making good use of the cache.
These are likely going to be your first port of call for performance issues at your day job, but fixes like removing dependencies or making fewer network calls are pretty straightforward. I think the author chose to do a deep dive on the topic on freeing up the main thread because there's such a wide variety of approaches and many of them may not be obvious.
I'm not sure the author realises _what_ a massive impact bundle size has on the main thread though, especially hydration. The majority of apps I've optimised over the years have the (often vast) majority of main thread time spent on the bundle parse/hydration (plus obviously network).
Also, removing dependencies is not easy. I've seen many corporate that have a huge UI lib for example that everyone should use for brand consistency. But it's many MBs of JS, because it has to cover every possible use case.
This doesn't even get into 3rd party vendors who _also_ ship react et al and have other bundles.
I'm not saying the article is wrong, but if you want to free main thread time especially at the most critical point (when the user has initially loaded the page) you _probably_ will find that most of the opp is in bundle size and hydration improvements.
I would think, or hope, a UI library like that could benefit from webpack and tree shaking such that only the needed components end up in the final bundle.
All good points. Perhaps rather than saying the fixes are straightforward, I should have said it's a straightforward concept to understand. If your app takes forever to load because of a huge bundle, you need to figure out how to make the bundle smaller, somehow. (How exactly to do that is where it gets complicated, like you say.)
NoScript is a remedy for this. When a site is broken I whitelist a few domains likely to be necessary. After a few attempts I bounce. If I see a dozen plus domains I don't even bother. This cuts down on the volume of garbage sites I waste time on and shields me from novel trackers not on any block list.
The web is much faster when useless JS is taken away.
I challenge you to browse the web one week on this laptop part of the current top 10 Amazon best sellers on a gigabit fiber connection and tell me if you still think that this is the problem: https://www.amazon.com/HP-Everyday-Processor-Microsoft-Porta...
Please don't brush off parent's "slow connection". Many people are stuck with that.
A prime example: cookie dialogs. On a slow connection, page loads, large parts are rendered, and you start reading. After that, some script starts to present a cookie dialog, and everything freezes. Page doesn't scroll anymore, buttons don't work, sometimes a previously-readable page is darkened or otherwise obscured so you can't keep reading while this goes on.
Then a whole bunch of stuff is downloading, which (again: "slow connection") takes forever. Like 20s+. Halfway through you see "accept / reject / settings", but none of those buttons respond (except the dark pattern where "accept" often works faster or smoother than either "reject" or "settings". Aaargh!). When things respond again, consider yourself lucky when page re-renders as before.
Which also runs afoul of 1 of my pet peeves with user interfaces: DO NOT PRESENT A UI ELEMENT UNTIL CODE TO PROCESS ITS USE, IS PRESENT IN MEMORY & READY. Really simple right? Yet I see examples ignoring this oooften.
A 'slow' CPU, low RAM/swapping etc just makes this worse. Web developers tend to have fast machines & connectivity so they may not even be aware of this. Or think it's a non-issue even though it affects many users - existing or potential.
It is a problem and plays a role, then the rest of the SPA interactions are as bad. Amplified by 100+ third party scripts.
Stop building SPA, go back to HTML. Re-assess every third party. For extra performance and scaling, implement cache. Relax and see web experience healing.
There's definitely trade-offs. I actually prefer a proper SPA to pure HTML when on a slow connection and interacting with a site a lot.
Especially when trying to buy something. I much prefer to have a longer initial load and then have everything just work instead of waiting as I navigate between pages, the multi stage checkout, confirmation etc.
But yeah, if I'm just trying read a single article on a blog, preloading everything is pointless. A hybrid site with the initial page being server side rendered + progressive enhancement afterwards is theoretically optimal in my opinion.
You typically still have to wait for API calls between interactions, but error handling and number of requests (linked to experience on slow connection) tend to be worse.
If that's a connection-less interaction or something small that stays on the same page, sure it makes sense to keep it in the browser. You don't need to build your whole site as a bloated SPA just for few limited use-cases.
These people definitely have an overly rosy view of the past. The sites that are dog slow shit ux now still would be with server rendered html and jquery spaghetti, just like they were in the past.
Ever submit some giant form to get some random error and then lose the entire state of it? Used to be extremely common, even though it shouldn’t have been.
Losing the entire state happens on SPA. Plus a random error not providing any feedback is a typical SPA experience. You can poorly execute on any technology. It's just much easier to do things wrong using this-year-trendy-SPA-framework.
Use the appropriate technology, everything doesn't have to be a SPA.
And yet it used to be much more common. SPA or not doesn't change how your team executes, what kind of management you're working under, or any other externality that makes you end up with a shit website.
In London in many apartment blocks one can only get wired internet via an old copper cable with speeds like 80mbit/s download in theory but in practice it can be below 30 with ping in 50ms range and much slower upload. And 5g does not help either as the signal can be very weak.
Okay so that's no excuse for whoever is providing your internet, coax can deliver 800+ Mbps no problem. And if you are actually saying you only get DSL through a phone line in London then holy shit I would be busting down the door of my landlord. They never in the last half a century got wired for cable?!
A phone line from before WWII works fine to make a call but absolutely sucks for DSL.
And in London many buildings are declared as historic making it hard to get a permit for any work. The best chance is to wait until old pipes bursts and digging has to be done in any case to put fiber along the pipes.
It's not that, it's the building owners (freeholders) refusing permission, or not replying. It's a massive issue.
You'll notice buildings in central London that are listed _but_ have housing association ownership nearly all have fibre to each apartment, as they did portfolio wide deals with hyperoptic etc.
And pipes don't help. Openreach (who owns the copper network) are not allowed in 99% of cases to "fix" copper with fibre under the agreements they have with building owners, they can only make like for like repairs.
The worst affected apartment buildings are 90s and pre 2015ish. Everything after that got fibre installed at build time.
Btw it is worth checking if you have an altnet like hyperoptic, community fibre or g network available. The majority do and if you are just checking for openreach or VM broadband it won't show up.
I was using a laptop with windows 10 and 4GB of ram and an anemic CPU a few times a month two years ago. Even with a fast network, a laptop with no ram is gonna be slow to browse, and bloated pages are gonna be slower.
It will certainly help to download the bloat faster, but you've still got to do all the hydration as OP put it.
Based on my experiences with windows 11, that laptop seems like it will be quite a bit worse than the one I was using, even though mine probably has a much worse cpu.
my point is that as programmers we have to take into account that the average human today has a computer that likely struggles to open Win11 notepad. I don't buy random laptops from amazon, but an astonishingly high amount of people do and we have to work with that
Try it yourself on a gigabit internet. Put CPU throttling in devtools to 10x slowdown (assuming you have a fast computer) and see how fast it is even with super fast internet.
This isn't new at all, just one of the first things I found by googling "webgl demo."
WebGPU of course goes even further.
I think the real gap is just that people by-and-large aren't building real games on top of Safari. It's more lucrative to use the app store with its low-friction payment system.
I made a project a while back to port Minecraft's desktop version to the web and it runs decently-ish on a good computer with WebGPU (but takes a really long time to load)
This was functionally enabled by default by Minecraft being java, including the part where it was popularized by a java applet of a very early version.
There are business-level issues with web based AAA games, as I was alluding to before. Apple has a two-click payment system. If you failed a Candy Crush level and you needed to get up from the couch and get your credit card out of your wallet to buy more turns, no one would ever do it.
Since at least Windows 3.1 we all know that cooperative multitasking is a bad idea. But we see a lot of developers use it, even Rust developers who should know better.
> I can't think of a better way to make simple things billions of times slower than they should be.
How's it going to do that? What's so bad about it? Especially in the multi-core era which lets multiple programs run at the same time the way that multiple pages can run javascript at the same time. The lack of preemption is only within a single page/program.
During periods of time where no single chunk of code runs for more than a millisecond, cooperative multitasking should have the exact same performance as preemptive multitasking. And even when single chunks of code do run for that long, if that code wasn't properly isolated then preemption doesn't save you from lag.
So the difference only shows up when you have chunks of code that keep running way too long, that are also inside of properly isolated threads/callbacks, and on web those threads/callbacks are not inside web workers. Is that a common situation?
> afiori: JavaScript's execution model uses cooperative concurrency to avoid a tons of data races, preemptive non-parallel concurrency would make all web development incredibly harder
JavaScript's execution model uses cooperative concurrency to avoid a tons of data races, preemptive non-parallel concurrency would make all web development incredibly harder
Yes, I was talking from a performance/UX standpoint.
Of course, doing everything in one thread most of the time makes everything easier, because you're using the thread as the lock, so to speak. But using locks is bad for performance and latency and thus UX.
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.
I agree with most of the article, but would clarify the following:
> For the screen to look smooth, frames have to be drawn at the display’s refresh rate. On the most common 60Hz display, that means 60 frames per second, or about 16.6 milliseconds per frame.
It isn't absolutely necessary to match the display refresh rate. With a 144Hz monitor, 72FPS is going to look smooth for the vast majority of the people, and even 48FPS will look smooth for most people. I agree that higher FPS is better, but there are diminishing returns.
It's a good nitpick. A hypothetical 1000Hz display will still look smooth to the human eye at 60/120Hz. A 1Hz display will never look smooth.
But it's more about honoring the user's preference. I personally would rather 60Hz, then 120Hz heating up my room unnecessarily. If someone has a display set to 1000Hz for whatever reason, then you should try your best to honor that.
A user's hardware represents the worst case scenario they want to be able to handle, not their preferred nominal settings. Most people aren't changing their screen refresh rate when they switch between playing a game and reading wikipedia.
Below a certain threshold things are certainly going to look janky. But you’re right you don’t have to match the screens native refresh rate. More important is that you have a consistent frame rate. If you can’t hit 120hz, it’s better to target 60hz, rather than 120 a miss your frame budget. 30fps will also look better than 60 but regularly dropping frames.
I generally agree, though "consistent" can by varying levels of strict depending on the tradeoff you want.
But importantly, if your screen is variable refresh rate or high rate enough compared to your typical performance, that greatly reduces the inconsistency. Go ahead and vary between 55 and 70 if the screen is at 165. Definitely don't drop to 30 and I don't think you want to drop to 41.25 either.
Great piece, OP. We work in WASM and are considering web workers to help with rendering documents off the main thread in that context. I was surprised to read that ArrayBuffer is moved by reference only! Might be an option. Thanks for putting this together.
haven't done this for documents, but for canvas rendering transferControlToOffscreen() worked better than moving ArrayBuffers. It hands the canvas to a worker that draws directly, no pixles over postMessage at all.
Top article, kudos! applied some of these techniques previously, and they do matter a lot. thing is, when you learn/teach JS there is usually limited time left to talk these topics, and they are essential more than it seems.
the whole point of cooperative multitasking is to yield now and then (back to the runner), so that it can process the drawing. Besides, at 60fps there's so much that can be computed once every N frames, and the eye does not see it, the animation flows.
It becomes even more interesting when webgpu is involved, but the CSS animator is indeed very fast.
note: some recent work of mine (newskool digital flyer sites) -> bsf.hmsu.org // nouveauxhivers.dub4powder.xyz
For responsiveness that’s what you want, context switches add quite a lot of jitter and perceived slowness’s, making your app feel slow despite running at 120 fps.
This article concludes with the following statement:
> So much of development is trade-offs, and you have to choose according to the situation, which ultimately comes down to the developer’s experience and judgment.
It’s a great article, but I think it is a bit behind the ball in framing scheduling problems as a matter of “experience and judgment”. The problem of allocating work to a scarce resource is one of the oldest and most well-studied in all of computer science. It would make sense to go consult a textbook on the matter before trying to reinvent the wheel.
Well yes. But most of those studies assume/assert control over the environment. In this case you are running in the browser and you have to deal with the primitives it gives you. Both in compute management (threads/workers), communication (RPC, messages, shared memory, sockets), as scheduling (like having yield or not.
I’m not sure whether inventing a setup like green threads in JavaScript/workers would even be possible.
That is not to say that we should just forget about those learnings though.
This! Since it became easier for people to post their thoughts on a problem vs. research and learn from past work, we're now in the era where its harder to find the seminal and really-well-explained material for having to wade through years and years of people's rediscovery blogs.
(Don't get me wrong; I too think the article is great; just wish all the folks who went to JS bootcamp and are amazed by this would have cracked any CS or OS text book written since the late 60's and browsed a few chapters.)
The discussion of "FLIP (First, Last, Invert, Play)" would be improved by mentioning the View Transitions API, which is basically there to automate this technique.
I remember seeing some JS cryptography library a long time (maybe 10 years?) ago that provided an async hashing function for exactly this reason: to split up what would normally be a simple synchronous computation and yield more often to the main thread.
Can't recall the name, but I remember thinking that was very clever once I understood why it was doing that, and am glad to see the concept explained directly here.
Here is a problem that I had thought about in my last frontend project: the project needed to parse a user-provided string to provide syntax highlighting. The implementation was to parse the string immediately after a user keystroke so the user always sees correct colors. But I had this nagging thought that if I had designed the grammar wrong some parses might take more than linear time and would hold the main thread during the parse. But I didn’t really want to first render a black string, parse on a service worker and then rerender with color. The effect must have seemed disorienting.
Anyways I stopped the project for unrelated reasons and this thought kept nagging me in the back of my mind. The time I work on the project I’ll be sure to try some techniques in the article.
You'd use an incremental parser, they're specifically designed to be efficient for small edits. The big name is `tree-sitter`, but its output is compiled so on the web it requires some wasm shenanigans. For webpages, I'm a fan of `lezer`: https://lezer.codemirror.net/docs/guide/
Brilliant, I had no idea about this stuff. Thanks for writing it up.
On the price ticket example, on my device (Samsung A15, mediocre phone from 2024) I get 11 fps with the slow example and 30 fps with the fast one. (15 if I scroll!)
Is that a case of the back pressure you mentioned?
All the other (fast) examples are 60 fps though :)
One thing that I found quite interesting to see is how the behaviour of the "4.000 particles" demo changes between the 5ms rendering and the "everything now" rendering.
If you are currently trying to build a web-based clone of something approximating ChatGPT, pretty much everything in this article is absolutely mandatory.
The streaming response UI/UX is a total nightmare to make work smoothly. You have to come up with clever heuristics around where to chop up the stream of changes and how to batch the work relative to frame updates to make it not look like confetti during a streaming response.
I really don’t understand why the LLM web chat clients have all converged on this UI where one character appears at a time. It is kind of fun the first time (like you are watching some Harry Potter special effects where an enchanted book writes itself). But really they could send sentence or paragraph long chunks of text, it would be fine.
Seems like an artifact of the time when tokens-per-second were low enough that people needed to be informed that the machine was actually doing something.
I 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!
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 chat example here doesn't really seem to work for me—I get 32 FPS consistently no matter what the chat settings are. Maybe a Chrome thing? Or an M3 thing?
I 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.
AI;DR – too bad as the content seems to be worthwhile, but then why not take the trouble to write it up yourself. Have it proofread/edited/spruced up all you want afterward, but don't have it do all (or most of) the writing.
> 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.
Using a lighter weight DOM can help. There's always a point where it starts to bog down, but many pages are just unnecessarily heavy because they're relying on so many nested widgets and whatnot.
> what's your solution to the performance hit that you get when you load up the dom with a zillion things?
Browsers can easily render and scroll through entire wads of content.
The problem is, when the "line" comprising an email in the email list of Outlook Web is in a maze of (literally, just looked it up) about 30 divs deep, performance inevitably goes down the drain.
Computers in the 00s could handle inboxes with thousands of emails just fine and scroll through them. Outlook struggles keeping more than 30 in active memory. That's gotta be a joke.
By the way: the solution is rendering tabular stuff in, well, tables instead of armies of divs that try to be tables. That case has been optimized to death because that is how websites and applications used to be built.
The solution is to improve the browser to remove the performance hit. Modern computers are extremely powerful so there is no good reason why they would not be able to handle a zillion things in the DOM.
The browser can easily handle millions of calculations and then render a million DOM elements so quickly that you won’t even notice it. The problem is when you try and do this hundreds of times very second.
The irony is that obsessing over smoothness and frames per second is what causes this in the first place.
Yeah, 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.
and if you have no website at all, it takes zero seconds to load.
But for people who are developing websites that are more than just text, this is an excellently written article and great advice.
It's funny, for mobile app dev it feels like the community are a lot of focused on staying off the main thread, this is the first time I've come across one for webdev.
Well yeah but if you do actually need things like images, animations, high frequency updates, etc, this is actually a pretty good overview of how to approach it. Also learned that react uses posting to a MessageChannel to yield!
GP is right that just like with garbage where "reduce, reuse, recycle" is the mantra, the first question for optimizing something should be if you need to do the calculation at all.
This is true as well, yeah, but it came off as dismissive of everything too. Personally I prefer information dense interfaces with minimal chrome, but there really is a certain joy when you get to use a well designed and optimized fancy reactive, immersive interface
I'm more surprised how cheap it is in browsers because I know it's not that easy - they are really really good at it. Pure text rendering is therefore rarely an issue.
Amazing how you are being so down voted, most webpages do utter crap that no one would want the webpages to be doing other then advertisers. Really most things should be text and if we lived in a more cooperative world everything would be easy to parse and manipulate text with some video and images and perhaps various well defined interface types for different services that can be implemented in various ways as to the users liking.
My point is that many websites are using way too much technology for what they need to do, with correspondingly long load times and choppy runtime behavior.
Correct. But if the page is, at least in part, an art piece rather than an information dump, or needs to do interactive rendering for its purpose (an editor like the markdown example, live updating status displays, games and other interactive toys, etc), then the tech is necessary and this article is useful.
Again, correct. But “don't do this if you don't really need to do this” is rather pointless to say, hence is being downvoted, because people already being that sensible don't need to hear it, and those who are not are unlikely to listen. The comment is just noise, as unnecessary as the unnecessary animation and other gumf that it is railing against.
A handful of comments on an otherwise fairly reasonable article.
> When we run into jank like this as developers, the usual reaction is to wonder “is my code slow?” and start picking apart algorithms or looking for wasted computation. In most cases, though, the speed of the code is not the problem. The code isn’t slow. It just happens to be the code that’s holding the main thread.
Eh, most of the time it is slow, because you chose to use React. React used naively scales very badly. You have to jump through lots of sometimes-fiery hoops to make React… not much slower than some of the alternatives. Memoisation (possibly now via React Compiler) and things like that.
> [Diagram with rAF, Style, Layout and Paint attributed to the main thread]
Not sure about other browsers. Firefox has generally been the leader in these areas.
> [steering cost demo]
The demo is deeply unsatisfying because the simulations are quite different in a very problematic way: in “all at once” mode, it loses most mouse movements, which radically affects the simulation which is attuned to movement events rather than simulating physics based on a constant tick rate. Without examining it closely, my guess is it’s using pointer events and the browser is coalescing the events because of the blockage and it’s only taking the final state rather than going through all of getCoalescedEvents(). In a simulation like that, if you can’t run it at full speed, you have to decide what to do, and you should do it deliberately, because it may be disastrously wrong. Should you fall over, simplify the simulation by dropping some of the calculations, reduce the tick rate, something else?
> The demo below is a markdown editor with a long CHANGELOG open. Building the preview means parsing the entire document (about 2,000 lines) and rebuilding its DOM from scratch, which is far too expensive to run on every keystroke.
No it doesn’t. This is a clear example of your code being slow, because you’re doing the wrong thing. You want an incremental parser of some kind. Markdown is tolerably well-suited to this kind of thing because for most edits you can just render the current paragraph.
The suggestion is bad. “Debounce 300ms” behaviour is obviously worse for small documents.
> DOM writes can be batched as well. Appending a hundred nodes in one operation instead of one at a time, or toggling a single class instead of changing style properties individually, turns many changes into one and helps performance. The old technique of assembling an HTML string and assigning it to innerHTML in one shot has the same essence. You gather the writes so the rendering pipeline’s fixed cost is paid once.
This is simplified far beyond accuracy. parent.append(one_hundred_nodes) and one_hundred_nodes.forEach(node => parent.appendChild(node)) are unlikely to perform particularly differently. Changing style properties individually isn’t that* much worse than toggling a single class (it amounts to rewriting the style attribute a bunch of times, and the CSS parser and serialiser aren’t particularly slow). Building an HTML string and assigning it to innerHTML is better than constructing children manually in some cases, worse in others. The real thing that matters is avoiding triggering layout unnecessarily by things like accessing clientWidth between changes.
> Deferring
The lazy rendering trick used here is very problematic because you still need to know how tall each item is. Plenty has been written about hazards of infinite scrolling, that’s what’s being dealt with here. Now if you can have each item be a fixed height, then progressive rendering has far fewer side-effects. I would also say that switching from Notifications back to Feed and having it take an extra few hundred milliseconds is really not that bad. And that I’m not convinced the approach taken was right anyway, you could often just leave the feed rendered and avoid affecting the gross layout.
—⁂—
On the presentation of the site itself: this makes no sense:
So this is AI slop written? Why would anyone believe I'd want to read AI spam?
Also, the issue I see is who controls browsers as much more profound. We need to find a solution here, as the browser is too important to allow private companies to keep mankind hostage.
Edit: Wow, and the praise-accounts. Is that new on hackernews?
I started reading and it immediately sounded like AI, sent it to pangram and it agreed. The amount of posts praising it like it's fuckin oxygen or something ... dead fuckin internet
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 writing slop.
I think you're overindexing here. There are no obvious traces of AI in those full paragraphs (and I read thousands of lines of AI generated text daily). These are not the usual tells, just decent writing.
It reads pretty much like every well-written technical article used to, ten years ago; and scores a 0% likelihood of being AI generated in Quillbot.
It would be better to say that the Browser's Main Thread has been made expensive to run, because browsers have had a bunch of crap piled on them in terms of functionality that is expensive to run.
Actor Model, dedicated or shared application worker. Full support for multi-window apps. Resolved since 2019. 26000 commits in, and counting. You are welcome!
This mistake gets repeated over and over again, in every single GUI framework of any kind. I don't understand why does it have to be that way.
Just use multi-threading. Run each library in a separate thread. Use actors approach to pass data between libraries, application and finally to submit data to update GUI.
Using single thread for everything and expecting that developer will create separate threads for heavy work is obvious approach, but it never worked. Developer doesn't care. And user gets inferior experience.
Good 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.
99% of the time those sites could be plain HTML and CSS, but apparently new generations don't even know how to do that, out of programming bootcamps.
>99% of the time those sites could be plain HTML and CSS, but apparently new generations don't even know how to do that, out of programming bootcamps.
That is because the latest framework always fixes everything that wasn't broken before.
There is no good technical solution for rendering on the server and upgrading to an interactive experience on the client.
Ignoring for a moment that most websites don't need any interactivity: Even for those that need it, for almost any of them something JQuery-like is more than enough. You really, really, really don't need the latest super big framework.
The jQuery spaghetti of the past seems worse than the React spaghetti of today. Too many unpredictable side effects. Changing one thing breaks something else. On business-scale timeframes, you can't clean it up.
React enjoyed its spot in the limelight. Then, unskilled people wrote bad React and the framework, not rank-and-file developers, took the credibility hit. It is more difficult, I suppose, to make a user-perceived slow webpage in jQuery.
> most websites don't need any interactivity
I dispute this. I don't have any statistics either, but my subjective experience is that most websites are not like newspapers or blogs. Even shopping websites have pretty heavy interactivity these days.
Also, most boring pure-information-presentation problems are mostly solved by ancient technologies like wordpress. If you're working in web development in 2026, you probably aren't making static websites or blogs. You're doing something novel that probably has much higher interactivity demands.
There is hardly anything novel in Web other than catching up to Flash or native apps.
If you can tolerate the (fairly minor) SEO consequences, just render on the client exclusively and fetch data via http calls. I've made small but quite interactive websites with entirely static Svelte + some router (routify/sveltekit/etc.) SPA that just uses http calls for whatever the server needs to be involved in. It's not the right choice for everything, but for some things it works excellently. With a relatively lightweight frontend like Svelte, as well as splitting the SPA into multiple bundles (so it's in some ways not an SPA anymore) makes it perfectly usably snappy even over 200+ms latency, and very fast over a normal connection.
Most websites don't need an interactive experience on the client, for what is static content.
I expect soon each website will have its own browser, compiled as WASM which will be launched in order to render the JavaScript and HTML on the website.
This is actually plausible as a way to prevent adblock.
Basically Flash 2.0.
Bad take.
HTML is abysmally lacking for any interactive (which is what this article is about).
Decades later, even something as common as a combobox is unsupported.
EDIT: Downvotes but no argument.
It comes down the web browser being used for two different use cases and two camps arguing past one another.
Documents vs Programs
The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity. You are rightfully pointing out that VanillaJS is insufficient to build software in the browser.
Where I imagine you lose some people is that comboboxes can be done natively with the datalist attribute.
> The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity.
Where does that html come from, then? Do you honestly believe all pages could be static html+css served from some bucket? Or do they need to be rendered by a programm running on a server? Because once you start talking about servers generating pages then all this talk about JavaScript frameworks boils down to arguing where the complexity should be in place A or B.
It comes from a server designed at CERN.
Yes? Users often prefer a nice GUI but CMSs are effectively what you describe and run the majority of content oriented sites. Static site generators are just the dev-centric version of that. The more common situation is that you're generating pages on the server and shipping a massive JS bundle just to display what could have been rendered once.
But even given your position you see no difference between shipping the user a binary and shipping source code plus a compiler in terms of the user's experience? Surely the existence of server side react points to the server doing the initial lift being an improvement.
> Yes? Users often prefer a nice GUI but CMSs are effectively what you describe and run the majority of content oriented sites.
I don't think you understood my question. I stressed the fact that complaining about the complexity of a page implemented with a JavaScript framework is a red herring, because said complexity doesn't go away by moving it to a server.
And the old "dynamic HTML" approach is not easier to maintain and developm. By far.
In the meantime, what goes away is performance and perceived performance. Your dynamic HTML pages need to travel all around the world until clients see an update, and a page reload is far heavier and time consuming than doing a fetch to get data.
Try to ask yourself this simple question: why do software engineers bother with JavaScript frameworks? Do you think everyone has absolutely no idea about what they are doing?
Hence CSS.
> 99% of the time those sites could be plain HTML and CSS
Some of that css and html doesn't run reliably and consistently on all browsers. A visit to sites such as canIuse helps build up an idea of the extent of the problem.
Also, you seem to ignore the fact that JavaScript frameworks use said html and CSS extensively, and provide the necessary abstractions to bridge the unreliability gap in addition to introducing features that html and css do not support.
What I really find funny about this issue is the fact that this type of claim implies that virtually all software engineers who for some reason aren't html+css purists are utterly incompetent and completely unable to assess any technical tradeoffs. Imagine yourself walking around with the belief that an entire field is manned by people who don't have a clue about what they are doing.
The article acknowledges this in the very first paragraph:
> For most of us it’s things like reducing network requests, shrinking the bundle, or making good use of the cache.
These are likely going to be your first port of call for performance issues at your day job, but fixes like removing dependencies or making fewer network calls are pretty straightforward. I think the author chose to do a deep dive on the topic on freeing up the main thread because there's such a wide variety of approaches and many of them may not be obvious.
I'm not sure the author realises _what_ a massive impact bundle size has on the main thread though, especially hydration. The majority of apps I've optimised over the years have the (often vast) majority of main thread time spent on the bundle parse/hydration (plus obviously network).
Also, removing dependencies is not easy. I've seen many corporate that have a huge UI lib for example that everyone should use for brand consistency. But it's many MBs of JS, because it has to cover every possible use case.
This doesn't even get into 3rd party vendors who _also_ ship react et al and have other bundles.
I'm not saying the article is wrong, but if you want to free main thread time especially at the most critical point (when the user has initially loaded the page) you _probably_ will find that most of the opp is in bundle size and hydration improvements.
I would think, or hope, a UI library like that could benefit from webpack and tree shaking such that only the needed components end up in the final bundle.
All good points. Perhaps rather than saying the fixes are straightforward, I should have said it's a straightforward concept to understand. If your app takes forever to load because of a huge bundle, you need to figure out how to make the bundle smaller, somehow. (How exactly to do that is where it gets complicated, like you say.)
Tbh its not just that, you can have small bundles which hydrate extremely poorly.
But yes, I think we are in agreement :).
Can you tell I have mental scars from nextjs bundle optimisation?
NoScript is a remedy for this. When a site is broken I whitelist a few domains likely to be necessary. After a few attempts I bounce. If I see a dozen plus domains I don't even bother. This cuts down on the volume of garbage sites I waste time on and shields me from novel trackers not on any block list.
The web is much faster when useless JS is taken away.
I challenge you to browse the web one week on this laptop part of the current top 10 Amazon best sellers on a gigabit fiber connection and tell me if you still think that this is the problem: https://www.amazon.com/HP-Everyday-Processor-Microsoft-Porta...
Please don't brush off parent's "slow connection". Many people are stuck with that.
A prime example: cookie dialogs. On a slow connection, page loads, large parts are rendered, and you start reading. After that, some script starts to present a cookie dialog, and everything freezes. Page doesn't scroll anymore, buttons don't work, sometimes a previously-readable page is darkened or otherwise obscured so you can't keep reading while this goes on.
Then a whole bunch of stuff is downloading, which (again: "slow connection") takes forever. Like 20s+. Halfway through you see "accept / reject / settings", but none of those buttons respond (except the dark pattern where "accept" often works faster or smoother than either "reject" or "settings". Aaargh!). When things respond again, consider yourself lucky when page re-renders as before.
Which also runs afoul of 1 of my pet peeves with user interfaces: DO NOT PRESENT A UI ELEMENT UNTIL CODE TO PROCESS ITS USE, IS PRESENT IN MEMORY & READY. Really simple right? Yet I see examples ignoring this oooften.
A 'slow' CPU, low RAM/swapping etc just makes this worse. Web developers tend to have fast machines & connectivity so they may not even be aware of this. Or think it's a non-issue even though it affects many users - existing or potential.
It is a problem and plays a role, then the rest of the SPA interactions are as bad. Amplified by 100+ third party scripts.
Stop building SPA, go back to HTML. Re-assess every third party. For extra performance and scaling, implement cache. Relax and see web experience healing.
There's definitely trade-offs. I actually prefer a proper SPA to pure HTML when on a slow connection and interacting with a site a lot.
Especially when trying to buy something. I much prefer to have a longer initial load and then have everything just work instead of waiting as I navigate between pages, the multi stage checkout, confirmation etc.
But yeah, if I'm just trying read a single article on a blog, preloading everything is pointless. A hybrid site with the initial page being server side rendered + progressive enhancement afterwards is theoretically optimal in my opinion.
You typically still have to wait for API calls between interactions, but error handling and number of requests (linked to experience on slow connection) tend to be worse.
If that's a connection-less interaction or something small that stays on the same page, sure it makes sense to keep it in the browser. You don't need to build your whole site as a bloated SPA just for few limited use-cases.
These people definitely have an overly rosy view of the past. The sites that are dog slow shit ux now still would be with server rendered html and jquery spaghetti, just like they were in the past.
Ever submit some giant form to get some random error and then lose the entire state of it? Used to be extremely common, even though it shouldn’t have been.
Losing the entire state happens on SPA. Plus a random error not providing any feedback is a typical SPA experience. You can poorly execute on any technology. It's just much easier to do things wrong using this-year-trendy-SPA-framework.
Use the appropriate technology, everything doesn't have to be a SPA.
And yet it used to be much more common. SPA or not doesn't change how your team executes, what kind of management you're working under, or any other externality that makes you end up with a shit website.
Yet you can look at RUM data (http archive tech report or other) and start noticing it's not just management.
In London in many apartment blocks one can only get wired internet via an old copper cable with speeds like 80mbit/s download in theory but in practice it can be below 30 with ping in 50ms range and much slower upload. And 5g does not help either as the signal can be very weak.
Try 10mbit/s down for a copper connection 30 min drive from Auckland (NZ) CBD Thank God for StarLink and other wireless options.
Okay so that's no excuse for whoever is providing your internet, coax can deliver 800+ Mbps no problem. And if you are actually saying you only get DSL through a phone line in London then holy shit I would be busting down the door of my landlord. They never in the last half a century got wired for cable?!
A phone line from before WWII works fine to make a call but absolutely sucks for DSL.
And in London many buildings are declared as historic making it hard to get a permit for any work. The best chance is to wait until old pipes bursts and digging has to be done in any case to put fiber along the pipes.
It's not that, it's the building owners (freeholders) refusing permission, or not replying. It's a massive issue.
You'll notice buildings in central London that are listed _but_ have housing association ownership nearly all have fibre to each apartment, as they did portfolio wide deals with hyperoptic etc.
And pipes don't help. Openreach (who owns the copper network) are not allowed in 99% of cases to "fix" copper with fibre under the agreements they have with building owners, they can only make like for like repairs.
The worst affected apartment buildings are 90s and pre 2015ish. Everything after that got fibre installed at build time.
Btw it is worth checking if you have an altnet like hyperoptic, community fibre or g network available. The majority do and if you are just checking for openreach or VM broadband it won't show up.
I was using a laptop with windows 10 and 4GB of ram and an anemic CPU a few times a month two years ago. Even with a fast network, a laptop with no ram is gonna be slow to browse, and bloated pages are gonna be slower.
It will certainly help to download the bloat faster, but you've still got to do all the hydration as OP put it.
Based on my experiences with windows 11, that laptop seems like it will be quite a bit worse than the one I was using, even though mine probably has a much worse cpu.
> 【Processor】AMD Processor
> 【Graphics】 Intel Graphics
And this is why you don't buy laptops from Amazon. At best, the seller has no idea what they're doing, at worst, this is fraud.
my point is that as programmers we have to take into account that the average human today has a computer that likely struggles to open Win11 notepad. I don't buy random laptops from amazon, but an astonishingly high amount of people do and we have to work with that
Try it yourself on a gigabit internet. Put CPU throttling in devtools to 10x slowdown (assuming you have a fast computer) and see how fast it is even with super fast internet.
Why would a regular React site be so huge?
Maybe they had bundled fonts and images.
The bundle is just the lib plus your files minified.
You want to bundle vs hitting dozens of requests just to get files.
It’s not like React/webpack is a black box doing things I don’t know or want.
Performance: I challenge you to build a complex 3D game in vanilla threejs vs using r3f. useFrame alone is worth it
What a joke of challenge, there is still no browser 3D game that is a match to Infinity Blade, that Apple used to demo OpenGL ES 3.0 hardware in 2011.
Anyone serious about 3D gaming on the Web has to do streaming.
https://playcanv.as/p/MflWvdTW/
This isn't new at all, just one of the first things I found by googling "webgl demo."
WebGPU of course goes even further.
I think the real gap is just that people by-and-large aren't building real games on top of Safari. It's more lucrative to use the app store with its low-friction payment system.
At the same level, as a commercial game, not a tech demo scene.
I made a project a while back to port Minecraft's desktop version to the web and it runs decently-ish on a good computer with WebGPU (but takes a really long time to load)
[1]: https://owlcraft.raymondjxu.net
Which, again, aren't Infinity Blade graphics.
Kudos on the work though.
[dead]
[dead]
This was functionally enabled by default by Minecraft being java, including the part where it was popularized by a java applet of a very early version.
That ran well back in 2012 on shit hardware.
There are business-level issues with web based AAA games, as I was alluding to before. Apple has a two-click payment system. If you failed a Candy Crush level and you needed to get up from the couch and get your credit card out of your wallet to buy more turns, no one would ever do it.
One thing doesn't prevent the other, yet most Web 3D is hardly any better than Flash games, with worse tooling.
[dead]
ES 2.0
Correct, my mistake.
[flagged]
Prove that I was the one down voting before writing such shitty reply!
Since at least Windows 3.1 we all know that cooperative multitasking is a bad idea. But we see a lot of developers use it, even Rust developers who should know better.
Cooperative multitasking isn’t universally a bad idea (in fact, Rust supports it)
I can't think of a better way to make simple things billions of times slower than they should be.
> I can't think of a better way to make simple things billions of times slower than they should be.
How's it going to do that? What's so bad about it? Especially in the multi-core era which lets multiple programs run at the same time the way that multiple pages can run javascript at the same time. The lack of preemption is only within a single page/program.
During periods of time where no single chunk of code runs for more than a millisecond, cooperative multitasking should have the exact same performance as preemptive multitasking. And even when single chunks of code do run for that long, if that code wasn't properly isolated then preemption doesn't save you from lag.
So the difference only shows up when you have chunks of code that keep running way too long, that are also inside of properly isolated threads/callbacks, and on web those threads/callbacks are not inside web workers. Is that a common situation?
I'm just going to borrow a sibling comment:
> afiori: JavaScript's execution model uses cooperative concurrency to avoid a tons of data races, preemptive non-parallel concurrency would make all web development incredibly harder
You are saying it as if there is some logical consequence.
No, I'm just saying that cooperative multitasking is there for good reason and isn't necessarily a bad idea.
But you left out what the reason is.
JavaScript's execution model uses cooperative concurrency to avoid a tons of data races, preemptive non-parallel concurrency would make all web development incredibly harder
Yes, I was talking from a performance/UX standpoint.
Of course, doing everything in one thread most of the time makes everything easier, because you're using the thread as the lock, so to speak. But using locks is bad for performance and latency and thus UX.
It predates Windows 3.1.
Superb 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.
[0]: https://mordritch.com/mc_rss/
I agree with most of the article, but would clarify the following: > For the screen to look smooth, frames have to be drawn at the display’s refresh rate. On the most common 60Hz display, that means 60 frames per second, or about 16.6 milliseconds per frame.
It isn't absolutely necessary to match the display refresh rate. With a 144Hz monitor, 72FPS is going to look smooth for the vast majority of the people, and even 48FPS will look smooth for most people. I agree that higher FPS is better, but there are diminishing returns.
It's a good nitpick. A hypothetical 1000Hz display will still look smooth to the human eye at 60/120Hz. A 1Hz display will never look smooth.
But it's more about honoring the user's preference. I personally would rather 60Hz, then 120Hz heating up my room unnecessarily. If someone has a display set to 1000Hz for whatever reason, then you should try your best to honor that.
A user's hardware represents the worst case scenario they want to be able to handle, not their preferred nominal settings. Most people aren't changing their screen refresh rate when they switch between playing a game and reading wikipedia.
It depends. My display being at 1000hz doesn't mean I need your homebrewed accordion menu eating up the CPU to slide out and wiggle at 1000hz
Below a certain threshold things are certainly going to look janky. But you’re right you don’t have to match the screens native refresh rate. More important is that you have a consistent frame rate. If you can’t hit 120hz, it’s better to target 60hz, rather than 120 a miss your frame budget. 30fps will also look better than 60 but regularly dropping frames.
I generally agree, though "consistent" can by varying levels of strict depending on the tradeoff you want.
But importantly, if your screen is variable refresh rate or high rate enough compared to your typical performance, that greatly reduces the inconsistency. Go ahead and vary between 55 and 70 if the screen is at 165. Definitely don't drop to 30 and I don't think you want to drop to 41.25 either.
Great piece, OP. We work in WASM and are considering web workers to help with rendering documents off the main thread in that context. I was surprised to read that ArrayBuffer is moved by reference only! Might be an option. Thanks for putting this together.
ArrayBuffer is copied by default unless you pass it as a special transferable object. But only the current owner of the buffer can use it.
If you need to read and write from both threads at once, you need to look at SharedArrayBuffer.
haven't done this for documents, but for canvas rendering transferControlToOffscreen() worked better than moving ArrayBuffers. It hands the canvas to a worker that draws directly, no pixles over postMessage at all.
Top article, kudos! applied some of these techniques previously, and they do matter a lot. thing is, when you learn/teach JS there is usually limited time left to talk these topics, and they are essential more than it seems.
the whole point of cooperative multitasking is to yield now and then (back to the runner), so that it can process the drawing. Besides, at 60fps there's so much that can be computed once every N frames, and the eye does not see it, the animation flows.
It becomes even more interesting when webgpu is involved, but the CSS animator is indeed very fast.
note: some recent work of mine (newskool digital flyer sites) -> bsf.hmsu.org // nouveauxhivers.dub4powder.xyz
FYI: This isn't a browser-only thing. All platforms (Windows, Mac, ios, android) typically have a single-threaded UI.
For responsiveness that’s what you want, context switches add quite a lot of jitter and perceived slowness’s, making your app feel slow despite running at 120 fps.
This article concludes with the following statement:
> So much of development is trade-offs, and you have to choose according to the situation, which ultimately comes down to the developer’s experience and judgment.
It’s a great article, but I think it is a bit behind the ball in framing scheduling problems as a matter of “experience and judgment”. The problem of allocating work to a scarce resource is one of the oldest and most well-studied in all of computer science. It would make sense to go consult a textbook on the matter before trying to reinvent the wheel.
Well yes. But most of those studies assume/assert control over the environment. In this case you are running in the browser and you have to deal with the primitives it gives you. Both in compute management (threads/workers), communication (RPC, messages, shared memory, sockets), as scheduling (like having yield or not.
I’m not sure whether inventing a setup like green threads in JavaScript/workers would even be possible.
That is not to say that we should just forget about those learnings though.
Do you have any suggestions for books on the topic?
This! Since it became easier for people to post their thoughts on a problem vs. research and learn from past work, we're now in the era where its harder to find the seminal and really-well-explained material for having to wade through years and years of people's rediscovery blogs.
(Don't get me wrong; I too think the article is great; just wish all the folks who went to JS bootcamp and are amazed by this would have cracked any CS or OS text book written since the late 60's and browsed a few chapters.)
The discussion of "FLIP (First, Last, Invert, Play)" would be improved by mentioning the View Transitions API, which is basically there to automate this technique.
Excellent article, I went into it thinking the headline is obvious, but the examples are well crafted and it isn't just the obvious stuff.
I remember seeing some JS cryptography library a long time (maybe 10 years?) ago that provided an async hashing function for exactly this reason: to split up what would normally be a simple synchronous computation and yield more often to the main thread.
Can't recall the name, but I remember thinking that was very clever once I understood why it was doing that, and am glad to see the concept explained directly here.
In the first example: doesn't pushing the button while typing cause the textfield lose focus? What's the point of the typing in the example?
I think the point is, if you click the '2.0s' button, you cannot re-focus on the input field for those 2 seconds.
Here is a problem that I had thought about in my last frontend project: the project needed to parse a user-provided string to provide syntax highlighting. The implementation was to parse the string immediately after a user keystroke so the user always sees correct colors. But I had this nagging thought that if I had designed the grammar wrong some parses might take more than linear time and would hold the main thread during the parse. But I didn’t really want to first render a black string, parse on a service worker and then rerender with color. The effect must have seemed disorienting.
Anyways I stopped the project for unrelated reasons and this thought kept nagging me in the back of my mind. The time I work on the project I’ll be sure to try some techniques in the article.
You'd use an incremental parser, they're specifically designed to be efficient for small edits. The big name is `tree-sitter`, but its output is compiled so on the web it requires some wasm shenanigans. For webpages, I'm a fan of `lezer`: https://lezer.codemirror.net/docs/guide/
Brilliant, I had no idea about this stuff. Thanks for writing it up.
On the price ticket example, on my device (Samsung A15, mediocre phone from 2024) I get 11 fps with the slow example and 30 fps with the fast one. (15 if I scroll!)
Is that a case of the back pressure you mentioned?
All the other (fast) examples are 60 fps though :)
Such an excellently written articles with really nice interactive visualizations!
Nice examples, a bit repetetive perhaps.
One thing that I found quite interesting to see is how the behaviour of the "4.000 particles" demo changes between the 5ms rendering and the "everything now" rendering.
If you are currently trying to build a web-based clone of something approximating ChatGPT, pretty much everything in this article is absolutely mandatory.
The streaming response UI/UX is a total nightmare to make work smoothly. You have to come up with clever heuristics around where to chop up the stream of changes and how to batch the work relative to frame updates to make it not look like confetti during a streaming response.
I really don’t understand why the LLM web chat clients have all converged on this UI where one character appears at a time. It is kind of fun the first time (like you are watching some Harry Potter special effects where an enchanted book writes itself). But really they could send sentence or paragraph long chunks of text, it would be fine.
Seems like an artifact of the time when tokens-per-second were low enough that people needed to be informed that the machine was actually doing something.
I suspect one reason is to subtly make the user feel more like they are interacting with a person.
> But really they could send sentence or paragraph long chunks of text, it would be fine.
The problem is that the content is multimodal, often recursively.
You can be inside markdown and then have a python code section. Simply detecting these boundaries is already challenging.
Reminds me of sprinkling DoEvents all over my VBA code to keep it "snappy" when I started to get into programming
I wish await in JavaScript could conditionally yield. Instead I end up having to use arounds like if (shouldYield()) await do yield();
There's an RFC or two to spawn threads so I'm looking forward to that. The current way of workers + messages is tedious as hell.
Isn't that basically AsyncGenerator?
Not really, that still yields on every invocation
I 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!
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 web inspector is often overlooked. Other important spots to look at are the Network tab and Lighthouse (in Chrome).
The chat example here doesn't really seem to work for me—I get 32 FPS consistently no matter what the chat settings are. Maybe a Chrome thing? Or an M3 thing?
This was so incredibly helpful and well presented.
I 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.
That's the kind of content I come to HN for, thanks!
AI;DR – too bad as the content seems to be worthwhile, but then why not take the trouble to write it up yourself. Have it proofread/edited/spruced up all you want afterward, but don't have it do all (or most of) the writing.
> Press a button: the JS animation and typing freeze, but the CSS animation keeps spinning
How do you expect me to type if pressing a button moved text focus away from the text field?
> 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.
Using a lighter weight DOM can help. There's always a point where it starts to bog down, but many pages are just unnecessarily heavy because they're relying on so many nested widgets and whatnot.
> what's your solution to the performance hit that you get when you load up the dom with a zillion things?
Browsers can easily render and scroll through entire wads of content.
The problem is, when the "line" comprising an email in the email list of Outlook Web is in a maze of (literally, just looked it up) about 30 divs deep, performance inevitably goes down the drain.
Computers in the 00s could handle inboxes with thousands of emails just fine and scroll through them. Outlook struggles keeping more than 30 in active memory. That's gotta be a joke.
By the way: the solution is rendering tabular stuff in, well, tables instead of armies of divs that try to be tables. That case has been optimized to death because that is how websites and applications used to be built.
The solution is to improve the browser to remove the performance hit. Modern computers are extremely powerful so there is no good reason why they would not be able to handle a zillion things in the DOM.
The browser can easily handle millions of calculations and then render a million DOM elements so quickly that you won’t even notice it. The problem is when you try and do this hundreds of times very second.
The irony is that obsessing over smoothness and frames per second is what causes this in the first place.
A zillion things is more than a zillion bytes of RAM :p
great article - explains in detail why my sans js websites run so smoothly and so fast.
Yeah, 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.
and if you have no website at all, it takes zero seconds to load.
But for people who are developing websites that are more than just text, this is an excellently written article and great advice.
It's funny, for mobile app dev it feels like the community are a lot of focused on staying off the main thread, this is the first time I've come across one for webdev.
Well yeah but if you do actually need things like images, animations, high frequency updates, etc, this is actually a pretty good overview of how to approach it. Also learned that react uses posting to a MessageChannel to yield!
GP is right that just like with garbage where "reduce, reuse, recycle" is the mantra, the first question for optimizing something should be if you need to do the calculation at all.
This is true as well, yeah, but it came off as dismissive of everything too. Personally I prefer information dense interfaces with minimal chrome, but there really is a certain joy when you get to use a well designed and optimized fancy reactive, immersive interface
Since when do images need more than just an <img> tag and a bit of styling?
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.
I'm more surprised how cheap it is in browsers because I know it's not that easy - they are really really good at it. Pure text rendering is therefore rarely an issue.
Amazing how you are being so down voted, most webpages do utter crap that no one would want the webpages to be doing other then advertisers. Really most things should be text and if we lived in a more cooperative world everything would be easy to parse and manipulate text with some video and images and perhaps various well defined interface types for different services that can be implemented in various ways as to the users liking.
Sure, but there are sites like HN and there are sites like https://earth.nullschool.net/
What's your point? Are you saying all animations and rendering are unnecessary?
My point is that many websites are using way too much technology for what they need to do, with correspondingly long load times and choppy runtime behavior.
Correct. But if the page is, at least in part, an art piece rather than an information dump, or needs to do interactive rendering for its purpose (an editor like the markdown example, live updating status displays, games and other interactive toys, etc), then the tech is necessary and this article is useful.
Which is something like less than one percent of websites, and this technology is deployed much, much more widely.
Again, correct. But “don't do this if you don't really need to do this” is rather pointless to say, hence is being downvoted, because people already being that sensible don't need to hear it, and those who are not are unlikely to listen. The comment is just noise, as unnecessary as the unnecessary animation and other gumf that it is railing against.
What does "Browser's Main Thread" even mean when there are over 30 processes running?
A handful of comments on an otherwise fairly reasonable article.
> When we run into jank like this as developers, the usual reaction is to wonder “is my code slow?” and start picking apart algorithms or looking for wasted computation. In most cases, though, the speed of the code is not the problem. The code isn’t slow. It just happens to be the code that’s holding the main thread.
Eh, most of the time it is slow, because you chose to use React. React used naively scales very badly. You have to jump through lots of sometimes-fiery hoops to make React… not much slower than some of the alternatives. Memoisation (possibly now via React Compiler) and things like that.
> [Diagram with rAF, Style, Layout and Paint attributed to the main thread]
Paint hasn’t been on the main thread in Firefox since 2017: https://mozillagfx.wordpress.com/2017/12/05/off-main-thread-...
Not sure about other browsers. Firefox has generally been the leader in these areas.
> [steering cost demo]
The demo is deeply unsatisfying because the simulations are quite different in a very problematic way: in “all at once” mode, it loses most mouse movements, which radically affects the simulation which is attuned to movement events rather than simulating physics based on a constant tick rate. Without examining it closely, my guess is it’s using pointer events and the browser is coalescing the events because of the blockage and it’s only taking the final state rather than going through all of getCoalescedEvents(). In a simulation like that, if you can’t run it at full speed, you have to decide what to do, and you should do it deliberately, because it may be disastrously wrong. Should you fall over, simplify the simulation by dropping some of the calculations, reduce the tick rate, something else?
> The demo below is a markdown editor with a long CHANGELOG open. Building the preview means parsing the entire document (about 2,000 lines) and rebuilding its DOM from scratch, which is far too expensive to run on every keystroke.
No it doesn’t. This is a clear example of your code being slow, because you’re doing the wrong thing. You want an incremental parser of some kind. Markdown is tolerably well-suited to this kind of thing because for most edits you can just render the current paragraph.
The suggestion is bad. “Debounce 300ms” behaviour is obviously worse for small documents.
> DOM writes can be batched as well. Appending a hundred nodes in one operation instead of one at a time, or toggling a single class instead of changing style properties individually, turns many changes into one and helps performance. The old technique of assembling an HTML string and assigning it to innerHTML in one shot has the same essence. You gather the writes so the rendering pipeline’s fixed cost is paid once.
This is simplified far beyond accuracy. parent.append(one_hundred_nodes) and one_hundred_nodes.forEach(node => parent.appendChild(node)) are unlikely to perform particularly differently. Changing style properties individually isn’t that* much worse than toggling a single class (it amounts to rewriting the style attribute a bunch of times, and the CSS parser and serialiser aren’t particularly slow). Building an HTML string and assigning it to innerHTML is better than constructing children manually in some cases, worse in others. The real thing that matters is avoiding triggering layout unnecessarily by things like accessing clientWidth between changes.
> Deferring
The lazy rendering trick used here is very problematic because you still need to know how tall each item is. Plenty has been written about hazards of infinite scrolling, that’s what’s being dealt with here. Now if you can have each item be a fixed height, then progressive rendering has far fewer side-effects. I would also say that switching from Notifications back to Feed and having it take an extra few hundred milliseconds is really not that bad. And that I’m not convinced the approach taken was right anyway, you could often just leave the feed rendered and avoid affecting the gross layout.
—⁂—
On the presentation of the site itself: this makes no sense:
[dead]
[flagged]
[flagged]
So this is AI slop written? Why would anyone believe I'd want to read AI spam?
Also, the issue I see is who controls browsers as much more profound. We need to find a solution here, as the browser is too important to allow private companies to keep mankind hostage.
Edit: Wow, and the praise-accounts. Is that new on hackernews?
Honestly... i'm usually on the AI;DR bandwagon but this was actually good :/
I started reading and it immediately sounded like AI, sent it to pangram and it agreed. The amount of posts praising it like it's fuckin oxygen or something ... dead fuckin internet
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 writing slop.
I think you're overindexing here. There are no obvious traces of AI in those full paragraphs (and I read thousands of lines of AI generated text daily). These are not the usual tells, just decent writing.
It reads pretty much like every well-written technical article used to, ten years ago; and scores a 0% likelihood of being AI generated in Quillbot.
Somewhere along the line "machine translation" became conflated with "machine translation + LLM editing"
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
The javascript web is. Restore the interop with noscript/basic HTML and it will lean towards sanity, something lost a few years ago.
It would be better to say that the Browser's Main Thread has been made expensive to run, because browsers have had a bunch of crap piled on them in terms of functionality that is expensive to run.
Actor Model, dedicated or shared application worker. Full support for multi-window apps. Resolved since 2019. 26000 commits in, and counting. You are welcome!
https://github.com/neomjs/neo/blob/dev/learn/benefits/body/O...
This mistake gets repeated over and over again, in every single GUI framework of any kind. I don't understand why does it have to be that way.
Just use multi-threading. Run each library in a separate thread. Use actors approach to pass data between libraries, application and finally to submit data to update GUI.
Using single thread for everything and expecting that developer will create separate threads for heavy work is obvious approach, but it never worked. Developer doesn't care. And user gets inferior experience.