Public CDN's aren't useful anymore

Public CDN’s were supposed to help page speed, but things have changed in 2019. Services like Google Fonts, Cloudflare’s cdnjs, jsDelivr and Google Hosted Libraries may not help make sites load faster as much as it used to.

Today, the primary advantage of public CDN’s is no longer supported by modern browsers.

Resources (like .js files) loaded by a site the user visits will no longer be cached for other sites they visit. Browsers have stopped having shared caches around Sep 2019 (Chrome 77, Firefox). This has all been done to address a cross-site leak security issue reported on March 2019:

CDN’s were supposed to help sites load faster. For example, a popular library like jQuery can be loaded from a CDN by one site, making it load faster for other sites the user will visit who would use the same CDN.

<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>

• Downtime. Security concerns aren’t the only downsides to public CDN’s. Downtime in public CDN’s will impact the service of your site. Compare this to something like npm or Rubygems where downtime will affect builds and deploys, but not users.

• Blocked in some regions. There are countries that block Google domains, which will impair your site if it loads critical assets from Google Fonts or Google Hosted Libraries.

• Resource integrity issues. In the event of a compromised public CDN, malicious code can be inserted into your site. This can be mitigated using Subresource Integrity (SRI), but maintaining these can be a hassle.

While public CDN’s have been heavily nerfed, some have found it to be useful for other reasons.

• Code examples. Using Google Fonts can be useful in code examples. There are even CDN’s like skypack that will create optimised versions of npm packages, allowing code examples to skip having build & compile pipelines.

• Simplifying build pipelines. Tools like Rails’s import-map recommend using a CDN like jspm to outsource to build step needed by some npm packages. Personally I find this questionable for security reasons, but some prefer to trade security for convenience.

• Sidestepping max connections? Browsers limit HTTP requests to 6 connections per domain, so having some assets served in a different domain can potentially have some advantages. In practice however, HTTP/1.1 pipelining and HTTP/2.0 Multiplexing should already allow browsers to make multiple concurrent requests.

• Self-host your JavaScript. For production builds, self-hosting seems to be a much better alternative to using CDN’s. There are many options today for self-hosting npm packages.

• Self-host your fonts. Fontsource is an easy way to self-host Google Fonts (and more) without having to manually manage font files.

• Use a CDN. Not a public CDN, but CDN services like Cloudflare and Fastly can make pages load fast (less than 100ms!). This will make self-hosting very viable.

• Enable HTTP/2. It’s a great idea to support HTTP/2.0 across all steps in web hosting infrastructure. Cloudflare, for example, allows enabling HTTP/2 support in their cache proxy service.

• How to Adapt to Shared Cache Going Away | Section
• Shared Cache is Going Away
• Shared Cache Is Going Away | Hacker News
• sirdarckcat: HTTP Cache Cross-Site Leaks