Date: 20th January 2012
Following on from my last blog on the The Fallacy Of One-Page Website Performance Optimisation I just wanted to add a quick note in answer to the question: “My web tech team are using lots of cool page speed performance tools to make our pages faster, isn’t that enough?”
I wrote earlier this week how thinking ‘page’ is not as effective as thinking ‘Journey’ – but putting that to one side – in particular I was asked about Google’s Page Speed tool.
It’s a useful tool, I’m not knocking it, but I am saying that it’s scope and limitations need to be understood. You can entirely waste precious tech team resources if you don’t.
In the pursuit of “How can we make the website faster for end users” it has a role, but first and foremost be clear: it is a tool that makes recommendations on good things to do, in general, to speed up a page. Note I said ‘in general’ – because the issues today in your website platform that are causing poor customer experience online may be quite different to what Google Page Speed will recommend to you!
The analogy, is talking to a knowledgeable friend about a problem your car has cold starting, and they say your should change your air filter, it looks due. It’s not wrong advice, air filters can be a source of problems, but for your car there are so many other specific places that could be causing your issue, that the generic advice is more than likely to miss the mark. Of course it’s quick and easy for your friend to offer a generic solution that is know to work in many cases rather than to dig deeper and actually check performance of spark plugs, timing, ECU boxes, petrol filters etc etc and find the genuine root cause!
So the tool is good at pointing out some useful things to do that, in general, are sensible things to do, but be aware they make very little difference in practise to your specific site’s speed problems.
The second limitation of Google Page Speed, and it’s not a bug it’s designed this way’, is that it intentionally ignores everything about your website performance, except the shipping of page content to the end user’s browser. That is, of course, a sensible thing to measure and optimise and track over time, but on your website, your users may be getting a really nasty user experience every time you ramp up an online campaign for reasons quite outside that scope.
In fact, in the real world most of the performance problems that we find are causing our clients lost sales online are at the website datacentre. It’s easy to add more features and complexity to a site in an attempt to increase the richness of the user experience and end up with unforeseen quirks and slowdowns due to effects in your software in your web platform.
These are the kind of typical multiichannel retail user experience problems that Google Page Speed can never help you with:
- Login is sometimes slow
- Add to Basket performance is variable
- Checkout page sometimes slow
So, if your tech team spend a lot of time on Google Page Speed work, and achieve higher scores when they run them against the Google tool, be aware that it may not make the difference to your user experience that you’d like – it may miss the ‘make website faster’ objectives that you have.
It’s not a tool that sits close enough to your real user experience, to really belong in any kind of KPIs for your site – for that you need to measure by Doing What the Customer Does‘.
Just to be really clear, the tech factors that Page Speed measures are in themselves good things, so yes we do support sensible use of:
- Browser cache optimisation
- Reducing network round-trip delay by reducing the number of objects per page
- Reducing the number of packets per page by minimising content (minify’ing)
- Avoiding HTML content ordering that delays rendering times
- Optimising for mobile (we have monitoring services for m-web and mobile-apps)