Google Page Speed - it's worth the effort

'The pressure on website developers to be experts in all areas of the web is becoming greater and greater. It seems every few months there is a new tool, new idea, new way of approaching the same thing, and the expectation is that web developers must learn and incorporate it. Google Page Speed is one of these tools.

Google Page Speed was initially released in June 2009 (source: http://code.google.com/p/page-speed/wiki/ReleaseNotes) as an add-on for Firebug in Firefox. The aim of the tool is to scan the current page you are viewing and tell you everything that is good, everything that could be improved, and everything that (in Google's opinion) should be improved.

I'd like to think that most web developers are genuinely concerned in wanting to build a strong robust website that works well for their clients and provides a joyful web browsing experience for the end user. We take pride in our work and try not to cut too many corners. But when you run the Google Page Speed tool on your site you get a sudden shrinking feeling that you’ve done a terrible job. Sure you may get around 70-85 out of 100 but those annoying red and yellow icons are off putting and the green ones are so nice and, well, green.

First impressions are to ignore the facts and say your website isn’t that bad as it loads perfectly fine for me, and for everyone else, and surely that’s all that matters. Right? Since its inception in 2009, Google have been busy refining their tool and now include results as part of their Google Webmaster Tools. Now, as of April 2010 (source http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html), it is official that page speed is affecting your clients website rankings. Although it is probably true that it isn’t a ‘huge’ factor in your rankings, it does affect them and, as a developer who is trying to produce the best website for the client, it means we should be taking notice of this.

After researching each of the problems reported by the Google Page Speed tool (thankfully they provide good documentation within the tool itself), I’ve come to realise that it isn’t so bad after all. Each of the errors reported can be split up into four different categories: DNS, server setup, compression tools, and best practise HTML.

DNS:
It is recommended to use alternative host names to load media type content e.g. instead of loading all images from www.apexinternet.co.nz load them from images.apexinternet.co.nz. If there are many images to be loaded on a single page then load them from images1.apexinternet.co.nz, images2.apexinternet.co.nz, etc... This is probably one of the trickier items to resolve, especially if you are using a CMS that doesn’t support this, but it does increase the time it takes to load a page. See http://code.google.com/speed/page-speed/docs/rtt.html#ParallelizeDownloads for more information.

Server setup:
I can only comment on Linux servers, but providing they are setup for compression correctly you can add a few simple lines to your .htaccess file and it will gain you some extra points in your results:

# Compression Optimisations

SetOutputFilter DEFLATE

ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"

You can also add your filename extensions to the ‘FilesMatch’ expression to compress them as well, e.g. (js|css|php) See http://code.google.com/speed/page-speed/docs/payload.html#GzipCompression for more information.

Compression tools:
These consist of compressing your images for websites – believe it or not you can cut down your file size by about 75% on some images. There is loads of free image compression software out there so just go and ask Google.

Minifying your code is another must. There are tools out there for this as well, though, finding a HTML minify tool isn’t as simple as hoped – especially if you are trying to automate this. See http://code.google.com/speed/page-speed/docs/payload.html#MinifyCss for more information.

Best practise HTML:
The title of this says it all – keep your code ‘clean’ and ‘complete’. Every image, yes EVERY image, must have an ALT tag and must have WIDTH/HEIGHT set somewhere in HTML or CSS. The order of how you call resources in your header tags is also important.

The lists above are only the tip of the iceberg but hopefully it’s given you a little insight to realise that it isn’t as bad as first thought and that it truly is worth the effort when you get your score in the mid 90’s. It is very much possible and, if you're clever enough, you can automate a lot of it. In an upcoming release of our CMS, Orbit, much of these will be addressed automatically which, will take the pressure back off the developer allowing them to focus on what they love to do.

One final note is to not get to worry too much if you can’t fix everything to get a perfect 100/100. There are situations where you do what you do for a reason and, although Google’s tool doesn’t agree with it, it is perfectly acceptable. At the end of the day we are trying to make a faster web browser experience, and if your name can be attached to helping make that happen, then go for it.

Useful resources:
http://code.google.com/p/page-speed/wiki/ReleaseNotes
http://code.google.com/speed/page-speed/
http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html
http://code.google.com/speed/page-speed/docs/rtt.html#ParallelizeDownloads
http://code.google.com/speed/page-speed/docs/payload.html#GzipCompression
http://code.google.com/speed/page-speed/docs/payload.html#MinifyCss
http://www.orbitcms.co.nz/