If we want people to buy things from us, we need to make that process as easy as possible. Sound obvious? It should be. But - for our US readers - have you ever tried to buy a car? Was it easy, pleasant or simple? Based on our experience, the answer to that is a resounding "no.” You’d think that anyone running any business would want to make the buying process as easy as possible, since (obviousness alert) you need buyers in order to have business revenue.
Now, as developers, we don’t necessarily have to worry about pushy salesmen or deceptive sales managers. Instead, our job is to use our technical skills and troubleshooting acumen to continue to streamline what we can control: the buying process on our ecommerce sites and apps.
And nothing is more important to the buying process than the actual checkout process. Without it, all the bells and whistles in the world are irrelevant.
As a rule of thumb, 3 in four people abandon their shopping cart before they check out. (Check out this article for more details.) And that rate jumps to over 85% when on a mobile device.
We’re developers. We’re better than that. We can make sure that the reason those shopping carts are abandoned is not because the checkout process is too slow. Instead, load test your shopping cart and checkout process to watch for performance bottlenecks.
Our GDPR- and regulation-compliant code instrumentation tells us which parts of the app or site get the most use. Take that knowledge from your stats and determine the most common cart/checkout actions. If most people add only one or two items and then check out, focus on that most typical pattern.
It’s easy to get started: record a load testing script in the Load Impact load testing tool. (See this support article for more info), and use the Load Impact scenario recorder Chrome extension from the Chrome Web Store.)
For starters, use the recorder to build a simple process like:
When you’re done, the recorder plugin will direct you into the LoadImpact app. You’ll then validate your script. Validation runs one virtual simulated user through to make sure your script behaves as directed.
Load that script into your LoadImpact load tests and watch for performance bottlenecks - and then tune them and remove them.