To be clear: CDNs are still highly useful. This is just about using them to host third-party libraries rather than serving them yourself.<p>It's worth noting that even a decade ago, using a CDN for third-party libraries often failed to produce the envisioned benefits. I tested this a far number of times and the cost of doing multiple additional DNS lookups, negotiating HTTPS, etc. was often higher than expected and the proliferation of versions meant that while it's true that the average browser hitting your site had a copy of jQuery in the cache it wasn't likely to be the same version from the same CDN.<p>Since HTTP/2 went mainstream half a decade ago, that's become an even harder competition to win since the browser can efficiently request a large number of files simultaneously without any of that setup overhead.<p>There's also a security concern: unless you use Sub-Resource Integrity (SRI) you're giving the CDN owner full control of your site and the users' data. That's not a catastrophic risk but it's probably more than a potential minor performance benefit is worth.<p>The last reason not to use them is increasingly the most important: if you include something large like many sites do, you probably have a ton of code which is going to have to be downloaded but isn't actually used by your site. A custom bundle (with tree-shaking, etc.) is going to save a substantial amount of transfer and it's usually the case that transferring less will overwhelm all other concerns.
CDNs are still useful if you (can/do) put everything on the same one. They’re just not useful to serve static dependencies off-site in hopes of users hitting a primed cache from another site, because of cache partitioning. That’s okay, that benefit was fairly limited anyway. You’re better off focusing on reducing page weight and optimizing loading (order, inlining critical resources, tree-shaking/code splitting, preloading to avoid waterfall, etc) anyway.
I have a large number of them blocked in my /etc/hosts file. My first experience with CDNs as an ordinary user was finding they were the source of a large amount of advertising and garbage I don't want to see.<p>Most of the web still works, though I sometimes run into odd things, like web pages where 1+Mb of cruft is delivered by the main host, but the 2Kb of text that I wanted to read was hosted on a blocked CDN. Ah, well. I'll find it somewhere else, then.
"Just read this and was a bit surprised."<p>I was surprised by something similar. We are in us-east-1 and standing up in us-east-2 as a backup. Now we're starting to stand up in us-west-2. So naturally, I asked why do us-east-2 if we need to do us-west-2 anyways for regulatory compliance? Latency. Ok... why not use CloudFront, Lambda@edge, etc? There's still unacceptable latency. I dropped it there, but really wanted to ask how that's possible and what the target latency is. Oh well, someone smarter than me must have already looked at it - back to the grind.
I believe back in the day CDN could also help with libs due to maximum number of connection to same domain; but with http2 this issue went away.<p>Still, localized content delivery is still needed even today, so CDN usage is still preferred. Unless your provider actually does CDN already, like github pages or something in those lines.
My knowledge of CDNs is limited but I assume that Moore's law will make CDNs obsolete because you will be able to efficiently and cheaply host your own data but then again webmasters will want to outsource it so they don't have to manage and maintain it.
I used to link to other assets that were served from a CDN, but have now opted for things like system fonts, instead of bulky webfonts served from a CDN and heavily optimize any images that I serve (greyscale GIF FTW) aswell as GZIP'ing everything.
tl;dr: There used to be a performance advantage when multiple sites loaded common resources from the same place, since it would often already be cached. But cross-domain caching could be used to violate your privacy, so browsers don't do it anymore, which nullifies that advantage.