2 steps to improve your website load time by 50%

By David Mytton,
CEO & Founder of Server Density.

Published on the 8th August, 2009.

From Monday 27th July 2009 to Friday 31st July 2009 we ran an experiment on the website for our server monitoring service, Server Density. The aim was to reduce page load time by as much as possible with the minimal amount of work. With just a few tweaks to the site, we were able to reduce our load time by 52% – from 3.4s to 1.6s.

Although the number of seconds doesn’t sound much, there are a number of benefits to having a fast loading site:

  • The overall visitor experience is improved because visitors are not having to wait ages for the content to load.
  • Google looks at load time as part of its calculation of the page quality score.
  • Mobile users on limited bandwidth connections can get to your site faster.
  • Google found that every extra .5 seconds of load time dropped traffic by 20%.

There are 2 simple ways that you can improve your site load time in a very short period of time:

  • Reduce the (file) size of the elements on the page
  • Use a content delivery network (CDN)

Reduce the (file) size of the elements on the page

Ignoring the HTML content, there are x3 key elements on any web page, 2 of which can be compacted in size in just a few minutes; CSS and JS. This reduces the overall size that the browser has to download by stripping out comments, whitespace and other useless-to-the-browser elements. You simply maintain the original file but compress and serve the minimised version to your visitors.

The Yahoo UI Library includes a compressor for both JS and CSS which you can download to incorporate into your build process. Alternatively, you can use this online tool to do it manually via your browser.

Images are a little more complex but again Yahoo has a tool called Smush which will compress images into PNG format. It used to be a standalone website but is now part of YSlow. We use it on all our websites.

Use a content delivery network (CDN)

When downloading your content the web browser will only open a certain number of connections per URL. Placing your content onto multiple domains gets around this restriction so the elements of your site can download faster because they are being downloaded in parallel. You can set up another domain on your existing server to serve the static content but using a CDN brings another advantage – the content will be served from a location closest to your visitor.

Our servers are based in the US which means that visitors abroad (and even those further away from the data centre in the US) have to wait longer for the data to transfer. Granted, the speed of light is quite fast but reducing the number of hops a connection needs to take to get to and from your server will make a difference, especially for visitors from countries further away.

There are quite a few CDN providers and choosing the right one is important if you are serving high bandwidth content like video or audio. However for our experiment we wanted to go with the easiest and quickest provider. We looked at Rackspace Files which uses the Limelight CDN but they don’t support custom CNAMEs; for cosmetic reasons we really wanted to use our own domain – cdn.boxedice.net.

As such we chose to use the Amazon CloudFront service. This serves content from an S3 bucket and meant it was very easy to upload the files and get the CDN up and running. It only took about 10 minutes to do.

Load time

We measured the load time using the Pingdom Full Page Test on 27th July before and after we implemented the changes and saw the 52% drop.

Load time measurement screenshot


Using Amazon S3 and CloudFront is very cheap. The pricing is slightly different depending on the edge location and we served 129,507 requests at a cost of $0.30 over the week. This was split up into:

  • USA: 61,674 requests (0.410 GB) – $0.13
  • Europe: 60,286 requests (0.364 GB) – $0.13
  • Japan: 1,662 Requests (0.012 GB) – $0.02
  • Hong Kong: 5,885 Requests (0.037 GB) – $0.02

Since the goals of the experiment were a success, the next step would be to measure the actual effects on visitor conversion (because knowing is half the battle).

Other resources

This was a quick experiment and only a few changes were made. There are many resources dedicated to helping you speed up page load time so that with a little more time and effort, you could probably decrease that load time even more. Here are a few links that will help:

Articles you care about. Delivered.

Help us speak your language. What is your primary tech stack?

Maybe another time