That idea of having JS files hosted elsewhere always struck me as a Girardian scam (e.g. "everybody else does it") and always getting voted down when I showed people the reality factor.
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.
> 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.
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.
This. If you are loading some scripts that are actually required for your app or page to work right, why would you get them from someone else's infrastructure? Terminal laziness? Or is the assumption that XYZ corp has more incentive than you do to keep your page working? This never made much sense to me except for developer toys & tutorials.
It makes sense from a $$ and resource usage stand point. I have to assume the best here and believe that the people arguing on there being no merit to CDN hosting of shared libraries all forgetting the two most important things a business must consider.
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.
> If you can save that 2MB per user per cache life, you pay that much less on the internet bill for your hosting
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.
In case the hash is provided, caching across websites could be turned on again, to avoid the possibility of it being used as a supercookie. The website would have to know the hash of the supercookie before loading the resource. Except if a candidate set of possible users can reasonably be downloaded to the client, maybe sorted by time of last access and proximity to the geo location of the IP address of the last access...
We at some point, we where retrieving some javascript (jQuery) and fonts dependencies from a CDN. At the end, we need that change and include all in out web application as we saw all kind of problems... Like that someone trying to use behind a intranet or not working fine when it's accessed a develop version behind a weird VPN. Or that funny moment when a CDN get down and simultaneously a lot of our webs get half broken.
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.