With web content it’s the exact opposite. Every time you are a bit lazy, and add another mushy, poorly optimized dependency, the cost is paid by every one of your users.

The better analogy is that the web is like an assembly line that serves content. Do you want wooden equipment with poor tolerances making up that assembly line which takes twice as long and occasionally dumps parts on the ground, or do you want a well-optimized system working at peak efficiency?

Plain HTML renders several order of magnitudes faster than post-load JS rendering, and yes, it is noticeable, especially if you account for variable connection speeds.

Most web devs develop on localhost and test on some of the best connections you can get today, leaving network performance testing as an afterthought at best... and it shows.

When I look at the massive backlog of requests from my users, not a single one is "speed."

I've recently come across several such applications that were "split up" for no good reason. Just because it's the current fad to do the microservices thing. Someone liked that fad and decided that over-architecting everything is going to keep them employed.

To clarify: This was strictly worse in every possible way. No shortcuts were taken. No time was saved. Significant time and effort was invested into making the final product much worse.

It just grinds me gears that we have all these wonderfully fast computers and we're just throwing the performance away.

My analogy to customers where I consult is this: What you're doing is like buying a dozen sticks of RAM, and then throwing ten of them into the trash. It's like pouring superglue into all but a couple of the switch ports. It's like buying a 64-core CPU and disabling 63 of those cores. It's like putting some of the servers on the Moon instead of next to each other in the same rack.

Said like that, modern development practices and infrastructure architectures suddenly sound as insane as they truly are.