[masklinn]

The page triggers 50 HTTP queries and is 3.85MB, so a CDN is only going to do so much.

* the base page is light but has very high latency (250ms)

* there's an almost-empty CSS (style.css) next to one which seems a bit overwrought (screen.css, 140KB is a lot for a CSS file), oh plus normalize from cloudflare despite it apparently already being included in screen.css

* you're loading 9 different JS files from your CDN, plus some emoji crap from not your CDN

* typekit accounts for 1 JS query followed by fetching 12 different font files, at 15~30K each

* 14 different queries to "driftt.com" whatever the fuck that is though I expect some sort of analytics/tracking crap given

* tracking & analytics & ancillary service queries up the ass: hubspot (4), facebook (4), google analytics (2), drift.com (2), others (5)

* the Lato CSS from google fonts but apparently not the font itself, on the other hand you're loading "larsseit.otf" from your CDN, maybe pick just one?

[SAI_Peregrinus]

It also works perfectly fine with all 3rd-party requests blocked (via uMatrix) for me. So other than the CSS none of what you mentioned is necessary to get a readable article.

[Traubenfuchs]

How does something like that even happen? Did someone copy and paste lots and lots of stuff together to end up with this abomination?

[walshemj]

50 is quite low I was auditing a big uk ecommerce site at the weekend and the homepage had over 170 elements

[masklinn]

> 50 is quite low

50 could be "quite low" if most of the requests were for "content" images. TFA has under half a dozen images, as I've outlined in my comment most of the requests are for ancillary garbage.

> I was auditing a big uk ecommerce site at the weekend and the homepage had over 170 elements

See above, 170 is pretty high but assuming at least one image request per product[0] plus a few more for buttons & the like, having a large number of requests would be understandable for an ecommerce site.

ecommerce sites would also be a place where:

1. analytics is very, very understandable

2. the site would use a pretty generic system which could hinder specific optimisations

3. assuming the user will browse around, the site could preload various stuff, sacrificing some upfront performance for a nicer "inside" experience

All in all, I'd be much more understanding of that than 50 request on a blog post, even more so a blog post on software complexity. Incidentally, the amazon.com home page generates ~250 requests.

[0] because spriting for web pages remains a pain in the ass, doubly so for JPEG