- Potential to sometimes make your website load slightly faster
- Potential to make your website take longer to load
- Potential to prevent your website from loading
- Complete reliance on external servers (single point of failure)
- Many popular CDNs do not use optimal cache control settings
- 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.
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.