[michalstanko]

The short answer: Tracking and advertising. Longer answer: All of the above + bloated frameworks (frontend and backend) + unoptimized/excessive static assets.

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.

[shp0ngle]

Why does tracking and advertising take so much time to load and display?

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?

[yawaworht1978]

Some of the scripts need to be placed in the head section of the document which is a blocking operation.

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.

[mrweasel]

Best answer that I can give you is: Because many of the ad companies are run by sales people.

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?

[Volker_W]

> They would continuesly lie about their implementation

Really? Could you give more examples?

[mrweasel]

Sure, we wanted to use Google Tag Manager, to load their javascript, because they already lied about it being async. So we’d use GTM to avoid them blocking our order confirmation page, when they had issues. So we asked if that would be an issue. It would not, their product worked well with Google products. It did not work, it completely failed to pick up the correct dom elements, it had never been tested with gtm. Again they also promised that they’d more to a real HA setup, but the never did.

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.

[p_l]

Consider typical Medium blog post.

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.

[shp0ngle]

I guess.

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.

[jazzyjackson]

Round trips for ad auctions are a part of it, but my take is that there are redundencies, literally a dev team that doesn’t exist anymore wanted to use one metrics tracker, it was never deleted and a newer team introduced a separate stack to check how long you gaze (sorry, “dwell”) at each paragraph. Multiply this by 10 years. Medium used to be relatively snappy (cached CSS and text + pretty slick lazy loaded images) but nowadays its another lumbering dinosaur.

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.

[p_l]

And the core website that the developers actually see while working on it might be just as fast as you imagine!

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.

[hidden-spyder]

Any way to stop all those requests?

[p_l]

Well, uBlock Origin and uMatrix worked pretty well for that, but with new Manifest v3 the feature will be lost

[hidden-spyder]

That's for Chrome. I'm on Firefox.

[p_l]

I think there's uBlock Origin for Firefox?