Blog homeOver the last week I have been thinking about speed - in particular the speed of websites and web based applications.
If you ask a technical person, page generation speed is often an attribute that is admired….. but a business person is often more focussed on whether a system achieves their business objectives.
So why has speed come to my attention this week
It is fairly old news now but Google have announced that landing page load time will now be incorporated into the Google Adwords quality score. Slow pages will be ranked lower - which will impact your marketing budget. All of the sudden speed has jumped from being something of interest to technology people and business people are paying attention.
What seems odd is that they have gone the route of comparing landing pages with other pages hosted in a similar geographic location. This could be interesting for mashups where your pages are hosted in various places!
My take on speed
We spend a great deal of time looking at page loading speed. We have an absolute maximum of 200 milliseconds for page generation (excludes JavaScript / CSS downloading) - and most pages are in the 20-30 millisecond range. Our “heavy” pages are 250 milliseconds (uncached).
However, as most know, page speed is primarily impacted by the JavaScript / CSS…. not the page generation component. We really do page generation optimisation for system performance reasons not user perceived speed improvements. Anyway, it is a nice metric to look at.
Are we looking at the right speed measure?
No I don’t believe so. Instead of focussing on the core speed metric we should be looking at task completion time (assuming that the task is necessary, obviously. Systems that are perceived as slow by users may be technically fast - but slow to achieve various tasks)
For example an online booking may take 10 minutes for a consumer to achieve (search, select, pay and confirm). If you gave this system to a travel agent they would say this is far too slow - but a consumer may be prepared to slowly progress through a system because they are enjoying the experience - and because each step has minimal cognitive “brain load” so every step is clear and understandable (rather than being designed for advanced, trained, users)
Is speed a reservation system selection factor?
Last week we won a customer from a competitor as a result of our good system speed. When two systems have similar functionality then speed can be decisive. I was quite interested that a customer specifically told us this was a factor for them (especially as this is a criticism aimed at may web based systems vs desktop based software)
While doing a bit of research on the web I found this interesting Google advert. Anite provide reservation systems for many of the larger tour operators in the UK. They also work in other IT sectors. This advert looks like one of their competitors (non-travel) has decided to make a point that their system is faster than Anite’s.
Ummm…. not sure what Anite will make of that.
If you want to be notified next time something is published sign up for email alerts or subscribe to the RSS feed. Thank you for reading!
I’m not sure that I agree that speed of the overall transaction is more important than response times per se. If your site/system is slow - recent research suggests more than 4seconds per page load is so slow a third of users will abandon the site - then you’re going to lose business to sites that are zippy, and there aren’t many of those around.
A quick response time is key to creating a great overall consumer experience, and a great experience backed up by good content will help create a brand.
Why do so many sites out there have such mediocre performance? Probably because one of the most important parts of the booking process - product search - is now so much more resource intensive than it was in the “good old days” of viewdata. And with Caching, Faceted Search and Guided Navigation about to become the norm, it’s just got yet more complex, and potentially expensive, to compete.
Speed matters, especially when searching, and together with “web2.0 presentation”will sort the men from the boys. It thinks it’s a key differentiator for the savvy online consumer.
Hi Ed,
Thanks for your comment.
You are right - however I wasn’t very clear. I was really talking about task based speed when within an application (such as a web based application) where the same task may be repeated multiple times over the course of a working day. I agree that search speed is going to be a big problem for most to address shortly.
I remember working for one airline site (connected to a GDS) but they weren’t as commercially successful as other websites connected to the same GDS. Theoretically they should have been equal (because they had the same inventory) but this one website in particular was cutting searches at 20 seconds -but as a result of their own internal algorithms they were not finding the most appropriate product in the same 20 seconds as competitors with the same distribution source.
Sometime soon engineers are going to get the respect (and the pay) that their skills can generate.