[hhsnopek]

The only issue with going against the grain here if you're not putting your site itself behind a cdn. It'll vary in download rates across the global. This was the intended use case for CDNs, but analytics are added so CDNs can improve.

You're correct with the fact that they are tracking us, but there's a trade off that comes with this that holds tremendous value. If that value of speed isn't a factor or low on your list of priorities then by all means, sever everything.

[korethr]

I think this is a false choice. If CDNs were simply caching the content in various geographic regions to keep the data closer to the users, and thus loading quickly, then that'd be fine. But in my observation, that's not what they've become.

It seems that increasingly more often, I have to enable javascript from numerous third party sites just to get some or all of the supposed first party content of the page to even render at all. And then all this extra JS ends up slowing my browser down, IMO, cancelling any improvement in load time from having a geographically close cache. Then there's other annoyances, like the alignment of the text, pictures, and other content suddenly shifting about, because the font has changed, or the JS from one CDN finally finished processing and decided that, no, actually, pictures should go over there.

My needs and wants from a page are rather simple. Render your content, then kindly get out of my way and let me take in the message you are trying to communicate to me. Attempting to import distracting fanciness from CDNs is more likely to cause me to skip your site than an extra 100ms of load time because I'm in Germany and you're in Canada.

On an unrelated note, it looks like I might be taken by another archive binge here soon.

[hhsnopek]

Sadly a lot of people don't use the `async` attribute for script tags. We can still load fonts over CDNs, even using Cloudfront or Cloudflare for caching.

> Then there's other annoyances, like the alignment of the text, pictures, and other content suddenly shifting about, because the font has changed, or the JS from one CDN finally finished processing and decided that, no, actually, pictures should go over there.

This is because the scripts and css are so large that it takes time for the browser to render all the rules set by that site. This can easily be optimized with the right tools or throwing out dead code, even only fetching code specific to that web page. Most developers just `script` tags into their head as well and this _kills_ loading of pages more than anything (unless your css file is thousands of lines).

CDNs are meant for distributing across the globe, you're hosting your own assets without a CDN in the middle and the site is still slow, you're optimizing in the wrong place.

[mattmanser]

There are particular circumstances you can actually use 'async' though. Load order is usually important.

[creshal]

You don't need inject third-party Javascript files into your website to geo distribute a few font files. You can still put them on something like S3 and let the hoster figure out the shortest path.

[dexterdog]

That would have to be S3 with Cloudfront which is the only way to easily have custom domain SSL since S3 is not CDN'ed or cached.

[ehnto]

The latency issue is only present once, the initial page load. After that the resources are cached. Second to that, if you're following best practices for page speed, the user will not notice at all because a snippet of CSS that provides the initial layout and styles will be sent with the HTML body. Amongst dozens of other things you can do to make this a non-issue.

[enraged_camel]

>>The latency issue is only present once, the initial page load.

The initial page load is also one of the most important things to optimize for things like, you know, conversion of visitors to paying customers. I've given up on subscribing to new products and services simply because their pages weren't performing well, and I'm sure many others here have done the same.

[ams6110]

I've given up subscribing because pages don't work (as in don't render anything at all) with JS disabled.

[leeoniya]

i've given up subscribing because pages look like shit in telnet:80

:D

[nkozyra]

Cached per browser, though, which is significantly different than cached per request.

Even if you're caching/serving static content efficiently it still adds load to a server.

[minxomat]

Not download rates, but request times are important for a website. Of course, if your uplink is exceptionally bad, the former matters somewhat, too.

Usually, one would amalgamate the resources to avoid additional requests to any server at all (CDN or not, all requests have unnecessary overhead). Many Web CDNs include frameworks that combine CSS, JS etc. resources to speed up page loading. Add to that SVG inlining and image optimization and you're good speedwise.

What you still miss the the geo-targeting of an Anycast network like CF et al. This will slow down the initial resource request again.

The question is: If you knew that you could live without the aforementioned pros of a CDN, why use it in the first place...

[majewsky]

> Many Web CDNs include frameworks that combine CSS, JS etc. resources to speed up page loading. Add to that SVG inlining and image optimization and you're good speedwise.

I thought that's what HTTP/2 was for? I'd rather solve this at the connection level than have some third party amalgamate my content and thus silently break it in maybe 5% of cases.

[OJFord]

    > It'll vary in download rates across the global [sic].

Sure, but we're talking on the order of ~KBs, so many HTML pages are going to be bigger than font and CSS files, and seeing as the author is providing a webcomic, all those images certainly will be.

Nobody's CDN-ing CSS for latency when the rest of their assets are served from a single location. As the author says, it's just "laziness" (or 'ease of development').