How To Speed Up Your Website Load Times

Some time ago Jack Osborne and I decided to sped up the current Hobo site to see if increasing page download speed had a positive impact on ranking, or the amount of traffic Google sent to your site. I left this article in drafts while I monitored any ranking benefits.

At the end of last year, we basically looked at an actual page on Hobo, and all the files involved in creating the page, and looked to see where we could make speed improvements.

This was the test page for benchmarking.

Essentially we took 299kb (Whoops!) and reduced it to an ‘old-school’ @50k target size by:

• redeveloping our bespoke WP theme template and css
• compressing css and javascript files
• reducing image size
• deactivating underperforming plugins
• removing some javascripts
• validating css and html
• improving the accessibility of the page
• making our form script load on only the contact page
• Gzip compression server side

Before

• Total loading time:10.5 seconds
• Total objects:78 (299.2 KB)
• External objects:4 (3.6 KB)
• (X)HTML:1 (22.5KB)
• CSS:6 (43.5KB)
• Scripts:3 (97.8KB)
• Images:68 (135.5KB)

After

• Total loading time:0.3 seconds
• Total objects:12 (50.8 KB)
• External objects:1 (1.3 KB)
• (X)HTML:1 (16.5KB)
• CSS:3 (8.2KB)
• Scripts:0
• Images:8 (26.2KB)

Google Webmaster Tools Performance Overview

Using GWT Performance Overview (found in Google Webmaster Tools LABS feature) I could monitor what Google thought of my page speeds – and as a result of the changes we made – we basically halved the download speed according to the measurements Google make:

On average, pages in your site take 3.4 seconds to load (updated on Dec 14, 2010). This is slower than 58% of sites. These estimates are of medium accuracy (between 100 and 1000 data points)

Clearly, there’s still room for improvement across the site, but the graph shows a big improvement, even though I started adding elements to the site since we made the changes to the site near the end of November 2010 and have since slowed things down a little again with some other plugins that will probably be getting uninstalled:

Speed Test & Accessibility Tools Used

• http://tools.pingdom.com/fpt/
• http://jigsaw.w3.org/css-validator/
• http://validator.w3.org/
• http://wave.webaim.org/
• http://www.cynthiasays.com/
• http://achecker.ca/checker/
• http://fae.cita.uiuc.edu/
• http://www.cssdrive.com/index.php/main/csscompressor/

Google also has a great page with plenty of tools for the web developer serious about improving website load times.
I will no doubt introduce some new things over time which will increase my download times again, but i will be sure to keep an eye on things. I’m sure there’s a few other things we could do to increase the download speed of our pages, but that will do for now.

Accessibility

I do care about accessibility and web standards. And so does Google apparently.

Why does validation matter? There are different perspectives on validation—at Google there are different approaches and priorities too—but the Webmaster Team considers validation a baseline quality attribute. It doesn’t guarantee accessibility, performance, or maintainability, but it reduces the number of possible issues that could arise and in many cases indicates appropriate use of technology. Google.

While it’s hotly debated wether or not valid html improves your actual website rankings – it’s always a good idea to aim for a decent level of accessibility for your website pages – which reminds me – probably time to check my own pages again!

Restructuring HTML

One of the major drawbacks with the previous wordpress template was the amount of code bloat. There were multiple divs within the code which had no effect on the visual appearance, the only thing they contributed was bumping the file size of the pages up a few kilobytes.

Coupled with the code bloat there was also a lot of non-semantic mark-up, divs with intangible classes and ids.

For the new template, we mocked up a simple wireframe, based on the exisiting blog layout and started to flesh out the site; what divs were needed and what the appropriate class names and ids would be. From there we starting designing the website in the browser to help iterate  and see how things shaped up. A major plus point of designing in the browser is that you can see how how the site displays across multiple different browsers; Apple Safari, Google Chrome, Internet Explorer and Opera.

Redoing the CSS

As well as completely recreating the template files, the CSS files were also redone. Nothing was carried over, we started with a clean slate.

The first thing we done when setting up our CSS file was to use a reset which the rest of the file would be built upon.

Roughly a year ago there was a tutorial on the A List Apart website which discussed how to go about creating a completely fluid/scaleable website, much like you would have with an old school table but instead built entirely with divs. I had been desperate to try this in a live production site for some time and the hobo blog provided me with this opportunity. Grab the corner of your browser window and resize the website to watch the elements flow around eachother.

All of the CSS was then factored into single line delcarations, as opposed to multi-line, to save valuable kilobytes.

Typography

All of the typography within the site was also addressed. We used the golden ratio, with the help of the Modular Scale website, to keep everything harmonious. Here’s a tutorial on how to use the modular scale website. Moving forward – we’ll probably use Google Web Fonts too.

What Effect Did All This Effort Have On My Site Traffic?

Did this massive change in download speed improve the Hobo rankings? After all, Google did say site speed was a ranking factor……

Well, no, not that I measured with any accuracy.

It *might* have in some areas…. but is that possible improvement justification for spending hours redeveloping your site? On it’s own – probably not – if you have to choose between redevelopment and link building or making your page more relevant!

Saying that – of course – a faster site has other benefits of course outwith anything to do with your Google rankings. A faster site could well improve visitor satisfaction and total number of conversions, for instance.

I didn’t expect faster website load times to improve the rankings of my website. I blogged about Google and site speed a long time ago. My friend Tad did a useful article a while ago, too - 30 Ways to Optimise Your Site for Speed.

I did want a faster site though – for all the other benefits.

NB – We are currently redeveloping the Hobo site as I write this to make it more… professional, but we’ll still be using Google Webmaster Tools (which are actually quite useful now) and the other tools mentioned to keep an eye on website download speeds and accessibility.

Written by Shaun Anderson