Javascript CDNs: A Ticking Timebomb

Sorry for the mainstream media headline, but the truth hurts. Javascript CDNs are dangerous and want to harm your grandparents, your kids, and your little dog too. What do I mean by this? Well, let’s look at the advantages and disadvantages:


  1. Potential to sometimes make your website load slightly faster


  1. Potential to make your website take longer to load
  2. Potential to prevent your website from loading
  3. Complete reliance on external servers (single point of failure)
  4. Many popular CDNs do not use optimal cache control settings
  5. SSL introduces ethical issues

So let’s look at the first one. the CDN can make your script load faster. It can make it run slower. Consider the odds of the user already having the script. What do you think the chances are of that user having already specifically downloaded, for instance, jquery.min.js v1.7.2? It’s probably safe to assume less than 50% for the average user, right? So then we should all use jquery.latest right? Ha, no. NEVER trust the latest version of jQuery; I speak from firsthand experience. Also consider, if the user does NOT have that version of jQuery, it will have to connect to an external server, and thus will take longer to download than if it were local.

Second, the potential to break your website if the CDN doesn’t connect, or gets hacked. Don’t say “that’s Google’s server, it’ll never happen!” It can, and it does. It’s not a question of if it will happen, but when. And when it happens, a lot of websites are gonna go down for putting too much trust in the cloud. On top of that, some places have a ban on Google domains (such as some schools, workplaces, and entire countries). I’ve seen this happen in the past, and had to stop using CDNs in K-12 educational projects.

Third, reliance on external servers. You are introducing a single point of failure by using a CDN-hosted script. Luckily, there is a way around this; have a local fallback in place. However, this can introduce problems when trying to test your website locally.

Fourth, CDNs don’t generally cache like you think they would. You’d think they’d cache a solid version of jQuery for a week or month, since it’s highly unlikely it’ll change. As far as I can tell, they only cache for days or hours. Does this not defeat the purpose of a Javascript CDN? I think it does.

And finally, SSL. When someone connects to your website via SSL, they are entrusting you not to communicate their requests with remote servers. You are essentially breaking their trust by using a CDN. It may not be a big deal to me and you, but to some users it is.

I have to admit, I’ve been using Javascript CDNs blindly for years now, and only recently did I begin to question whether the effort was worth it. When you do the math, honestly it doesn’t look like it is. Are we really willing to put our eggs in other baskets to save 15kb? Does the potential savings in loading time have enough of an impact to positively affect the user? Are the odds in the user’s favor at all? Ask yourself these questions, and you might be surprised you’ve been living in the cloud computing matrix, and this stuff about CDNs making things faster is irresponsible marketing at best, dangerous at worst. Am I onto something, or am I just being an idiot?

Leave a Reply

Your email address will not be published. Required fields are marked *