7 Reasons NOT to use a Content Delivery Network

While there are many compelling reasons to use a Content Delivery Networks (CDN) , you should consider the following situations before placing essential files on other domains… 1. Additional complexity A link to a CDN file won’t work if you’re developing offline. That’s rarely an issue, but some developers have temperamental internet connections or need to work on the move. You also likely to require a build process or manual intervention when deploying your site to a live server. It will be necessary to CDN-ize local links to JavaScript libraries and other assets. It could become complicated if you’re using a service such as Amazon S3 to host some resources but not others. 2. Files may not be optimized Consider a modular library such as Modernizr or YUI. Free CDN-hosted files are available but they generally provide all the common functionality within a large package that may exceed several hundred Kb. If you just require a few features, you can use your own specialized versions and merge all CSS and JavaScript files to invoke fewer HTTP requests. The result is smaller files which download quicker and execute faster — especially on mobile devices. That said, you could upload optimized files to a private CDN but you would need to consider the additional effort and cost that would incur. 3. There are no pre-caching guarantees While there’s a higher probability a popular CDN file has been pre-cached, it’s not a given. In particular, mobile devices tend to have small and fairly inefficient caches. The advantages may be negligible, especially if you can host a smaller file on your local server. 4. Blocked access We live in a world with geographic, legal, political, and commercial boundaries. It’s not uncommon for organizations or whole countries to block the domains or IP address of popular free CDN services. Similarly, companies such as Google and Microsoft must adhere with US export laws. There are known restrictions on use of data in Cuba, Iran, North Korea, Sudan and Syria. The list of blocked countries can change on the whim of any government. 5. Two points of failure It’s catastrophic when your site goes down and, despite a good reliability record, CDNs aren’t infallible. There’s little you can do but wait for the service to resume. It would be possible to use a CDN and fall-back to local files if the service isn’t available. It’s a solution which provides a good level of redundancy — at the expense of further development and complexity. 6. Security If security is a major concern, don’t use a public CDN. When a remote file is called, information about the referrer is also sent. Remotely-hosted JavaScript libraries are particularly risky since the code could be modified to collect data about your users or systems. Similarly, your CDN options will be more limited if you require HTTPS. 7. Loss of control Are you happy handing control of website files to Google, Microsoft, Amazon or any other large web company? Are you concerned they’re collating information about your website and systems? Do those companies have too much control over the net? Perhaps it’s paranoia, but you have a reason to be paranoid when everyone’s out to exploit you! If you’re feeling dizzy from all these pros and cons, come back soon for the final installment: Should You Use a Content Delivery Network?

Frequently Asked Questions (FAQs) about Content Delivery Networks (CDNs)