• Client Side vs Server Side A/B Testing That Won’t Harm Your SEO

    A/B testing is an effective way to improve your sites conversion rate, it also allows you to improve your site’s user experience. By A/B testing different pages on your site, you’ll be in a position to better understand what is and isn’t working for your users. Tools such as Google Optimize are great for both […]

    AB Usability Testing

    A/B testing is an effective way to improve your sites conversion rate, it also allows you to improve your site’s user experience. By A/B testing different pages on your site, you’ll be in a position to better understand what is and isn’t working for your users. Tools such as Google Optimize are great for both A/B testing and multivariate testing on the client-side.

    Testing is the secret to making sense out of data, companies are now beginning to test everything, from the content of their visuals, to call to actions and even different algorithms. A/B testing is quickly becoming one of the best website conversion testing techniques being used by a variety of industries.

    A/B testing graphic
    Graphic by Visual Website Optimizer

    You can do A/B testing on either the client-side or server-side. There are many advantages to using either, but it’s important to first understand what it is you want to test and measure, and then work out what type of A/B testing will help you to reach the answers you need.

    What Is Server-Side Testing?

    A/B testing on the server-side is a form of experimentation where variations of a test are rendered directly on the web server, before being delivered directly to the client. By implementing A/B testing directly on the server, you’re able to run more sophisticated tests that might otherwise hold back the user experience if implemented on the client-side.

    Server-side testing is a good idea for cases when it is simply impractical to experiment on the client-side. An example of this could include testing two different product recommendation algorithms on an eCommerce site.

    Server-side testing will allow you to run multi-channel experimentation at the same time, such as web, mobile and even email.

    Examples of When Server-Side Testing Should Be Used

    Server-side testing can be most useful in some of the following scenarios:

    Running Experiments on Spas (Single Page Applications)

    Single-page applications serve dynamic content which refers to changing certain elements of a particular page based on the user’s interaction with it, rather than loading entirely new elements from the server. Examples of websites include Instagram, Facebook, Twitter and all other sites and apps that work behind a login. Testing dynamic content on your site/app is more technically complex, hence it only being tackled by server-side testing tools.

    Test the Launch of New Products or Features

    Before the launch of a new product or feature, there may be many ideas that product managers want to validate to ensure the launched product/feature is exactly what they envisioned it to be. Server-side testing allows product and UX teams to test deeper into their stack, experimenting thoroughly with their product features to measure their performance, validate hypotheses and roll new products/features out with confidence.

    Enhance Mobile In-App User Experience

    Mobile app technology is a whole lot different from web technology. This means that client-side experimentation on websites cannot be replicated for mobile apps, and even if you did decide to implement client-side testing on your mobile app, the result would not only be a poor experience, but also a lot of UI bugs. App stores require approvals when shipping new updates to your users, you can’t do this instantly like you can with a website. Therefore, to successfully run experiments on mobile apps, you would need a sophisticated server-side testing tool that is able to handle the complexity of a mobile app.

    Challenges of Server-Side Testing

    Slower Implementation and Execution

    If compared to client-side testing, server-side testing is more complex in its operation as variations need to be coded before the test can begin. Implementing and executing an entire server-side test campaign can be slower than running a client-side one, however, dedicating that extra time is immensely rewarded with deep insights on how you can optimize your entire stack as well as your UX.

    Reliant on Developers

    A dedicated development team is required to run an end-to-end server-side test. Whilst marketers and UXers are focused on improving and optimizing the user experiences, you’ll need a development team who are focused on implementing the server-side testing. Using server-side testing continuously and strategically will be an investment that will pay off in the long run.

    What Is Client-Side Testing?

    A/B testing on the client-side would involve testing variations of your page by doing manipulations on your browser(the client), done through JavaScript. When a user comes to a page, the Javascript inside your users’ browser will alter the content being delivered by the server so that the end user gets the appropriate variation of the page, based on the targeting rules that are selected.

    Client-side testing is a good idea for getting a better understanding of what visually needs to be done, in order to achieve more conversions or reach your end goal. An example of a client-side test could include changing the colour of a call to action, or changing the main hero image of your page.

    Client-side testing is a lot more suitable for teams who don’t have access to developers, since there are many client-side testing tools out there that allow you to make edits to your site using a visual editor.

    Limitations with Client-Side Testing

    There are a number of disadvantages to client-side testing, and some of the biggest limitations include:

    • Browser compatibility: Not all browsers support scripts so your users may experience errors if no alternatives have been provided. Different browsers and browser versions will also support scripts differently, so more quality assurance testing is required.
    • Developers: You may find that more development time may be required if the scripts aren’t available through other resources. While developers have more control over the look and behaviour of web widgets, usability problems may arise if a web widget looks like a standard control but behaves differently.
    • Flicker: Another common issue with client-side testing is flicker. When the user comes to your site/page, the testing tool is being loaded and a network request is being sent. The page continues to load while it waits for the response from the tool to load. Once the tool has loaded it will likely make another network request (depending on the tool you use) to get any test code to run on this page.

    If these network requests take too long, the elements on the page start to become visible, and once the test code finally reaches the page and executes, the visible elements are changed, resulting in a flicker from default to variation.

    Whilst there isn’t a cure for Flicker, there are a number of tactics that can be implemented to reduce the amount of Flicker.

    It’s important to fully understand which tool will best fit your needs for client-side testing. You want a tool that works well with your current setup, saves you time and eliminates the possibility of browser compatibility issues.

    Can Server-Side Testing Cause Issues for Your SEO?

    Whilst there’s no clear evidence that server-side testing can cause any major issues for your SEO, testing done on the client-side would ensure a minimum SEO impact. Typically changes made through JavaScript are not accounted for or indexed by Google, leaving no impact on your search engine optimization. However, it could be possible to cause SEO issues to your search ranking by abusing an A/B testing tool for purposes such as cloaking.

    “Cloaking is an SEO technique in which the content presented to the search engine spider is different from that presented to the user’s browser.”

    If Google determines that the variation of a page is substantially and materially different from the original, then they’ll likely see this change as cloaking and your site may end up being subject to a penalty.

    Things to Keep in Mind with Server-Side Testing

    If you have a great team of developers then server-side testing may be the better idea. Server-side testing can be great if your need is to run multiple tests across different platforms like websites, apps and email.

    With server-side testing, you also have the flexibility of doing deeper testing. For example being able to test significant changes to your product including algorithms, back-end logic, and underlying features. Whilst this requires time from your developers, it may also mean having to change some of the codebase in order to have these tests running.

    Server-side testing provides you with the opportunity to run tests with a minimal performance impact. The experiment is unnoticeable to the visitor, and also has little impact on the loading speed of the page.

    Things to Keep in Mind with Client-Side Testing

    Choose to use client-side testing for ease of experimentation. If the main objective is to enable your marketing team to create and implement experiments using a visual editor such as Google Optimize, then client-side testing is perfect. You’ll also find client-side testing to take less time to turn such experiments. Less work, more speed and a simple way to execute.

    Since client-side tests happen after the page is loaded, they can often take advantage of more data, to segment visitors based on data that isn’t available at the time the server request is made.

    Finally, as mentioned earlier client-side testing will also minimize the SEO impact of your site, reducing the risk of penalties and ranking issues.

    Final Points

    As you can see, both server-side testing and client-side testing are hugely valuable when used effectively.

    While server-side testing is newer, it shouldn’t necessarily be viewed as a better option. We recommend using both types of testing within your testing program, letting each individual test requirement determine what the right tool is for the job.