RevaHealth.com Blog

Time matters, and when it comes to the online world nowhere does it matter as much as with page render times. We have found a direct correlation between render times and bounce rates, so there is a real commercial need to get our page load times down. One of the problems that we face is the physical distance some of our users are, Australians say, from our server, and the time it takes for our page to be downloaded by their browser.

Now packets travelling down fibre and copper are fast. The problem is that while they’re fast they aren’t instantaneous. Even with infinite bandwidth it takes a measurable amount of time to request a file and get it back to your browser.

The problem only gets worse the further your server is from the user. If, say, the majority of your users are in London then you can potentially minimise the issue by putting your server somewhere physically nearby, in the UK at least. This will give you a round trip delay (latency) of about 30 milliseconds. However, if your server is a continent away the delay is more likely to be 200ms, and if it’s on the other side of the world it going to be about 350ms.

Now 200ms or even 300ms does seem like a lot of be worrying about in the context of a 4 second page load time, and it wouldn’t be if the browser only had to suffer this delay once. The problem is that browsers can typically only download a certain number of files simultaneously.

For example, if a web page has 30 files to download, then the browser could be forced to wait 200ms more than once and maybe as many as six times. This can add nearly a second and a half onto the page load time. In reality it is even worse that than that as each packet must be acknowledged. So not only is there latency with each file, the time to actually transfer the file is also increased as well.

As is the case of most web business, RevaHealth.com was global from day one. No matter where we place our servers, they are going to be physically remote from a large number of our users. We have historically addressed this problem by reducing the number of files on our page. However, there is only so far this can go and we have now run into hard limits. If we want to reduce our page render time further we just have to face this latency problem head on.

So what’s the answer?

Content Delivery Networks are the answer. Let me explain why they are so useful and what impact they have had on our own build process. There are three distinct advantages to using a CDN for your static content:

1. Reduction in latency and therefore improved page load and rendering
2. Increasing the number of domains where the page’s dependant files are called from increases the number of files that can be simultaneously download. This improves page load and render times.
3. It removes the overhead of serving these static files from your own server, improving efficiency.

A CDN is a network of servers throughout the world that puts your content physically closer to your users, thus enabling the lowest latency possible. In order to use one you need to change your build process so that your static files are uploaded to and called from the CDN rather than from your own server.

Here’s what you need to do:

• Create new CNAMES in your DNS records for your static files. Each CNAME will correspond to a bucket on the CDN where you store files. It is a good idea to create enough buckets so that there will be no more than 4 files in each bucket. For example, create css.example.com for CSS files and js.example.com for JavaScript files. This will maximise the number of files that the browser can download simultaneously. You don’t need to worry about which CDN servers are closest to the user; the CDN’s DNS will automatically resolve the CNAME to the closest server.
• Change all of your references to static files to the corresponding address on the CDN. For example, your CSS file will now be referenced as css.example.com/style.css
• Upload your static files to the CDN

Unfortunately it does get a little bit more complicated than that. The problem is that the servers at the edge of the CDN are designed to deliver files as quickly as possible so they don’t check with the central server to see if the file has changed. This means that if you change any of your static files, in your next build the user will still be downloading the old version of the file.

Here’s Why
When the first user downloads the HTML for your page, the HTML references the CDN for static files. DNS then automatically resolves the CDN CNAMES to the nearest server in the CDN. However this server does not yet have the files it needs, so it requests them from the central server and then serves them up to the user. In this instance the user sees little or no improvement in page render time when compared to downloading everything directly off of your own servers.

The benefits come when subsequent users in the same geography visit your site. Exactly the same process is repeated, except that now the edge server does not need to ask the central server for the files, as they have them locally.

The problem with this system is that when you change the files on the central server, the edge servers don’t know about them and they keep serving up the old files, typically breaking your site.

How a Content Delivery Network works

What to do about it

To get around this problem you need to implement a build process that iteratively changes all the static file names and the references to them. Now when a user downloads a new version of your page it will reference files that the edge server does not have locally, forcing it to get the new files from the central CDN.

So What about the Results?

We had already put in a lot of effort in optimizing our page render time and it was down to 4 seconds for our average user (4,000 KM from server). Implimenting the CDN dropped this down to 3.5 seconds. While a half second improvement hardly seems worth it when you get to these kind of time even a small improvement can significantly improve the user experience and we are seeing a probable 2-3% decrease in bounce rate as a result. The saving is made because of two reasons:

1. The javascript required to render the page gets down the browser quicker
2. The CSS sprite is now downloaded in parallel with all of the files required to render the page, whereas becuase it used to be on the same domain as the other files it would be delayed by the latency of a full round trip.