Huh? Who ever said the main point of a CDN is to make things easier? It's always been in order to provide a faster end-user experience.
> ...but it's also not easy to say you're really improving the performance of something if there is any possibility you'll need to do an additional DNS lookup -- one of the greatest "long tails" in performance.
But common CDN's will virtually already have their IP address cached while you're browsing anyways.
Caching certainly has nuance to it as you say, but I think you're being particularly ungenerous in claiming that CDN's are a scam and that you're representing "reality".
Businesses measure these things in reality with analytics, and they also almost always analyze the worst 5% or 1% of requests as well, not just the "median".
CDN's are a big boost to performance in many cases. Or at least, until now (for shared files). You shouldn't be so dismissive.
Every byte sent will cost the business. If you can save that 2MB per user per cache life, you pay that much less on the internet bill for your hosting.
Every byte sent uses up some of your limited bandwidth while it is being sent. If your site is 10KB and you rely on 2MB of javascript libraries and fonts, offloading that 2MB is quite a significant reduction is resource usage.
These above two views seem vastly more important than terminal laziness, up-time management, etc.
Ah yes - I remember those _dark days_ of being a shared webhosting customer over a decade ago and stressing about breaking my 500GB/mo data transfer limit.
Today, Azure's outbound data costs on the order of $0.08/GB, so 1MB is $0.000078125, so the cost of 2MB of JS is $0.00015625.
Supposing you have one million new visitors every month (i.e. nothing's cached at their end so they'll download the full 2MB) - those one million visitors will cost you $156.25 in data-transfer.
Compare that to the immediate cost to the business of paying their SWEs and SREs to trim down the site's resources to a more realistic few-hundred-KB, supposing that's a good 2-3 week project for 3-4 people - assuming a W/Best Coast company, that's ( $250k / 52 ) * 3 * 4 == $57,000.
From looking at those numbers, there is absolutely no business case in optimizing web content - it's now significantly cheaper (on paper) to have a crappy UX and slow load-times than it is to fix it.
... then you're doin' it wrong.
100%. Its mind blowing that this could possibly be considered without batting an eyelid.
https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
Nobody seemed to think it was hard to host a file before this came along, just as nobody thought it was hard to have a blog before Medium.
Of course this creates the apocalyptic possibility that one of these servers could get hacked (later addressed with some signing) but it's also not easy to say you're really improving the performance of something if there is any possibility you'll need to do an additional DNS lookup -- one of the greatest "long tails" in performance. You might improve median performance, but people don't 'experience' median performance in most cases (it goes by too fast for them to actually experience it), they 'experience' the 5% of requests that are the 95% worst, and if they make 100 requests to do a task, 5 of them will go bad.
People are miseducated to think caching is always a slam dunk and sometimes it is but often it is more nuanced, something you see in CPU design where you might "build the best system you can that doesn't cache" (and doesn't have the complexity, power and transistor count from the cache -- like Atmel AVR8) to quite a bit of tradeoff when it comes to 'computing power' vs 'electrical power' and also multiple cores that see a consistent or not view of memory.