CDNs are great, but shared asset CDNs like
https://cdn.jsdelivr.net/bootstrap.css can, surprisingly, be quite a bit slower than hosting that
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 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
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
jquery.js, you'll likely find some performance gains from self-hosting that file instead.