How We Improved Site Speed By 61%


We can't stress enough the importance of the page load time of your website. Three stats highlighted by Brendan in his post really hammer home its effect on your site's performance:

  • Almost half of all consumers expect a load time of 2 seconds or less and over a third will abandon the website if it takes more than 3 seconds
  • A single second delay in page response can result in a 7% conversion reduction
  • Concerning optimising for mobile, 73% of mobile internet users have encountered a website that was too slow to load and so becomes unusable

With that in mind, we constantly work to improve the page load time of our sites. We recently improved the speed of one of our sites by 61% . Here are the techniques we used and the subsequent results.

The Challenge

From both a front-end and back-end perspective the site was too slow. The median page load time was over six seconds. This improved slightly for repeat visitors (to nearly five seconds), but was still more than double the time that consumers expect. One problem was not so much that the site was slow, but that it was perceived to be slow.

Many of the slow to load elements were above the fold, meaning the user felt like they were waiting for the site to finish loading. Not only were the slow page load times frustrating for users, they were holding back the evolution of the site. Performance issues had to be resolved before we could even think about making the site responsive/catered to mobile (both from network and CPU/memory usage of device).

What We Did

Speeding up the server

The first part of the work was to cache as much data as possible so that it is not session-dependent. Over time, the site gradually got slowerWe then implemented conditionally-loaded JS/CSS and we had to find out why. This is the method Brendan detailed in his April post.

Third party widgets

Third party plugins (such as social widgets) are attractive because they're quick to implement. They do come with a cost in terms of how they affect performance. 

Often, plugins make a site slower because they have to pull in content from a third party website. If a plugin isn't adding value to your site, you might want to remove it. How do you deem whether a plugin is adding value? You need to look at user engagement with this plugin.

If it's not absolutely necessary, then get rid. We removed third party widgets/scripts that weren’t adding value to the site. The result was removal of over a dozen HTTP requests (making the site quicker and making the payload smaller to download), and reduction in DNS requests and SSL negotiation time. You can see this in the graphs below: 


JavaScript and CSS

Several techniques were used on the JavaScript (JS) and CSS to help with the site's performance. Firstly, we combined multiple JS files into as few files as possible and reduced file sizes by minifying JS and CSS. We then implemented conditionally-loaded JS/CSS.

Instead of JavaScript being pulled in on every page across the site, it is now dynamically pulled in just on the pages that need it, which made the pages load a lot quicker. We removed legacy JS and CSS that was no longer needed. We optimised the JavaScript and used console.time() as a profiling tool to find out if code could be rewritten to work faster.


Effective web pages have to look great, and images play a huge role in that. Often though, images are responsible for slow page-load time and poor site performance. We optimised images using ImageOptim.

The tool finds the best compression parameters for images and removes unnecessary comments and colour profiles. This means they take up less disk space and load quicker.

One page of the site we optimised saw a near 50% decrease in page size after running the images through the optimiser. Important to note that this app takes savings even beyond Photoshop’s ‘save for the web’ feature.

Above the fold

Earlier, we mentioned how the website was perceived to be slow, because slow loading elements were above the fold. By ensuring that above the fold elements didn’t rely on JS just to be shown, what the user sees first loaded quicker and their perceived experience of the site was faster.

The Results

So, the result of this work is a website that, on the face of it, looks no different to what it looked like before, yet is 61% quicker to load.

How did we measure the performance of the new and old site? We benchmarked the site using http://www.webpagetest.org.

The site was then tested 10 times with a first time visit and then a repeat visit from a testing server based in Dublin, using IE9.

This produced HTTP archive files (.har) which we then inspected in detail. We then used http://www.softwareishard.com/har/viewer/ to drag and drop the .har files and view their contents. Our key metric improvements were: 

  • HTTP requests: 96 -> 61 (36% saving)
  • First view load time: 6.378 seconds -> 3.574 seconds (44% saving)
  • First view page size: 1.235MB -> 830KB (33% saving)
  • Repeat view load time: 4.854 seconds -> 1.897 seconds (61% saving)

This highlights how important how optimisation is on the server as well as the browser. They are both as important as each other and optimisation on the browser-side tends to be overlooked.

Ultimately (and most importantly) these changes meant a much faster website and less frustration for the end user! Is your website's speed turning customers away? If so, get in touch with 9xb.com.Image credit: wwarby on Flickr

< Back to News & Insights