DEV Community

Rico Sta. Cruz
Rico Sta. Cruz

Posted on

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

Shared caches don’t work anymore

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>

Enter fullscreen mode Exit fullscreen mode

☝Google has been running a CDN serving popular JavaScript libraries. (via Google)

Other issues with public CDN's

📉 Downtime — Downtime in Public CDN’s will impair 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) (ie, <script src="..." integrity="(sha384_hash_here)">) but maintaining these can be a hassle.

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?

For production builds, self-hosting seems to be a much better alternative to using CDN’s.

💡 Self-hosted JavaScript — There are many options today for self-hosting npm packages.

💅 Self-hosted fontsFontsource 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 (<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.


Top comments (1)