5 ms·

There is probably no good reason to use such CDNs nowadays: 1) The biggest benefit of using cdn was that scripts stylesheets were often loaded from cache. This

There is probably no good reason to use such CDNs nowadays: 1) The biggest benefit of using cdn was that scripts stylesheets were often loaded from cache. This is no longer the case anymore. 2) It's adding an unnecessary vulnerability as seen from this case. 3) CDN scripts can be (possibly) used to track your website traffic. 4) They often drop third party cookies which decreases your website load speed among other things. It's best to just host your script on Digital ocean spaces or S3 and use a Cloudfront proxy.

cryptonym 5y ago
CDN can protect your servers from DDOS and countless attacks, bots, vulnerabilities. It tends to be patched pretty quickly when there is an issue. It can reduce cost by offloading, improve performance by distributing content (with or without computing) from a closer location, optimise delivery in many ways, scale with limited cost... Extra cookies and scripts are related to specific features. A good CDN will let you configure exactly what you want. Cloudfront is a CDN. EDIT: The issue is more related to using a third party domain in order to load assets on you website. I agree, that should be done from first party when possible.
- judge2020 5y ago
  Yes, I think OP meant “cdnjs” when he was talking about CDNs, not reverse proxies like Cloudflare, Cloudfront or Akamai.
- hansel_der 5y ago
  i think op was referring to the practice of using a separate cdn for specific resources (like fonts and scripts), not using a cdn per se.
tobr 5y ago
It’s often the lowest-friction way to include a library in a project. You’ll often see “getting started“ documentation using cdnjs.com because it’s so easy. That’s not a good reason, but probably a very real one.
torgard 5y ago
> Cloudfront proxy I mean, CloudFront is a CDN too. EDIT: Oh, I misread. You weren't dismissing CDNs entirely. Only this type of CDNs. In that, I agree.
zinekeller 5y ago
Some rebuttals: > 1) The biggest benefit of using cdn was that scripts stylesheets were often loaded from cache. This is no longer the case anymore. This is indeed true. However, most websites (despite the relative ease of activating a CDN service) only host their website in a single location. In those cases, library CDNs (to differentiate from other uses of CDNs) can still benefit the website, even when you consider optimisation strategies such as HTTP/2. Additionally, the stress on their servers are decreased because it's handled by their library CDN provider. > 2) It's adding an unnecessary vulnerability as seen from this case. > 3) CDN scripts can be (possibly) used to track your website traffic. Good points and something that I can't rebut easily. It is indeed on the onus of the website to check the reputation of library CDNs, and it may violate privacy guarantees (you're trusting Google/CloudFlare/Microsoft/Amazon/Fastly/MaxCDN etc.) Specifically on 2) however, they knew that they are large: the speed of fixes (as shown) here proves that library CDNs can benefit websites' security, which tends that its software stack is updated slower (by the website operator's fault). You can also leverage subresource integrity (https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...) to fail hard. > 4) They often drop third party cookies which decreases your website load speed among other things. Citation needed here. As far as I checked (and just verified as I post this, to ensure that this is still true), every library CDNs I knew (even in weird places such as Japan- and China-centric library CDNs) do not place cookies in the library URLs themselves (some do on their websites themselves, but it is usually separated by domain names). > It's best to just host your script on Digital ocean spaces or S3 and use a Cloudfront proxy. If you're a large website or basically need to ensure the privacy is guaranteed, sure! I see that large websites do in fact use their own choice of CDN providers (most websites including Amazon themselves uses Fastly though). Some even do a step-up: some websites (for example) use Fastly for their American traffic, KeyCDN for European traffic and Quantil for Asian traffic. However, I only knew of two CDN providers which provides a flat-rate and reasonable costs: CloudFlare (uhh, CDNJS operator) and DDOS-Guard (which some consider shady).
- z3t4 5y ago
  A CDN is really only useful if you store your entire website with all it's content on it. Or if you serve a lot of data (petabyte egress) where the CDN have better peering deals for lower bandwidth cost. If you operate a "normal" static website, make sure http2 is activated, and that assets that never change are cached. And if possible use a hosting provider in the same country your users are located.
johne20 5y ago
We have ran with s3 origin and a CDN for our static files for years. It has been super solid, almost zero downtime. One thing that has become an issue, is s3 doesn't let add custom headers, eg. CSP, CORP etc. We are considering firebase hosting or our own origins behind a CDN for more control over headers. Anyone have any other suggestions?
- dubcanada 5y ago
  Cloudfront with a lambda setup can add all the custom headers you want.
