CDNs are Awesome

Author: Stuart Maynes

tl;dr: Content Delivery Networks are great. You should use one.

The modern web is full of things like images, scripts, stylesheets. When you download a web page you’re not just downloading as web page,  you’re downloading a (potentially) huge group of other files to give you the immersive user-friendly experience that you’re now used to online. With broadband now ubiquitous, this isn’t much of an issue although the more you download to view a site, the longer it takes. This can have an immediate effect on the behaviour of your visitors. As a result of this, it makes sense to try to mitigate this as much as possible by speeding up download speeds for end users.

Content Delivery Networks (or CDNs) allow developers to serve these assets from supercharged servers with one job: deliver content to users fast.

Overview

Web servers are actually very simple. They work like this:

  1. URL is requested by a client. (Typed in a browser, or requested from a web page in the case of loading an image/script/stylesheet)
  2. Server finds requested resource.
  3. Server sends resource back. (serves it).

It’s that simple. 

Let’s try an example, substrakt.com.

When I type ‘substrakt.com’ in to the browser:

  1. A request goes off to our web server that says “Max wants to download the substrakt.com website”.
  2. The server says “Ok, here it is!”
  3. In that list, there’s a whole bunch of other files (pictures of our face, our office, the fonts we use, etc.) that our web server also needs to send back too.

This takes time and uses up resources of a relatively expensive web server. We want our web server busy doing tricky things like running database queries and processing PHP files, not wasting time with tiny jobs like sending images and stylesheets.

ENTER. THE CDN.

The CDN acts as a proxy between the user and our application server. It says “Use me to handle small jobs like requesting images and javascript files. I’ll decide when I need to bother the web server, not you. I’m also way cheaper.”

Without a CDN, here’s the layout of our server.

client-server

The server sends stuff directly to the client whenever it’s asked for. The server can be slow due to a multitude of reasons and even if it’s not, the server is in one physical location making it slower for anybody who’s geographically further away.

With the CDN, it’s slightly different:

cdn

As this (clear as mud) diagram shows, the CDN is now acting as a proxy between you and the web server. We don’t ask the server directly for any assets anymore. We query the CDN directly instead which aggressively caches assets and serves them from so-called ‘edge’ locations closest to the person who requested the result. This has the double-advantage of both meaning that sites load more quickly and it removes load from the main server which can get on with the important work of interpreting code and querying databases. Most CDN providers also charge on a pay-as-you-use system whereby the more assets served means the more it costs. This is unlike the standard model for charging for servers which have to remain on 24/7.

CDNs are designed specifically to serve content and to do it really quickly. That’s their one purpose. They’re no good at processing data, or number crunching, but they can serve an image from one side of the planet to the other in a fraction of a second.

We use a CDN for all of our projects as it helps us keep hosting costs down for our clients and results in happier users who have to wait less time to use our sites!