In my experience it does. A place I worked once had a mysterious dip in user activity with a deploy, and the deploy only included a shadow feature that nonetheless still loaded the required, but not optimized assets. When we removed the loading of the assets user activity went back up.

This was a decade ago so I don't remember the exact specifics. The dip was high enough that we basically stopped everything else and immediately investigated.

This is very shallow short term view on things. Performance also impacts customer retention, loyalty, satisfaction and word of mouth advertising because of that, makes engineers feel good and proud about the things they do, rewarded and motivated to keep going and not leaving to do something else, etc. Hardly "a waste of resources".

Is it worthwhile making a page load 10x faster?

If you go from 10sec to 1 sec, absolutely.

If you go from 1sec to 100ms, maybe.

If you go from 100ms to 10ms, unlikely.

Assuming "fast enough for a good user experience", expecially early on in a product lifecycle, I prefer to focus on development speed than product speed.

> Is it worthwhile making a page load 10x faster?

I get your point. This is an outlier, but hear me out:

For some of the workloads I run on https://workers.dev, I can tell you that going from 100ms to 10ms is something I look for every single day. I am also very interested in anything that takes the memory usage down into KBs from high MBs, say.

What webpage that you frequently use takes up to a minute to load? I can't think of a single one I've used over the past year.

Open the developer tools and see for yourself.

Of course by "load" I don't mean TTFB, I mean actually loading the full page, including all the spinners, reflows, banners and toolbars popping into your page, images, etc.

Why does that matter?

But even better:

1) Use a framework/language that is optimized by default instead one that is slow by default. Ex: Svelte only recalculate only the part of the UI affected by a change. Most of the other frameworks recalculate the whole virtual DOM.

2) When you can write something fast or slow in the same amount of time go for the fast one. It seems trivial even mentioning it but sometimes people with "make it work first, make it better later" do not even spend few seconds pondering this.

Practically, not much can be quickly built in Svelte. There's thousands of React components I can download right now to solve my problems. Shipping features to users has a much bigger impact on a business than subpar page load times.

“not much can be quickly built in Svelte” - is this an experience you actually have from trying it? Because it’s very far from what I’ve experienced. So many things in Svelte can be done with surprisingly little code.

Also in my experience, those thousands of React components are going to be a source of new problems. The more of them you have, the more likely you’ll run into frustrating limitations that contorts your code to an unmanageable mess.

I do not. However, I have used React and Angular and they all take roughly some baseline amount of effort to achieve anything. And in all of them, I've had a times the need to rely on the community to ship product features faster. Have you tried implementing accessible drag-and-drop lists? Atlassian, for example, has spent years working on that problem, making a well-polished, enterprise-grade, cross-browser dnd solution (react-beautiful-dnd). And DND might be just a small feature of any otherwise much larger app. Foregoing all of these existing tools to start with a new UI framework is not a decision to be made lightly.