Avoid shared asset CDNs

CDNs are great, but shared asset CDNs can be slower than self-hosting that file instead. Visit today to find out why.

CDNs are great, but shared asset CDNs like https://code.jquery.com/jquery.js or https://cdn.jsdelivr.net/bootstrap.css can, surprisingly, be quite a bit slower than hosting that jquery.js or bootstrap.css file on your own domain.

When a browser requests a page on your site, it first makes a DNS/SSL connection to your domain. On your fast broadband connection, that could take around 150ms. On a slower connection with more latency, that could take more like 500ms.

But now the browser has established this connection to your domain, so it doesn't have to make that connection again when it tries to get other resources from your domain, like CSS or JavaScript files (although not for fonts, which I won't go into here, except to say that fonts behave differently and do require a new connection to be made).

But then here's what happens if you use a shared CDN to serve something like jQuery: the browser has to make a brand new DNS/SSL connection to ajax.googleapis.com, or cdn.jsdelivr.net, or whichever other shared CDN you're using. And here's what that looks like, using a WebPageTest waterfall chart:

That thin bar before jQuery starts downloading is the browser making a DNS/SSL connection to ajax.googleapis.com, and on this test run (on a fast 3G connection), that setup took a little over half a second.

But it's possible to avoid the setup cost by self-hosting that jQuery file instead, as you'll get to reuse the connection the browser has already made to your domain. Here's a video showing the difference between loading jQuery from Google's CDN, vs self-hosting that file (again, tested on a fast 3G connection):

Self-hosting jQuery led to rendering starting 367ms earlier, Largest Contentful Paint improving by 281ms, and the above-the-fold being visually complete more than a second sooner.

But doesn't self-hosting lose the caching benefit of a shared CDN?

For years we've been told that shared CDNs like this benefit the user because of caching. If a visitor lands on your page that loads jQuery from Google's CDN, and they've already visited another site that uses that same shared CDN to serve that same version of jQuery, then it'll already be in their cache and the browser won't have to download it again.

Except, that doesn't happen anymore.

Chrome introduced cache partitioning last year for privacy reasons, which means that - in the situation above - jQuery would be downloaded again, even if a visitor had a version of it in their cache.

And cache partitioning seems to have been in place in Safari from as early as 2013.

So if you're using a shared CDN to serve a static asset that's not going to change - something like bootstrap.css or jquery.js, you'll likely find some performance gains from self-hosting that file instead.

July 2021


Thanks for reading. If you found this interesting, you might also like Blackbird - site speed monitoring for ecommerce. Try it for free today.