There are two different ways to test a page. The most common approach, client-side testing, sends all users the same the page, but then JavaScript running on the client loads changes that alter the page for some users. This has the advantage of being simple to set up.
The other way is server-side testing. With this approach the server sends a variant version of the page to some users directly, and that’s all they load. This approach can be quicker. And it allows for complex, far-reaching ideas to be tested. But it is typically much more complex to set up, and caching can also be impacted.
The following sections go into client-side and server-side testing in a little more detail.
Client Side
- Changes are applied to the page as it loads, or after it loads, in the client’s (user’s) browser by Javascript.
- With most modern split testing platforms, this means small changes like switching out an image or changing the color of CSS element don’t require any technical expertise or access to the CMS/back-end.
- Minor cosmetic changes are easy to implement.
- Split URL tests with a completely different variant URL can also be run as client-side tests but often the creation of a whole new variant page isn’t required.
- There may be minor impact on page load time.
Server Side
- The alternative is set on the server before the page loads.
- All variants have to be available on your server.
- Requires far more technical expertise to set up both the variant and the underlying test infrastructure.
- There is no impact on load time unless the variant takes longer to load than the original.
- Caching may not have the same benefit.
- Server side testing is typically used for more far-reaching or complex changes.
Client-Side Advantages
If you’re just changing the color of a button or what’s in a headline, a client-side test is going to be quicker to set up and the results will be just as good.
Server-Side Advantages
Here are some scenarios when you might choose to test server-side.
- When you want to test changes to an app or involving an app (not an option client-side)
- When you’re making changes to dynamic content, like a shipping charge that’s based on a user’s address
- When you absolutely cannot have the user experience even a tiny delay or flicker in loading
- When you want to roll out complex changes carefully, with the ability to roll back at any time
- When you can’t or don’t want to make use of third-party cookies or send any data away from your own server (server-side testing makes this possible but doesn’t guarantee it)
- When you want to test parts of your side with high security needs.
Most split testing platforms are primarily or entirely client-side, but some (e.g. VWO Fullstack) offer server-side options via a Software Development Kit (SDK).
Third Party Cookies
Client-side testing may or may not involve third party cookies. It is possible to obtain useful information about how your site is being used without dropping a single cookie or collecting any information on additional users.
There are several advantages to running a test without third-party cookies.
- Reduced need for cookie walls and warnings.
- Some browsers block third party cookies by default but none block first party cookies by default. Set your own cookies and you’ll get better identification of returning users across multiple sessions.
- If you are in a sensitive sector such as health (where HIPAA rules may apply) keeping all data to your own server reduces risk and eliminates the need to get a partners to sign a BAA.
- Privacy-minded audiences like those at the highest end of the technical spectrum will notice.
Some technologies are more servers-side friendly than others. Ruby is commonly used for this purpose, but it is possible to server-side test even in user-side friendly environments like WordPress.