Client-side testing is contrasted with server-side testing, where the test cases are decided on the back-end (in the web server) before they’re served to the end user.

Benefits of Client-Side Testing

There exist a variety of testing tools that can make it easy to implement client-side A/B testing. Many of them include a WYSIWYG editor that lets you easily change components in a visual editor without needing to reach into the code at all. This type of testing framework makes running tests on the client-side extremely easy and intuitive.

It also makes it possible for marketing teams to run experiments without needing to employ a front-end developer. Not a single line of code needs to be written, not a single actual deployment needs to happen until the experiment is complete. Once that happens, the developers only need to be brought in if the winning variation was one of the alternatives: otherwise, the alternate variations can simply be scrapped and a new experiment can begin.

Another benefit of client side testing is the additional user data available. Because the variation hasn’t been decided until the page loads in the visitor’s browser, more data can be gathered about the user to determine which variation to serve. On the other hand, server side testing has less user data to work on, so it’s less able to segment users.

There are some drawbacks to client side testing, though. The most common is that, since the test is implemented using client side JavaScript, the user experience can suffer. Depending on the specific implementation, the page load time can get higher as it takes a second to determine what variation the user should see, or the user could see a “flickering” effect on the webpage as the original version is displayed before the test variation displays in its place. While load time issues are harder to fix, flickering can be tactically improved by only using client-side tests for elements below the fold.

The Lifecycle of a Client-Side Test

A client side A/B test, like any other A/B test, begins with a hypothesis. “We think changing the color of this CTA button will improve conversion rate” is a classic example. Once the hypothesis is determined, the variations can be created using the visual editor and displayed to users using the testing tool.

After the test is complete, significance is calculated, and the winning variation is determined, it’s time to implement the winner. This is a key difference between client-side and server-side testing: when an alternate version wins in an experiment, the actual deployment process is slower than in client-side testing because the variations have not yet been built. With a server-side test, the variations have to be built in order to be tested, so the rollout process is extremely fast. However, on the converse, if a test fails to produce significant results, the variations that cost developer effort for a server-side test will have to simply be scrapped, whereas no developer effort went into creating variations in a client-side test. There is less cost to doing more experiments if they’re done on the client-side.

Client-Side Testing Use Cases

By now, you’ve probably realized that the question is not “server side or client side testing, which is better?” — it’s “server side or client side testing, which is better for you?”

You should probably use client side testing if:

• You only need to test the front-end “look and feel” of your website or web application
• You’re either testing below-the-fold elements, or you’d like to run low-cost experiments only visible to internal users (aka, you’re in a situation where the flickering or page load issues don’t make a significant difference)
• You don’t want to expend the developer resources to do a deployment for each experiment
• You want to collect more user data before displaying different variations

If your use case doesn’t fit all or some of these criteria, you might want to consider server-side A/B testing instead.