Serve-side testing is contrasted with client-side testing, where the test cases are rendered (typically using some type of testing tool) using JavaScript during the loading of the web page.

Benefits of Server-Side Testing

One of the main problems with client-side A/B testing is that it’s almost certain to impact the user experience in some negative way. If you use asynchronous JavaScript, the original page will load first and then be replaced by the test variation, causing a “flicker effect”. If you use synchronous JavaScript, however, the page load time will suffer, and your end user will stare at a blank page until the content loads.

Server-side A/B testing eliminates this problem completely. Since the variation is determined before the resource is served to the visitor’s browser, there is no flickering and no negative effect on load time.

Another benefit of server-side testing is the ability to use it for mobile apps, or other environments serving dynamic content. This ability to be “omnichannel” helps businesses test variations across multiple platforms.

The most critical benefit, though, is the ability to test the full stack. Client-side testing tools may be simpler for marketing teams to implement, but they can only test the look and feel of the website. If a development team would like to A/B test anything on the back-end, like a new algorithm or a different database query, they will need to use server-side testing.

The Lifecycle of a Server-Side Test

To run experiments with server-side testing, just like any other A/B testing, you begin with a hypothesis. “We think this new search algorithm will be more effective,” or “we think this simplified user interface will improve conversion rates,” or whatever it is. Once the hypothesis is determined, all variations have to be built.

This is a key difference between server-side and client-side tests. Using the type of WYSIWYG editor provided by many client-side testing tools, marketing and product teams are able to perform tests without having to actually implement the alternate variations. On the other hand, all the different variations in a server-side test must be actually implemented by the developers.

After the test is complete, significance is calculated, and the winning variation is determined, it’s time to roll out the winner. There is another key difference between server- and client-side testing here: in a client-side test, once the winner is determined, it has to be built and implemented, whereas in a server-side test, all variations have already been implemented (and are probably just behind feature flags), so it’s a simple matter of rolling out the winner to all users.

So in short, server-side testing is slower when the alternate versions don’t win (because the developers built them for nothing), but faster when they do (because they’re already built and just need to be rolled out).

Server-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 server side testing if:

• You want to be able to test across multiple platforms, from web applications to mobile apps
• You want to be able to test across the full stack
• You want to test without it impacting your users on the front-end, either from longer page load time or “flickering”
• You have the developer resources to do a deployment for each experiment

It’s much easier to implement this if you use a server-side solution like Split, which can help you manage all your experiments in one place.