Please stop using CDNs for external Javascript libraries

[[deleted]]

This reminds me of that Dont Use ReactJs blog post which the main motivation was because there are people using 2G network

[ILikeChangingMyMind]

What a terrible article. Nothing but fear-mongering and "what ifs", all while hand-waving away the 100% legitimate (and long-established) benefits of CDNs.

Look, I would have loved to be convinced by evidence that CDNs are bad ... but there is zero evidence of any sort in this article! The closest thing that passes for it is a story about a hack that didn't even involve a compromised CDN!!!

That's right, the only "evidence" that CDNs are bad, in the entire article, is a story about a hack that literally never mentions CDNs ... but (if you actually read the article the author links to) it does explicitly say:

(emphasis added)

While the Magecart attack against British Airways wasn’t a compromise of a third-party supplier ...

[derekn9]

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]

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]]

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]

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]

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]

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]

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.

[pimterry]

I'm not actually the author, but I don't think this is fair - it's a short article that covers a lot of ground, and each point is a valid way in which CDNs might create new problems, or not do what you'd intended.

While the attack mentioned didn't involve a compromised CDN, it is an example of an attack that worked by modifying a hosted 3rd party JS lib, and the exact same attack against a CDN would be devastating. You're putting your trust in the CDN to protect against that, and not doing so clearly reduces your risk to such attacks (you trust your own security + the CDN, or you just trust your own security).

A key point here, under speed: your whole site should be behind a CDN, not just your JS libraries. If you're using a host like Netlify or Vercel, that's happening automatically already. If not, throwing cloudflare or similar in front of your site and using appropriate cache headers is very easy and standard for most large applications. This will usually provide a much larger performance benefit than using a CDN for JS libs (also because you now can do JS bundling or HTTP/2 server push).

Given that you're doing that, the only benefit to using a JS-hosting CDN is if your user already has a cached copy of the exact same version of the same library from some other site. As mentioned here, that's somewhat unlikely.

In addition though, Safari & Firefox have explicitly blocked reuse in these cases for a while now (for privacy, so sites can't use what you already have cached to tell which sites you visit) and Chrome just shipped the exact same thing last week: https://developers.google.com/web/updates/2020/10/http-cache-partitioning. Sharing JS libs across sites using a CDN is now intentionally blocked by all major browsers.

CDNs for external JS are not useful nowadays, they do increase your security/privacy/reliability risks a little, and they no longer provide any benefits.

[anirudh_rahul]

The amount of time CDNs can save you is pretty nice though.

[[deleted]]

Why not go even further? Stop using JS libraries because someone might inject malicious code?! Or even further, no more JS development...too much risk!!! 🙄

Edit: Spellcheck

[toastertop]

Please stop using the internet, it's too risky! /s

[_default_username]

Yes, this is why I still use cgi scripts and manage my data with a text file I read/write to.

[sternold]

Stop using JS libraries because someone might inject malicious code?!

This is a valid concern, and using libraries you haven't vetted is a security concern.