The peak survival guide for your website no. 2: performance testing

This is the second in a series of posts in which we recap some of the advice given by Tim Daish and Andy Davies in their recent webinar on preparing for peaks.

In the last post, we talked about setting early objectives and identifying what peak looks like for you.

This time, we’ll look at performance testing – when and how you should do it.

Performance testing subjects your site to increased levels of traffic in a controlled way, so you can understand how it behaves under load. It comes in several different forms. In a load test, traffic builds up gradually and is then maintained at a certain level. A spike test emulates a sudden flood of traffic (such as you might see in a DDoS attack – or if all your marketing emails landed at the same time!).

Planning and running a performance test can take some time, so it’s good to start early. On top of this, you should expect to do some performance tuning after your first test. Since you don’t know what you’re going to find, you need to leave yourself as much room as possible for those ‘unknown unknowns’. You could be going through a number of cycles of testing, tuning and retesting, which will usually take at least several weeks.

In our experience, timing is always tight, and the window between having an environment ready to test and the big launch or marketing campaign is often smaller than we would like.

So be realistic. Have clearly defined objectives. And limit your scope to the following areas:

  • key business functionality
  • key architectural features
  • key user groups.

Also make sure you test proven functionality – there’s no point performance testing a system that might be fundamentally broken.

Finally, test a ‘happy path’. That is to say, the route you expect visitors to take when they follow through and make a purchase or convert in some other way. This doesn’t mean you shouldn’t have more than one user journey – you need to make sure that all relevant parts of your system are covered. But rather than trying to cater for abandonment by scripting several partially complete journeys, it’s normally much more straightforward to include a separate script for general browsing and unfinished purchases.

Do it this way, and you’re much more likely to get through the performance testing process with the minimum of fuss – so you can get on with delivering a website that meets and exceeds expectations on the big day.

If you’re not sure how your website will cope during the pre-Christmas peak this year, just get in touch to discuss how we can help with performance testing and optimisation.

Published date:  29 September 2017

Written by:  Alex Painter

comments powered by Disqus

Filter By Service

Filter By Date