SPA’s – The Next Big Challenge for A/B Testing

Blog / 10 Aug 2015

Tags: A/B Testing / CRO / UX

Page load times are becoming increasingly more important for both conversion rate optimisation and search engine rankings, meaning companies are increasingly moving towards new website technologies. One of these technologies is the SPA - Single Page Applications, which pose a sizeable challenge for A/B testing.

What are Single Page Applications?

So firstly, what are SPA’s? Well with traditional websites, when you click a link, you will be served a different page with a unique URL where you can visibly see that new page is loading. In SPA's all the content can be on the one page within a single URL and loaded all at once upon first visiting. So when you click a link within an SPA, content that has already been loaded is effectively turned on or off within that same page and is served instantly. For an example of a modern SPA click here.

A/B testing with Single Page Applications

Due to this new technology, SPA's are causing problems for A/B testing tools as the tool’s code snippet will only load once and will not reload when the visitor performs an action such as clicking a link, as there is no URL change. Although many of the tools are playing catch-up, leaders in the field have introduced a workable solution which allows experiments to be manually activated and called upon via API calls, which, although messy and convoluted, does enable you to make them fully functional.

The second challenge that A/B testing with SPA's face is building the variation code. SPA's are built using JavaScript libraries and frameworks such as Angular JS or Knockout JS, which are an entirely different code to JavaScript itself. Nine times out of ten, variation code will have to be built in this framework language rather than traditional HTML/CSS/JavaScript in order to interact with the page’s elements. This renders all WYSIWYG tools useless as tool visual editors can’t illustrate the code. Also, when it comes to building variation code from scratch, developers will have to know the library or framework language. This is problematic for developers who didn’t build the website, but who work within a conversion rate optimisation team that are tasked with building the variation code. These teams will either have to learn the site’s new programming language or pass the variation implementations back to the development team that built the website.

For the moment, Solution Engineers from companies like RedEye have to be versatile and adapt to each client’s website, learning its native language while continuing to research and implement innovative ways to work with SPA's. Although many companies may not yet have the courage to move to SPA's, when they do we can only hope A/B testing tools will have caught up with greater integration, to work with SPA's seamlessly as if it were a traditional site.

Watch this space for developments on SPA's and A/B testing!