I guess we all know this, so I apologize if you meant it more as a rhetorical question.
As for Gmail, I've never had a problem, it's always pretty fast, considering all the features it has.
I would not really mind ads and being tracked if it didn't make internet sometimes literally unusable?
"bloated frameworks"... I remember when React was touted as "faster than native DOM"! Which didn't make much sense even back then, because you need to do the things in actual DOM too... but... there was always the push of speed
So where is the bloat from, really.
Javascript can be really fast. It's just, nobody really cares? I guess?
Seriously, we struggled with an ad/retargeting company, they ran EVERYTHING of a single EC2 instance and they didn’t understand the internet. If/when their service went down the checkout pages of all their clients would timeout. The word async meant nothing to them, but hey better to crash than not track users. They would continuesly lie about their implementation, because they failed to under basic terminology. “This is a HA setup, right?”, “Yes, it’s a cloud solution in AWS”. That just meant: Why would AWS go down?
Really? Could you give more examples?
Oh I forgot. They claimed that their solution was custom made, tailored to the need of their business and the business of their customers. When we asked for a few tweaks, to make implementation easier it turned out to not be true. It was in fact an off the shelf solution and they had no influence on the development. We only found out because some of the Javascript revealed the real authors.
If by chance you block certain actions, you'll see it spin ridiculous amount of CPU, trying to sent tracking data all the time over graphql.
Some tracking systems injected (often without developer involvement, using so-called tag managers) will send your mouse position and clicks.
Through tag managers, you can easily end up loading 50 different scripts, often compiled with attendant framework code, usually in chains of tag manager loading tag manager (classic example - using Google Tag Manager to load Facebook manager and Google Ads, which then issue multiple calls to load JavaScript ads and trackers, which might involve further script loads).
And the tag managers are often managed by marketing in complete separation from any development or QA, so what was reasonably good website loading fast even under limited network conditions, suddenly turns into huge freeze-fest as 3 autoplaying videos get preloaded, 2MB JS/CSS animated overlay ad loads in, 3 ad boxes are filled in dynamically , and don't forget 15 trackers, 4 of them from ad services, 8 of them added by marketing team with possible duplicates, and 3 of them part of malware loaded by the ads.
The fact is, modern javascript is FAST. And with http3, and compression, you can make things load really REALLY fast. Much faster than in 1994!
And you have things like tree shaking where you can make the js tiny. Not speaking about wasm, that’s even faster, or putting things to web workers. Modern CSS is so easy to use. And of course CDNs are nowadays all around the globe. Chrome debugging tools are pretty good to debug slowness.
What I am saying by long way and repeating… it’s easier than ever to make a fast website!!! I know first hand, I made some websites recently, with really heavy logic on the FE in JS.
So why are all these websites so slow… ugh.
The tools are there! It’s not like it is inscrutable.
I guess it’s related to that notion “groups of people can never admit a mistake” - if they ever did a clean sheet redesign it could turn into neo-facebook/reddit (somehow even slower due to extremely tall dependencies) - but they can never go back to first principals of how the site used to work, it would be admitting that things have gotten worse with time.
The developers are not in charge, usually, of what rules will be loaded into a tag manager by the marketing team (which might involve different sets based on URL or various other tracking data). The tag managers themselves and base ad auction and spyware stuff might be pretty performant, too - it's when you hit all those third party ads etc. that you might also see some shitty code.
But when many of those "features" are written assuming all the extra budget for themselves, well, things go bad fast.
Some of the ads are generated on the run based on that tracking data and it involves many, many http round-trips before it's injected via ajax. Further, comment sections have some sort of fb tracking integration, triggering even more round trips.
And all that is separately loaded on a non optimized website layer with many externa JavaScript frameworks and dependencies.As well as injected video components, huge images which most likely aren't optimized. Lazy loading should be native now, no jQuery function needed, no intersection observer either, and it does work ok, but it's often not properly implemented or not at all.
As for react, the stripped shadow Dom might be faster then the native Dom, but you still need the Dom and react is still a heavy load. I remember the days when people said don't needlessly load jQuery. Today, people use react when there's no real need to do so.