Client-side testing and personalization explained
An in-depth analysis of the most important technical considerations when implementing A/B tests and personalization campaigns on the client-side.
Summarize this articleHere’s what you need to know:
- Client-side A/B testing is the go-to method for testing and personalizing website content, thanks to its ease of use, speed, and flexibility.
- However, it can introduce flicker effects, reduce developer control, and present integration challenges.
- Advanced configuration options can help minimize flicker and optimize loading times, depending on your priorities.
- Choosing between synchronous and asynchronous loading depends on whether minimizing flicker or page load times is more important.
This post is one part of a multi-part series on the different technical approaches to A/B testing and personalization. In this article, I will provide an in-depth analysis of the most important considerations when implementing experiments and campaigns on the client-side.
How client-side testing and personalization works
So, what is client-side rendering?
Where does content get changed?
On the client-side
The page modification technique is the same across all vendors – a piece of code in the SDK performs an action based on the desired use case.
A few client-side rendering examples:
- Injects global CSS styles onto the page, changing the styling of elements on the page
Configuration options for client-side testing and personalization
Some of those include:
Which one: synchronous vs. asynchronous? At the end of the day, there is no universally right or wrong answer when it comes to synchronous versus asynchronous loading – the appropriate choice depends on your business priorities. If avoiding flicker is the highest priority, then synchronous loading should be used. If minimizing page load times is the highest priority, then asynchronous loading should be used. That said, the impacts on load time and other risks associated with synchronous loading are trivial enough when using a major vendor that synchronous loading is an appropriate approach for most websites.
As a cheat sheet for this discussion, refer to the following table:
Client-side script loading methods
Asynchronous with mitigation
Vendors also utilize a variety of techniques to reduce the file sizes of their scripts, through minification, removal of non-essential embedded libraries, dynamically removing old or unused experiments and personalization campaigns, and more.
4) Utilizing lazy loading techniques
In addition to purely reducing file sizes, some vendors implement lazy loading techniques on your testing and personalization campaigns so that only the absolutely necessary campaigns are loaded with the SDK. In practice, the necessary campaigns are typically the ones that apply above-the-fold on the most popular pages of your site. Other campaigns, such as those that execute below-the-fold or are triggered by specific events, are marked for lazy load. This usage of lazy loading reduces file sizes, delaying downloads to later network requests with smaller payloads.
Client-side rendering has become increasingly popular over the last few years, led by libraries and frameworks such as React and Angular. Since most A/B testing and omnichannel personalization platforms were developed before the rise of client-side rendering, most vendors still do not have great support for client-side rendered sites (as of early 2020).
For the few vendors that do provide “support,” their approaches would be more accurately described as workarounds rather than robust solutions, and typically come with many feature caveats.
Common approaches include:
- Extended implementations that promote the firing of special tracking functions on the vendor’s SDK as the context of the page changes, allowing the vendor to keep track of the site lifecycle. This approach allows developers to have full flexibility over when the vendor’s SDK takes actions, at the cost of increased implementation effort and ongoing maintenance code.
- Usage of client-side DOM monitoring functions such as the Mutation Observer, allowing the vendor to keep track of page changes automatically without much extra implementation effort required from your team. However, usage of such functions is typically not robust; DOM monitoring may be unreliable, especially if your site has a more complicated rendering flow.
Client-side rendering SEO impact
Is there a difference in client-side performance between vendors?
Next up: server-side testing and personalization
Based on our experience working with clients over the past 8 years, these are the most important technical aspects to consider for client-side testing and personalization. In the next part of this blog series, we will conduct a similar analysis on server-side testing and personalization.