Personalization and A/B testing with single page application frameworks

Jonatan Ramirez

Every day we interact with different sites created using single page application frameworks such as YouTube, Netflix, Facebook, and many others.

An increasingly popular architecture for building web applications and sites, we wanted to provide some clarity on the topic. In this post, we’ll dive into the rise of single page applications, what they are, the pros and cons, as well as how to overcome some common challenges presented when using them within the context of A/B testing and personalization.

Before we dive in, let’s define some common terms we’ll be using throughout this article.

XMLHttpRequest (XHR): An object-based API used to interact with servers (aka send HTTP or HTTPS requests) to retrieve data from the URL without fully refreshing the page.

Single Page Application (SPA): A web application using a single HTML file that dynamically updates the content of the current page based on an interaction occurring on the client-side or browser.

Multi-Page Application (MPA): Traditional web applications conformed by multiple HTML files that reload the entire page and display a new one upon user interaction.

Client-Side: The browser, i.e. Google Chrome, Safari, Internet Explorer, Firefox, etc., where dynamic action is taken. For single page applications, most of the logic and operations are executed client-side.

Server-Side: This is where most of the data processing takes place for traditional multi-page applications – typically developed using server-side languages like PHP, native React, Node JS, and others.

AJAX: A set of web development techniques used for building asynchronous web applications that are executed on the client-side.

Application Programming Interface (API): A collection of methods that enable applications to send requests for a service and receive a response back, usually in the form of a JSON.

The evolution of single page application frameworks

Before SPAs, when technical teams wanted to build a web application, multiple HTML files were created to represent all possible pages visitors could navigate. But as time passed, new technologies like AJAX appeared, making it possible to retrieve data from the server without the need to load individual HTML pages with new content simplifying the navigation experience across pages.

As AJAX matured, a new concept developed where all of the site’s content was preloaded onto a single HTML file, and different sections were shown to visitors based on their interactions. An architecture defined in large by mobile applications, it allowed visitors to move faster across areas of the site by making light internet calls to the server to load the necessary data and content for the desired section.

With these improvements, more and more technical teams began exploring avenues for migrating to SPA frameworks in order to reduce site load times for their visitors. And this trend has only grown as businesses compete to grab and hold the attention of consumers who now expect seamless, fast, and highly tailored experiences online.

To refresh or not to refresh the browser

With traditional MPAs, after an action is taken on a website, most of the logic is executed on the server, where numerous processing requests must be made to load each new HTML page. SPAs, on the other hand, move this logic client-side (or the browser), loading all of the required HTML, CSS, and Javascript from the server just once. Subsequent visitor interactions are then handled using lighter XRH to only retrieve the data needed to render the new content or virtual page that must be loaded after the interaction has taken place in the browser.

The key difference between the two being that visitors remain on a single page (typically the homepage or index.html) that loads virtual page views as they engage with different areas of the site, instead of the browser being fully refreshed and loading new HTML, CSS, and Javascript files with every new pageview. As a result, the user experience is faster and much more fluid.

Some of the main aspects when designing a single page application architecture can be summarized in the following points:

Routing: How visitors will navigate across the different sections of the site without having to fully load a new page.
Dynamic user interfaces: How the content will be updated based on visitor actions. This is done using very lightweight data structures called JSON, which are used to provide a structured definition of the new state that needs to be used to render the content based on the visitor’s actions.
Access to data: How to access data without having to make additional network requests. Typically done by making use of client-side or browser features, where data can be persisted or cached in session variables stored in the local storage provided by the browser.

What are the technologies behind a single page application architecture?

In essence, a single page application is a Javascript framework that also uses HTML5 and CSS3. These become the main components to building SPAs, however, there are a few libraries and frameworks that have emerged and become popular in development using the previous components:

React.js: Developed by Facebook, it is mainly for developing user interfaces, typically in conjunction with Redux to manage the state of the application components.

Angular.js: Developed by Google, it uses a Model View Controller (MVC) architecture that allows for updates to the model every time the view changes, which are managed by the controller.

Vue.js: An MIT licensed open software used not only to build Single Page Applications but also to render content server-side as well sites that are statically generated. React Vue also requires state management handled by Vuex.

Meteor: There are additional packages compatible with Meteor that help to resolve the impact SPAs have on SEO by rendering the pages server-side.

Weighing the pros and cons of single page applications

Much like the debate between client-side vs. server-side testing (which is actually closely related to our conversation on SPAs today), there are always important factors to consider when implementing new technologies or frameworks. Below, find a deeper breakdown into the advantages and disadvantages of utilizing single page applications.

Important factors to consider before implementing SPAs
	Upsides	Downsides
