CDN's Aren't as Useful Anymore?
https://gomakethings.com/cdn-caching-isnt-the-performance-boost-it-used-to-be/
Just read this and was a bit surprised.
Just read this and was a bit surprised.
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.
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)
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.
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.
>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.