7 ms·

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 be

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.

jcelerier 14d ago
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-Portable/dp/B0H94BMX1K/ref=zg_m_bs_g_565108_m_sccl_5/143-6149589-1760914?psc=1 https://www.amazon.com/HP-Everyday-Processor-Microsoft-Porta...
- cryptonym 14d ago
  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.
  - doix 14d ago
    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.
    - phoghed 14d ago
      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.
      - cryptonym 13d ago
        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.
        phoghed 13d ago
        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.
        cryptonym 12d ago
        Yet you can look at RUM data (http archive tech report or other) and start noticing it's not just management.
    - cryptonym 13d ago
      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.
- RetroTechie 14d ago
  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.
- fpoling 14d ago
  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.
  - Spivak 13d ago
    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?!
    - fpoling 13d ago
      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.
      - martinald 13d ago
        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.
  - sam_shingler 13d ago
- martinald 14d ago
  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.
- deathanatos 13d ago
  > 【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.
  - jcelerier 13d ago
    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
- toast0 13d ago
  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.
amelius 14d ago
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.
- pjmlp 14d ago
  It predates Windows 3.1.
- odo1242 14d ago
  Cooperative multitasking isn’t universally a bad idea (in fact, Rust supports it)
  - deleted 13d ago
    [deleted]
  - amelius 13d ago
    You are saying it as if there is some logical consequence.
    - odo1242 13d ago
      No, I'm just saying that cooperative multitasking is there for good reason and isn't necessarily a bad idea.
      - amelius 13d ago
        But you left out what the reason is.
  - econ 13d ago
    I can't think of a better way to make simple things billions of times slower than they should be.
    - odo1242 13d ago
      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
fxd 14d ago
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
- pjmlp 14d ago
  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.
  - StilesCrisis 14d ago
    https://playcanv.as/p/MflWvdTW/ 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.
    - pjmlp 14d ago
      At the same level, as a commercial game, not a tech demo scene.
      - simpleintheory 14d ago
        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 https://owlcraft.raymondjxu.net
        pjmlp 14d ago
        Which, again, aren't Infinity Blade graphics. Kudos on the work though.
pjmlp 14d ago
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.
- thataccount 14d ago
  >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.
  - w29UiIm2Xz 13d ago
    There is no good technical solution for rendering on the server and upgrading to an interactive experience on the client.
    - pjmlp 13d ago
      Most websites don't need an interactive experience on the client, for what is static content.
    - sgift 13d ago
      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.
      - w29UiIm2Xz 13d ago
        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.
pverheggen 14d ago
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.
- martinald 14d ago
  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.
  - bot403 13d ago
    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.
  - pverheggen 13d ago
    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.)
kevin_thibedeau 13d ago
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.
deleted 13d ago
[deleted]

jcelerier 14d ago

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-Portable/dp/B0H94BMX1K/ref=zg_m_bs_g_565108_m_sccl_5/143-6149589-1760914?psc=1 https://www.amazon.com/HP-Everyday-Processor-Microsoft-Porta...

cryptonym 14d ago
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.
- doix 14d ago
  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.
  - phoghed 14d ago
    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.
    - cryptonym 13d ago
      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.
      - phoghed 13d ago
        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.
        cryptonym 12d ago
        Yet you can look at RUM data (http archive tech report or other) and start noticing it's not just management.
  - cryptonym 13d ago
    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.
RetroTechie 14d ago
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.
fpoling 14d ago
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.
- Spivak 13d ago
  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?!
  - fpoling 13d ago
    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.
    - martinald 13d ago
      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.
- sam_shingler 13d ago
martinald 14d ago
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.
deathanatos 13d ago
> 【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.
- jcelerier 13d ago
  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
toast0 13d ago
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.

amelius 14d ago

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.

pjmlp 14d ago
It predates Windows 3.1.
odo1242 14d ago
Cooperative multitasking isn’t universally a bad idea (in fact, Rust supports it)
- deleted 13d ago
  [deleted]
- amelius 13d ago
  You are saying it as if there is some logical consequence.
  - odo1242 13d ago
    No, I'm just saying that cooperative multitasking is there for good reason and isn't necessarily a bad idea.
    - amelius 13d ago
      But you left out what the reason is.
- econ 13d ago
  I can't think of a better way to make simple things billions of times slower than they should be.
  - odo1242 13d ago
    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

fxd 14d ago

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

pjmlp 14d ago
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.
- StilesCrisis 14d ago
  https://playcanv.as/p/MflWvdTW/ 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.
  - pjmlp 14d ago
    At the same level, as a commercial game, not a tech demo scene.
    - simpleintheory 14d ago
      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 https://owlcraft.raymondjxu.net
      - pjmlp 14d ago
        Which, again, aren't Infinity Blade graphics. Kudos on the work though.

pjmlp 14d ago

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.

thataccount 14d ago
>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.
- w29UiIm2Xz 13d ago
  There is no good technical solution for rendering on the server and upgrading to an interactive experience on the client.
  - pjmlp 13d ago
    Most websites don't need an interactive experience on the client, for what is static content.
  - sgift 13d ago
    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.
    - w29UiIm2Xz 13d ago
      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.

pverheggen 14d ago

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.

martinald 14d ago
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.
- bot403 13d ago
  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.
- pverheggen 13d ago
  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.)

kevin_thibedeau 13d ago

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.

deleted 13d ago

[deleted]