Public CDN's aren't useful anymore

As of 2019, CDN's like won't make your site faster

Written by Rico Sta. Cruz
(@rstacruz) · 1 Apr 2022

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.

What changed?

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:

About public CDN’s

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=""></script>
Google has been running a CDN serving popular JavaScript libraries. (via Google Developers)

Other issues with public CDN’s

  • 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.

Hey! I write articles about web development and productivity. If you'd like to support me, subscribe to the email list so you don't miss out on updates.

Are public CDN’s still useful?

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.

What do we do now?

  • 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.

Written by Rico Sta. Cruz

I am a web developer helping make the world a better place through JavaScript, Ruby, and UI design. I write articles like these often. If you'd like to stay in touch, subscribe to my list.


More articles

← More articles