To be clear: CDNs are still highly useful. This is just about using them to host third-party libraries rather than serving them yourself.
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.
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.
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.
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.
> It's worth noting that even a decade ago, using a CDN for third-party libraries often failed to produce the envisioned benefits.
This always seemed like a lot of hopeful mythology. As you said, there were so many versions, and then if you start combining the modules, and the various public CDNs, it becomes a combinatorics problem that you can only when if the browser cache is enormous. But even a pretty large browser cache becomes pretty small when auto-play video is a thing and 2mb seems small for a landing page.
CDNs are certainly useful, if you can serve your content from closer to the user, that reduces latency which also increases potential bandwidth early in a connection. It's often helpful to serve content through a CDN, even if it's not cached, as reducing the latency makes a big difference (and the edge <-> origin connections can often be longer lived so that latency has less of an effect on the bandwidth available)
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.
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.
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.
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.
Not to be rude, but you never understood how CDNs we're helpful, then, because they were about round trips and latency, which Moore's law does not help with. The point of cdms was to reduce the number of distinct resource objects that your browser requested, and that will continue to be good advice in many situations.
I said that my knowledge of CDNs is limited but yea I understand that CDN is similar to edge computing. My logic was Moore's law will make everything so cheap that CDNs wouldn't be as needed as they use to be.
>The point of cdns was to reduce the number of distinct resource objects that your browser requested, and that will continue to be good advice in many situations.
In the world of optimized software and computational power abundance(both CPU and bandwidth) this shouldn't be a problem.
You're still thinking about this wrong. This is not about bandwidth or CPU time - It's about the time it takes to communicate. Moore's law will make running a CDN cheaper, but it won't make sending a request across the globe any faster.
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.
But that's not the main point of CDNs, their main advantage is to off-load resource requests to servers close to the user and avoiding serving huge amounts of static data from your own server. They also offer numerous other advantages (DDOS protection, hiding your server IP, etc.), but also come at a privacy cost and risk of data centralization (a good % of internet traffic goes through Cloudflare for example).
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.
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.
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.
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.