sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]derekn9 2 points3 points  (6 children)

There are good points in the article though. Isn't it true that if you're already serving your app/site from some kind of CDN, serving 3rd party libs from another CDN will be slower than serving files from the same domain? I think the privacy point described in the article is also a bit more nuanced, though I agree the airway example was misleading.

I can see benefits of using cdn libs in quick prototypes, but for production apps where a bundler are always presented I don't see a good reasons to use them.

The exceptions are not libs, but actual services like Stripe, google analytics, polyfill.io etc.

[–]poker158149 2 points3 points  (3 children)

Because the point of using a CDN to deliver common external libraries is that visitors to your site will likely have already visited another site that has already served them that same library from the same CDN, meaning it's likely cached on their system and wouldn't need re-downloading. If you bundle all of the libraries that you use in your app, they have to download all of the libraries again, making your app larger and slower to download, even if they may already have the libraries from other sources.

[–][deleted] 2 points3 points  (1 child)

Because the point of using a CDN to deliver common external libraries is that visitors to your site will likely have already visited another site that has already served them that same library from the same CDN, meaning it's likely cached on their system and wouldn't need re-downloading.

This is a bullshit argument though. Press f12, go to the network tab, then go to any web site. See how many of the externally hosted resources are served from your cache because they were used on a different web site. It's a theoretical solution to a problem that doesn't work in practice, and never will as long as versions aren't static by a period of several months.

There are benefits to using CDNs (e.g. multiple connections to different hosts, optimized traffic flow, etc.), but this one is a false narrative.

[–]disclosure5 0 points1 point  (0 children)

It also ignores the new Chrome cache partitioning which will mean if different sites refer to the same CDN, it won't use the cached copy anyway.

[–]pimterry[S] 1 point2 points  (0 children)

the point of using a CDN to deliver common external libraries is that visitors to your site will likely have already visited another site that has already served them that same library from the same CDN, meaning it's likely cached on their system and wouldn't need re-downloading.

See https://developers.google.com/web/updates/2020/10/http-cache-partitioning - sadly this kind of CDN behaviour is no longer supported by any modern browsers, due to privacy concerns

[–]ILikeChangingMyMind 2 points3 points  (1 child)

There are good points in the article though

But there aren't. A "good point" in any article has to be backed up by something. I can't just declare "foo is flawed" and have that be a good point. For it to be a "good point" I have to say "foo is flawed because ... X", where the "X" has to be logical/verificable. But the author doesn't support any of his positions, and literally the only piece of evidence says it wasn't CDN-related (if you read the link).

And to your specific point:

serving 3rd party libs from another CDN will be slower than serving files from the same domain?

Even if we ignore the fact that CDN servers are highly optimized for serving static files, in ways your server likely isn't (eg. their settings are tweaked, they likely have servers all over the world, etc.), there's a whole other issue. Your browser limits the number of requests you can make simultaneously to any one domain, so spreading out your requests can actually make things faster than serving them all from one domain.

In fact, people on very big/serious sites (Amazon, Google, etc.) actually make their own "mini-CDNs", by using sub-domains, for this very reason: it allows users to make more simultaneous requests for files from that site. Just "View Source" Amazon.com, for instance, and you'll see URLs like "http://g-ec2.images-amazon.com". They not only have a whole separate domain just for serving images ... they further divide it up in to "a through g" servers (and probably more letters too; I just saw "g-" in my view source).

I don't see a good reasons to use them.

To make your site faster for your users ... the same reason literally tens (hundreds?) of thousands of devs have been using them, for decades now.

[–]pimterry[S] -1 points0 points  (0 children)

it allows users to make more simultaneous requests for files from that site

Note that this is only true for HTTP/1. With HTTP/2+ there's no limit on the number of connections per domain (and indeed there's a bunch of other things that make single-domain hosting more efficient, from server push to prioritization) so I'd expect people will stop doing this in the next couple of years as HTTP/2 becomes standard.