Hacker News new | ask | show | jobs
by jetheredge 3064 days ago
Author here... yeah, we are loading a lot of crap, aren't we? We will do an audit and make sure we aren't loading a bunch of unnecessary stuff, but the whole site should be served up through a CDN, sorry it is loading slow for you.
2 comments

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?

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.
How does something like that even happen? Did someone copy and paste lots and lots of stuff together to end up with this abomination?
50 is quite low I was auditing a big uk ecommerce site at the weekend and the homepage had over 170 elements
> 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