Blogs

Should You Use a Content Delivery Network?

Craig Buckler
Share

If you’ve been following my recent posts, 7 Reasons to use a Content Delivery Network and 7 Reasons NOT to use a Content Delivery Network, you’ll be utterly confused and on the brink of giving up this web game altogether.

The answer to “should I use a CDN?” is…
it depends.

There are a few clear-cut situations when a CDN should be avoided:

  1. You’re building an intranet application without external access to the internet.
  2. Security or privacy is a top priority, e.g. a banking application where you need full control over all source files and server locations.
  3. You’re building an application for a company or country which is known to block specific domains or IP address ranges.

Your choice of CDN will also be more limited if your application requires the secure HTTPS protocol.

CDNs bring fewer benefits to smaller sites with relatively light traffic. Assuming you don’t require high-bandwidth video or audio files, it may be simpler to keep all your files in one place.

Small Local vs Large CDN Files

For busier sites, CDNs can significantly boost performance and save costs. However, be conscious of file optimization issues. For example, is it better to load a full 300Kb JavaScript library from a CDN or an optimized 50Kb version from the local server?

I’d be tempted to pick the smaller local file — especially if a reasonable proportion of the target audience are using mobile devices. A smaller file outweighs many of the reasons to use a CDN; it will download quicker and execute faster.

A/B Performance Testing

If time and budget permits, you could consider A/B testing. You’d need to implement a solution which served individual users with a CDN-powered or locally-hosted version of a web page. A snippet of JavaScript could record real download and rendering speeds and post results back to the server using Ajax or similar methods. Depending on your traffic profiles, you may be able to simplify this process by running a local version for one week then a CDN-powered version the next.

A CDN may be less efficient if, for example, the majority of users are on slower connections and are physically close to your main server’s location.

The Best of Both Worlds?

Several of the problems associated with CDNs can be rectified using a fall-back. If a file cannot be downloaded because the CDN is blocked or unavailable, the system can resort to a local version. Again, this requires more development but would increase availability on mission-critical systems.

CDNs and Progressive Enhancement

There will always be resources which not absolutely essential for the page, e.g. background images, JavaScript widgets, some CSS resets, etc.

Consider web fonts. Google’s webfont CDN is a great system and you’ll encounter few problems if the service becomes unreliable or fails. If the font can’t be loaded, the site can fall-back to a common typeface.

Wrapping up

CDNs are an incredibly useful resource but remember to consider the consequences. In practice, most sites will benefit if they load jQuery, the HTML5 shim and font files from a public CDN. For busier sites, the speed improvements and cost savings of a private CDN are hard to ignore.