This post includes recommendations for teams that are procuring websites, and I think they can be summed up as: *buy simpler problems*.
Every feature that gets added via JavaScript is more complex, more expensive, and harder to improve. That means that when things go wrong, they're treble costly to fix because JS is *"f-it! we'll do it live!"* for web development. JS disables or routes around all the ways the browsers try to help.
Let browsers help!
Everyone in a site's production chain has agency to prevent disaster
The number of times I tried advocating for this at my previous job 🤷♀️ I didn’t always succeed but talking about it, repeatedly, is useful. “Isn’t that your job?” was always on the tip of their tongue, understandibly (to a degree).
The best argument I found was in the studies that show x% longer page load leads to y% loss of conversion (ie. direct correlation to campaign success, hence revenue).
And the best example for that was the home page, specifically the hero images in a carousel that was under the responsibility of the marketing team. They had tools to upload the images, set the links and alt text in the various languages the site was available in, set a schedule etc so there was no technical involvement at all. Sometimes there would be 6 or 7 images in that carousel, noticeably slowing down page loads on that most important page.
@GuillaumeRossolini @slightlyoff
What's frustrating is that sometimes the bad performance isn't really the result that of a framework used, or true incompetence.
We're now investigating and refactoring an app of ours. There's nothing really too odious... but a death by a thousand cuts: features brought in under impossible deadlines, invalid device assumptions, original architecture not evolving for new requirements etc.
1/
@GuillaumeRossolini @slightlyoff
To the point that our assumptions about perf bottlenecks end up being wrong and appear in a different place from what we originally assumed :)
2/2
@dmitriid @GuillaumeRossolini This is why teams should always prefer simpler problems; when you don't have good operational control and observability, the complexity of the architecture multiplies your costs to remediate.
See also: https://infrequently.org/2022/05/performance-management-maturity/
Despite advances in browser tooling, automated evaluation, lab tools, guidance, and runtimes, modern teams struggle to deliver even decent performance with today's popular frameworks. This is not a technical problem per se. It's a management issue, and one that teams can conquer with the right frame of mind and support.
@slightlyoff @GuillaumeRossolini
Also, as additional data point to "get the team and managers to use cheap phones", I cannot stress the importance of "bad" devices enough.
In our case we develop for smart TVs and gaming consoles. A five-year-old TV on the lower performance spectrum? Well, millions use it, and you have to support and test on it. And that's on top of constraints (CPU and RAM) thar partners impose.
Sadly, people forget about it on the web proper.
Alex Russell
Guillaume Rossolini
Stuart 
dmitriid