How to improve your website performance with a CDN

Why you need a CDN

Using a CDN is one of the easiest and fastest ways to boost your website performance.

In order to see where the biggest peformance bootlenecks are, you can start by having a look at a waterfall graph of your website. The example above comes from b2evolution.net (before optimization). Any modern web browser will let you display this for you own site by using its developer menu/tools. When you do this for your site, just remember to clear your browser cache before measuring, otherwise your results won’t really show what your visitors experience.

The waterfall graph shows one line for each file that is downloaded to display your page. Here are the color codes used by Safari:

The blue line is the main PHP/HTML file;
The green lines are for CSS files;
The yellow lines are for Javascript files;
Finally the purple ones are for images.

Pay attention to 3 important aspects here:

There are usually more files than you think that need to be downloaded to display a single web page.
All files don’t start downloading right away.
Each file has a long Latency time and a comparatively short Actual Transfer time.

Let’s look at these 3 problems in order.

We have many files to download

One solution, of course, is to try to reduce the number of files. There are several ways to do this:

Change the design of your site – but that’s surely not what you want 🙁
Concatenate Javascript files – but that’s a bit complex if you’re using several libraries like jQuery and plugins…
Concatenate CSS files – same as above, plus it maks maintenance harder…

All those files can’t download simultaneously

There are two main reasons why all files can’t download simulatenously:

First, the browser doesn’t know about which CSS and JS files it needs to download before it receives the HTML page that references them. Note that it will start requesting CSS and JS files as soon as it sees them referenced in the <HEAD> section of your page. Then you may have a CSS file that includes another CSS file, which in turn uses an image as a background. All this cascade further delays the time where your browser knows it needs to get that background image. This explains that some Latency lines start later than others on the graph.
Second, the browser has a built-in mechanism to not overload a single webserver with too many simultaneous requests. Typically it will pause further requests once it already has 5 transfers in progress with a single server (a single fully qualified domain name to be exact).

You may optimize this process in two different ways:

Request all your files as soon as possible (a modern CMS like b2evolution does this for you). Note that on the graph above we only have analytics.js that starts later because analytics are not critical to the display of the page.
Request as many files as possible from a second (or even a third) server, different from your main server. This is easier than you may think. We’ll get back to this below.

Each of the files has a long latency time before it actually downloads

The latency is due to several factors:

Your browser first needs to resolve the IP address (through a DNS lookup) of the server it wants to talk to;
As explained above, if your browser already has too many requests in progress, it will wait before sending the additional requests. This may add big waiting times to your latency;
Once your browser sends a request to the server, it will actually take some time to travel the Internet before it gets there. This may take anywhere from 10 to 200 milliseconds (ms). This will be longer if the server you want to reach is on the other side of the planet or even longer if you’re using a mobile phone network, even if the server is in the same city as you are.
The server then needs to process the request. In case of a PHP request, there may be some heavy processing involved. This is where you want your CMS to be fast. And this is where you want your web host to be fast at executing PHP (or other) scripts. But in the case of static files like CSS, JS and images, there is no processing and the server will respond almost instantly (unless the server is so overloaded than even reading a file from disk takes a long time).
Then, the response must travel back to you. Here we have the same latency as in step 2, but this time on the way back to you. Count another 10 to 200 ms.
Once the first response byte arrives to your browser, we need to wait for the rest of the bytes to arrive. This is the Actual Transfer time. The time this will take depends on your bandwith and on the size of the file. But as you can see on the graph, the actual times are always shorter than the latency times (except for very large files like large images, or video, which we don’t have on this page).

The conlusion is that, provided you’ve optimized the size of your files, your website’s donwload time is not a file size or a bandwidth issue. The biggest component in your site’s performance is actually the latency issue.

So what can a CDN do about all this?

CDN means Content Delivery Network. It means that instead of using a single web server for delivering the files that make up your web site, you will use a network of servers. This sounds a bit crazy and complex, but it’s actually pretty easy to set up. We’ll get back to this in a second.

For now, just imagine that all your CSS, JS and image files have automagically been replicated on a network of servers all around the world. (These servers are called “Edge Nodes".)

Now, when someone visits your site, they will obtain several major benefits:

The requests will be routed to a server near them. This will dramatically cut down on the 10–200 ms latency that occurs twice. This alone may cut down latency by as much as going from 400 ms to 20 ms ! Just look at the first 2 green lines of the graph above. See how much less latency they have compared to the others. This is because those two CSS files (they are public webfonts) are actually already fetched from CDNs in this example.
If you split up your files over several different CDN zones or even several different CDNs, the 5 simltaneous downloads limit will be multiplied. This means there may be no more queueing and waiting when downloading many files for a page.
Finally, because the edge nodes are closer to the user, they may have better end-to-end bandwidth with that user, and even the actual transfer time will be reduced.

How to use a CDN

First of, you may already be using one without knowing it. For example: if you’re requesting some Javascript libraries like jQuery or Google Analytics from an external domain (not a file on your server). Those largely used scripts are already served through CDNs. Another frequent use of CDNs is the use of webfonts from an external domain. Here again you may already use the CDN of the font provider. (This is what happens for the first 2 CSS files in the graph above).

Doing this is typically very good for your performance on those specific files, but what about your own custom CSS, Javascript and images?

For your own files, you need to set up your own CDN.

You can do this very easily with MaxCDN for example.

How it works

The principle is simple:

You will define a “pull zone” which maps requests like http://yourzone.youraccount.netdna-cdn.com/some-folder/some-file.png to be equivalent to http://www.yourdomain.com/some-folder/some-file.png.
When a user’s browser requests http://yourzone.youraccount.netdna-cdn.com/some-folder/some-file.png, it is automatically routed to the closest edge node of the CDN network (thanks to some Internet magic called AnyCast).
If the edge node doesn’t have the file in cache yet, it will instantly fetch it from its source location http://yourzone.youraccount.netdna-cdn.com/some-folder/some-file.png. This will take a little extra time on the first request. But starting with the second request, this file can now be served instantly and extremely efficiently.

Now, of course, for this to work, your PHP or HTML pages need to reference http://yourzone.youraccount.netdna-cdn.com/some-folder/some-file.png instead of http://www.yourdomain.com/some-folder/some-file.png. Same for CSS and JS files of course.

Quick & Easy to set-up

If your website was a static site, you would have to change the CSS, JS and image URLs in your pages.

But, as you’re likely using a CMS to run your website, you can let it do all the work for you. You just need to tell it the URL of the CDN pull zone. MaxCDN’s homepage has a list of links to tutorials for setting this up in various CMSes.

(We’ll update this post shortly with instructions for b2evolution users. We’re curently working on streamlining the setup process as much as possible.)