The Fallacy Of One-Page Website Performance Optimisation

Date: 16th January 2012
Author: Deri Jones

I get to sit in on a lot of meetings with clients, who are looking to improve the ROI of their websites.

The most interesting ones are with organisations that have evolved far enough along the eCommerce evolutionary path to realise that it’s no good IT and Business teams sitting in separate silos. Those that understand that all teams need to pull together to achieve better online sales for their company, that their functions are interdependent and that it is through focusing on continually improving the technology underpinning the user experience that they will achieve their biggest success.

OptimisationIts at that point in an organisation’s evolution, that things online get exciting. The pace of change picks up, the common language of metrics derived from a ‘Do what the Customer Does’ approach to measurement reduces friction, and overall there’s a buzz and excitement growing as sales and conversions rise. Not only that but there is a new satisfaction for tech teams that their work has made a visible difference and they are no longer just the whipping boys for website shortfalls!

But there’s still scope for the momentum to be lost through some common pitfalls.

The downside to the tremendous pace of online change is that beliefs based on old knowledge are still hanging around in the dusty corners of boardrooms and server centres up and down the country.

Let’s throw a bit of light into some of these dark corners.

Page resolution speed is a vital element for good Sales Conversions.

Sure: new dialogue opens up with Tech teams around speed of User Experience, and early initiatives gain success through measuring the performance 24/7 of the multi-page Dynamic User Journeys that reproduce what real customers do.

However… someone, somewhere starts to get obsessed with the speed of individual pages in isolation to the user’s entire Journey. Complex multipart journeys need to be considered as a whole as well as their component parts.

Of course, once you are measuring 24/7 multipage User Journeys, one of the key metrics it will quickly provide, is which of your page types slow down the most under load. And of course, knowing that fact, its good to aim to speed up that page.

Speeding up a page is good of course – but once you’ve achieved some gains, you need to go back to the Customer level, to the user Journey: and see what the next issue is not stay blinkered down at the one page basement.

But, whether initiated in Marketing or in Tech the focus can shift from the customer, from the multi-page User Journeys that they follow: and can become all about ‘go faster stripes’ for just one page.

A page that resolves quickly but does not meet user needs as part of a journey in other ways will not perform well in terms of results.

A page is not a journey.

It sounds obvious, right? But it is very common for people to focus on an isolated step of a journey – for example the product page on a retail site – but this is often the just the first or second step in a functionally complex multipage interaction and as we know from a wealth of usability data it is often the later steps such as checkout processes where users are more likely to have a lower tolerance for problems.

But you’ll see forum discussions, full of requests on ‘making my page faster’, how to ‘minify’ my page, tricks to improve caching of my page and so on, but this shows a lack of understanding as to how sites work now.

Focusing on one page, is rather like going back to the early days of the Internet – when pages were simple, before CMS and inventory management systems became commonplace. In that world, the performance of the page was indeed not determined by any other page- it stood alone.

But in the modern world of rich pages dynamically put together in real time – that is no longer true.

To take a simple example let’s look at the CSS and JS files that a page needs: if you have already visited other pages at the same site, your browser will have those pages in cache already, so the next page is automatically lighter. It doesn’t just matter where the user goes, it matters how they got there, in other words, it’s the journey that counts.

One page is no longer just one page.

What’s more – with the advent of widespread AJAX and increasing HTML5 – the page actually changes as you move around it.

One of the most important links on any page on your site is at the end of Checkout, the ‘Confirm Purchase’ button. On many sites you cannot reach that button until you have filled in some previous fields; and in the process various parts of the page may have opened or closed in a “concertina”.

So you cannot optimise the performance of that page, without measuring all those steps within the page. All the little AJAX server connections that may happen as the user acts.

Increasingly many pages are made up of a number of disparate components, sometimes provided by, or displaying content from, external sources such a media players, ad servers, news tickers, twitter feeds etc. What appears as “a page” to the user is actually more like a “housing” for several “sub pages” that update at different frequencies, from different sources, hosted in different places. In the course of completing a user journey some of these components may be more important that others.

So optimising “a page” is, taken out of context, quite the wrong focus.

Realism is vital but it is not simple.

Yes, it can be a simpler world, when you only care about one page in isolation, and ignore meaningful Journeys – the web page optimisation route.

Yes – it can make Load testing projects much more bite-sized.

For data to be meaningful and actionable and all those other good things it needs to tell us important information about the real world. The snag is that the real world is not “easy” or “simple” it can’t be summed up by “one simple top line number” no matter how handy that would be for meetings and presentations.

Only the MultiPage Journeys reveal how Fit for Purpose your site is

If you ignore the Journey numbers and look only at page numbers: you are no longer measuring Customer experience, and can easily end up with a single page type that is 20% faster, but the overall User Journey no faster at all because some code optimisations have inadvertently slowed other pages!

Or a new sporadic error type may be appearing after a small tech change, so that for some of the boundary conditions that pages only experience when they called from other pages in certain paths.

Those errors are losing business from real people – but you won’t know if you only measure page performance.

A good number of the projects we pick up, clients have already some page-based website performance monitoring in place – some of the tools they have subscribed to and used before coming to us have been single URL focused, and given them a false sense of security that is shattered when they see the actual experience their users are getting when our Journey based measurements start to deliver data!

It’s not about the Page – it’s about the Customer Journey!

Contact us for more information or to discuss a demo or trial.

Top