How to Ask for Performance as a Requirement [Blog]

By: Roland Campbell, Director of Solutions Engineering, Usablenet

Every marketer or product owner knows the challenge of increasing conversion, order value or channel revenue across any or all digital properties. Accomplishing the goal of driving the right metrics up, and eliminating the causes of poor experiences that lead to bounce rates or cart abandonments often require a spectrum to actions and interventions. A UI/UX refresh, a rebranding program, or even re-platforming to the latest technology may all be part of the solution set to be considered. While all or some of these might help, I want to point you toward something may not have thought of or discounted. Look first to your current performance statistics. Are you seeing any of these behaviors identified by Radware play out?

44% of online shoppers say that slow online transactions make them anxious about the success of a transaction
Shoppers remember online wait times as being 35% longer than they actually are
A 2-second delay in load time during a transaction results in abandonment rates of up to 87%
18% of shoppers will abandon their cart if the pages are too slow
46% of shoppers cite checkout speed as the number one factor that determines whether or not they will return to a site.

Pretty compelling numbers, but it gets worse. The vast majority of mobile users (85%) expect pages to load as fast or faster than they load on desktop. In 2014, more than 55% of all retail traffic was from mobile devices! So its fair to say that the largest percentage of your users are coming in on devices with constrained network access, and yet they expect the experience to be as fast as your fastest platform (web) and will punish you if it is not.

Tips to get the Performance you need

You have to make sure when the requirements for your digital properties are built out, that performance requirements are built in. But, you face a challenge, as non-functional requirements (like performance) can be tricky. The first thing everyone will say is, “A page should load in less than 4 seconds”. An admirable goal, but short-sighted, without enough specificity. You left out which platform (e.g. desktop, mobile), which page and at what load.

A development team might take the 4-second load requirement to bring up a page and test it on a single machine. Often, it loads really fast. A second, simultaneous user might never load. This points to why you need to know your average and peak loads across a range of different channels. You probably already have a great handle on this from your analytics. Look at your page views per day and figure out the average load and the peak load. Remember to add to the load based on your estimate for growth. Mobile will likely grow faster than you think while desktop will grow slower.

Now let’s look at page speed. Do you want the entire page to load or do you want the page to be interactive? I would suggest that if interactive is OK most of the time, the homepage should load. If you are going for interactive, the page must load from the top down.

So now we have a requirement of a 4-second time to interactive, under average load. What performance penalty are you willing to accept at highest load? Work with your IT infrastructure team here. Peak traffic is usually transitory, but is often at your most important times. However, increasing performance at the highest loads can be expensive, meaning a compromise would need to be made. If you want to sound like you know what you are asking, ask your IT partners if the infrastructure supports cloudbursting, since that would be an option to support peak loads.

Is that it? Well, no, you should build the requirement around a flow. Walk through a purchase flow, and include “think time”. Calculate how much time it takes the average shopper to decide to take the next step and to complete that step. Figure out what percentage of people complete each step? Even if you had stellar performance and the best UI/UX possible, each step in your purchase flow will have abandons and bounces. People are fickle. I look at high-priced scuba equipment all the time, but I rarely buy.

Having followed the guidelines above, we now have an effective performance requirement: “A user should be able complete the purchase flow from PLP, to PDP, add to cart and checkout, with average time to interactivity of 4 seconds, at an average load of 2000 users starting the flow, with 75% completing the flow with a total think time of 20 seconds”.

I recognize that this approach requires more information and work to complete, but you will find the work well worth it when you are able to effectively eliminate all of the fuzziness that comes from addressing performance requirements.