- twistedpair 5y ago
  I'd suggest GCS+Cloud CDN or S3+CloudFront. I've been running several sites off Firebase Hosting the last 4 years and have seen surprisingly high downtime, cache clearing errors, and unexplained 502 errors from Firebase Hosting.

cryptonym 5y ago

CDN can protect your servers from DDOS and countless attacks, bots, vulnerabilities. It tends to be patched pretty quickly when there is an issue. It can reduce cost by offloading, improve performance by distributing content (with or without computing) from a closer location, optimise delivery in many ways, scale with limited cost... Extra cookies and scripts are related to specific features. A good CDN will let you configure exactly what you want. Cloudfront is a CDN. EDIT: The issue is more related to using a third party domain in order to load assets on you website. I agree, that should be done from first party when possible.

judge2020 5y ago
Yes, I think OP meant “cdnjs” when he was talking about CDNs, not reverse proxies like Cloudflare, Cloudfront or Akamai.
hansel_der 5y ago
i think op was referring to the practice of using a separate cdn for specific resources (like fonts and scripts), not using a cdn per se.

tobr 5y ago

It’s often the lowest-friction way to include a library in a project. You’ll often see “getting started“ documentation using cdnjs.com because it’s so easy. That’s not a good reason, but probably a very real one.

torgard 5y ago

> Cloudfront proxy I mean, CloudFront is a CDN too. EDIT: Oh, I misread. You weren't dismissing CDNs entirely. Only this type of CDNs. In that, I agree.

zinekeller 5y ago

Some rebuttals: > 1) The biggest benefit of using cdn was that scripts stylesheets were often loaded from cache. This is no longer the case anymore. This is indeed true. However, most websites (despite the relative ease of activating a CDN service) only host their website in a single location. In those cases, library CDNs (to differentiate from other uses of CDNs) can still benefit the website, even when you consider optimisation strategies such as HTTP/2. Additionally, the stress on their servers are decreased because it's handled by their library CDN provider. > 2) It's adding an unnecessary vulnerability as seen from this case. > 3) CDN scripts can be (possibly) used to track your website traffic. Good points and something that I can't rebut easily. It is indeed on the onus of the website to check the reputation of library CDNs, and it may violate privacy guarantees (you're trusting Google/CloudFlare/Microsoft/Amazon/Fastly/MaxCDN etc.) Specifically on 2) however, they knew that they are large: the speed of fixes (as shown) here proves that library CDNs can benefit websites' security, which tends that its software stack is updated slower (by the website operator's fault). You can also leverage subresource integrity (https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...) to fail hard. > 4) They often drop third party cookies which decreases your website load speed among other things. Citation needed here. As far as I checked (and just verified as I post this, to ensure that this is still true), every library CDNs I knew (even in weird places such as Japan- and China-centric library CDNs) do not place cookies in the library URLs themselves (some do on their websites themselves, but it is usually separated by domain names). > It's best to just host your script on Digital ocean spaces or S3 and use a Cloudfront proxy. If you're a large website or basically need to ensure the privacy is guaranteed, sure! I see that large websites do in fact use their own choice of CDN providers (most websites including Amazon themselves uses Fastly though). Some even do a step-up: some websites (for example) use Fastly for their American traffic, KeyCDN for European traffic and Quantil for Asian traffic. However, I only knew of two CDN providers which provides a flat-rate and reasonable costs: CloudFlare (uhh, CDNJS operator) and DDOS-Guard (which some consider shady).

z3t4 5y ago
A CDN is really only useful if you store your entire website with all it's content on it. Or if you serve a lot of data (petabyte egress) where the CDN have better peering deals for lower bandwidth cost. If you operate a "normal" static website, make sure http2 is activated, and that assets that never change are cached. And if possible use a hosting provider in the same country your users are located.

johne20 5y ago

We have ran with s3 origin and a CDN for our static files for years. It has been super solid, almost zero downtime. One thing that has become an issue, is s3 doesn't let add custom headers, eg. CSP, CORP etc. We are considering firebase hosting or our own origins behind a CDN for more control over headers. Anyone have any other suggestions?

dubcanada 5y ago
Cloudfront with a lambda setup can add all the custom headers you want.
twistedpair 5y ago
I'd suggest GCS+Cloud CDN or S3+CloudFront. I've been running several sites off Firebase Hosting the last 4 years and have seen surprisingly high downtime, cache clearing errors, and unexplained 502 errors from Firebase Hosting.