4 ms·

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 i

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.
- zinekeller 5y ago
  > Make sure http2 is activated HTTP/2 suffers from Head-of-Line blocking, which may impede rather than help speed up the connection. In most cases, this doesn't happen, but when they do happen it's consistent. Testing is required, because there are cases where HTTP/2 backfires spectacularly. > That assets that never change are cached Fair point, I also strongly recommend this. Plus, if your server supports statically compressing resources ahead of time it pays serious dividends (and activating Brotli, if you can custom compile applications or lucky to use a distribution that built it). > And if possible use a hosting provider in the same country your users are located. In Europe, this is relatively easy. In the US and Russia, probably two servers (for East and West coast/okrugs). In Asia? Surprisingly difficult, unless you're in East Asia (I'm not discussing why here since there's plenty of resources to learn more about why it's a pain in the rear). Africa? Actually, despite improvements in connectivity I strongly recommend to make the pages small and simple (as the requirements allow).

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.

zinekeller 5y ago
> Make sure http2 is activated HTTP/2 suffers from Head-of-Line blocking, which may impede rather than help speed up the connection. In most cases, this doesn't happen, but when they do happen it's consistent. Testing is required, because there are cases where HTTP/2 backfires spectacularly. > That assets that never change are cached Fair point, I also strongly recommend this. Plus, if your server supports statically compressing resources ahead of time it pays serious dividends (and activating Brotli, if you can custom compile applications or lucky to use a distribution that built it). > And if possible use a hosting provider in the same country your users are located. In Europe, this is relatively easy. In the US and Russia, probably two servers (for East and West coast/okrugs). In Asia? Surprisingly difficult, unless you're in East Asia (I'm not discussing why here since there's plenty of resources to learn more about why it's a pain in the rear). Africa? Actually, despite improvements in connectivity I strongly recommend to make the pages small and simple (as the requirements allow).