Why? Most trackers load async and don’t block the page from loading or rendering. I get it’s popular to hate but technically they load without blocking page from rendering. A good read is https://sites.google.com/a/webpagetest.org/docs/using-webpag...

Even just one poorly designed library can cause serious memory issues and trigger a ton of events. Usually it’s the marketing and ad people that throw around this “but they are async loaded”. That’s true, but doesn’t change the the fact that 40 trackers and their dependencies that come with it are slowing down and infringing on the users privacy. Let’s be real.

Can you share an example site with 40 trackers? I believe you but it just doesn't seem common place.

There has been a lot written about this, but here's a test I just ran on a random page on Huffington Post:

https://www.webpagetest.org/result/181031_TT_443f9d1e666d08f...

The article is probably <200 words, but the page is 3.2 MB and makes > 200 requests. There are 55 Javascript requests in there.

Right, HuffPo is egregious. How about a site HN readers might frequent, something lightweight like Reddit?

https://www.webpagetest.org/result/181031_H6_eaa2e64c9969515...

Random Reddit page, content: medium-sized image. 164 requests, ~12 seconds to render the page on the test rig. 60 Javascript requests. 1.5 MB of JS downloaded to display the post, a 46kb image. There's a 30:1 ratio of JS to post content (what the user wanted to see) here. And there's other bloat beyond the JS.

I just picked these two sites at random. You can do this all day with random websites. I would guess that most sites behind a .com (or .co.uk, etc.) will look similar.

I don't mean to pick on these sites, just wanted to point out that these practices are widespread and even reputable developers engage in them. Which will make it more difficult to undo the rot.

I see there is a lot of JavaScript but are you certain that is JavaScript with the sole purpose of tracking or application code? I’m not gonna say these sites could not be implemented better but the claim was these are all tracking pixels. Is that true?

You're parsing this too narrowly. I'm not making a claim about the purpose of each request. I'm looking at the totality and saying that maybe making 200 requests to display 200 words of content is overkill.

The larger claim was that the pages are loaded with junk that affects the performance of the pages. The signal:noise ratio on modern sites is broken, and optimizing the junk can only accomplish so much. Developers need to advise stakeholders of the downside costs, performance among them, of loading sites with bloat.

Here's an article I read a while back on the impact of specifically Javascript:

https://medium.com/@addyosmani/the-cost-of-javascript-in-201...

I agree but if you look at the parent response claimed 40+ tracking scripts, I just don’t see 40 tracking scripts I see a website using probably too many scripts to implement functionality but I can’t claim to know they can do it with less scripts - I can only assume and that is what the website posted in the original document talks about how to optimize... hence async and trackers not blocking comment was correct

They may load async but JS parse + compile + execute takes up client device CPU cycles and can block the main thread from responding back to user actions immediately. More so on mobile devices. This, and the fact that a typical page has multiple such trackers can cause notable overhead.

Can you share some example sites where the CPU cycles on mobile are a major impact? I suspect maybe news websites? I just don't encounter many on a daily basis where it has an impact and most sites I look into for performance - the issue definitely isn't trackers. It's almost always oversized large css files and blocking js files. When you dig into the site you usually find that it will be very challenging to architect it to avoid the blocking script or shrink the css... but again would love to see some "typical" examples.

They may not be blocking, but it's an extra burden on my limited bandwidth (slows other connections down while it downloads) and balloons the memory usage of sites that are otherwise delivering static content.

Usually the browser has a priority on each connection and when you load a script async the priority is set to low. Have a read here: https://developers.google.com/web/fundamentals/performance/r...

Love knowing this kind of stuff, thanks