Speed	Once the first page has loaded, the following interactions will be resolved in shorter periods of time compared to MPA. Dynamic content based on user interactions is loaded faster.	Initial page load can be slow due to the size of the files needed to process subsequent virtual page views.
SEO	If rendered server-side, SPA will be seen like traditional pages regarding SEO. This is typically possible using solutions like PREACT.	A perceived impact on SEO ranking as crawling and indexing becomes more difficult when fully rendering pages server-side. Google is improving the way SPAs are handled by executing the Javascript that handles the rendering of the new content.
Implementation	Reduction in code writing as methods and other pieces of functionality become reusable. Additionally, there are multiple libraries that can be used to minimize the amount of code needed to perform an action. Debugging can be simplified by using browsers like Chrome, where all SPA actions can be monitored.	Requires development and Javascript skills. Analytics and interaction events are harder to implement and must be linked to the dynamic changes occurring on the SPA.
Reach	Can support offline navigation by using data stored directly in the browser. Ideal for mobile-based sites due to the low levels of data required to load the application, reducing the consumption of mobile network resources.	Not available for devices that don’t support Javascript.
Architecture	Perfect for serverless architectures as most of the processing usually handled by the server is moved client-side to be handled by the SPA. Multiple frameworks and libraries to develop SPAs.	When not managed appropriately, scenarios where visitors leave pages using SPA opened can result in memory leaks that can lead to browser crashes as well as battery drainages in portable devices.
Security	SPAs push the architectural boundaries of traditional applications, creating an opportunity to secure existing and new services required to serve SPAs without exposing sensitive information in the browser.	Exposure to critical business logic may be reflected in the browser.
User Experience	As load times are faster once the first page is loaded, the experience is cleaner for users navigating through different content. Some user journeys become streamlined and linear, maximizing the time the user spends on site.	Visitors might experience problems when using browser controls to go back in their history page if this behavior is not handled by the SPA.

SPA-based A/B testing and personalization

Most A/B testing software and personalization platforms rely on complete page loads to render experiences. As this concept is not present when using SPAs like React or Angular, when visitors request new page views, it becomes harder to determine if new content has been added to the page or if the status of existing content has changed – and most importantly, when to inject the personalized content.

A personalization platform must now understand the context of the visitor, i.e. whether they’ve landed on a product listing, detail, or cart page and at what stage the new content should be delivered. This requires keeping up with a constant state of changing modularised React SPA or Angular SPA components and updating the experiences affecting those components in real-time.

Overcoming common challenges in A/B testing and personalization with SPAs

Although not the traditional environment in which A/B testing and personalization has been known to thrive, advancements in technology to keep up with these emerging frameworks have been made to ensure businesses of varying architectures can still effectively implement tailored experiences.

Below, we’ll walk through a few ways that teams are adapting to better meet their SPA needs.

The server-side approach

REST APIs can be used to identify the content, or state of the SPA, to deliver experiences on the server-side. And depending on the platform, non-technical users should be able to define this content via the UI, where different types of variables can be created and fed to the SPA.

Furthermore, businesses can test different variations of the content according to their desired traffic allocation method, allowing them to optimize any given business metric for specific audiences.

The workflow is described in the following diagram:

The SPA sends an XHR request to the server to get the data to render a new page view or a dynamic component on the browser.
The server makes a REST API call to the personalization platform’s API to retrieve the relevant experience content.
The personalization platform evaluates the targeting conditions defined as well as any priorities, selects the appropriate variation, and then returns a JSON payload to the server with the correct content.
The server returns the personalized content to the SPA for rendering.
Any interactions with the personalized content are tracked by the SPA and passed to the server.
The server passes the interactions to the personalization platform’s API, and these interactions are used for reporting to provide results for the A/B test.

The middle layer approach

An alternative to the pure server-side approach, a personalization platform’s API can be implemented to make calls from the clients to update the state of the SPA components instead of directly from the server. This reduces response times even further as fewer trips are needed for the data to render the content.

Here’s how this would look:

The SPA middle layer sends an XHR request to the personalization platform’s API to get the data to render a new page view or a dynamic component on the browser.
The personalization platform evaluates the targeting conditions defined as well as any priorities, selects the appropriate variation, and then returns a JSON payload to the SPA middle layer with the correct content.
The payload received is passed to the SPA to set the new state of the SPA component.
All interactions are passed natively to the personalization platform using its Javascript tag, and these interactions are used for reporting to provide results for the A/B test.

In close

SPAs may become more widely adopted due to improvements in how content is processed and delivered, but it’s important to understand that this new technology does present challenges when integrating with optimization and personalization platforms, which typically work with more traditional MPA setups.

I hope this article has touched on the different aspects of SPAs as well as some alternatives to overcoming those challenges on your mission to delivering faster, more intuitive, and tailored digital experiences to visitors. However, it is recommended to partner with a solution provider that offers seamless support for single page applications, including the ability to automatically detect changes in UI elements and page types for dynamic personalization without interfering with the source code.