Not all products are created equal. While we repeatedly buy some products almost mindlessly, for others, we take a lot of time to make a purchasing decision. For a price tag that meets a certain threshold or if we are particularly invested in the quality of a product, we want to be absolutely certain that we are making the right choice and are getting a good product for a good price.
We talk a lot about marketing strategy on this blog. But today, we are getting technical.
In this post, I team up with WiderFunnel front-end developer, Thomas Davis, to cover the basics of server-side testing from a web development perspective.
The alternative to server-side testing is client-side testing, which has arguably been the dominant testing method for many marketing teams, due to ease and speed.
But modern web applications are becoming more dynamic and technically complex. And testing within these applications is becoming more technically complex.
Server-side testing is a solution to this increased complexity. It also allows you to test much deeper. Rather than being limited to testing images or buttons on your website, you can test algorithms, architectures, and re-brands.
Simply put: If you want to test on an application, you should consider server-side testing.
Let’s dig in!
Note: Server-side testing is a tactic that is linked to single page applications (SPAs). Throughout this post, I will refer to web pages and web content within the context of a SPA. Applications such as Facebook, Airbnb, Slack, BBC, CodeAcademy, eBay, and Instagram are SPAs.
Defining server-side and client-side rendering
In web development terms, “server-side” refers to “occurring on the server side of a client-server system.”
The client refers to the browser, and client-side rendering occurs when:
A user requests a web page,
The server finds the page and sends it to the user’s browser,
The page is rendered on the user’s browser, and any scripts run during or after the page is displayed.
The server is where the web page and other content live. With server-side rendering, the requested web page is sent to the user’s browser in final form:
A user requests a web page,
The server interprets the script in the page, and creates or changes the page content to suit the situation
The page is sent to the user in final form and then cannot be changed using server-side scripting.
In laymen’s (ish) terms:
When you visit a SPA web application, the content you are seeing is either being rendered in your browser (client-side), or on the server (server-side).
Basically, the page is incomplete upon arrival, and is completed within the browser.
If the content is being rendered server-side, your browser receives the application HTML, pre-built by the server. It doesn’t have to fill in any blanks.
Why do SPAs use server-side rendering?
There are benefits to both client-side rendering and server-side rendering, but render performance and page load time are two huge pro’s for the server side.
(A 1 second delay in page load time can result in a 7% reduction in conversions, according to Kissmetrics.)
All of which to say, with a complex application, client-side rendering can lead to sloooow initial load times. And, because client-side rendering relies on each individual user’s browser, the developer only has so much control over load time.
Which explains why some developers are choosing to render their SPAs on the server side.
But, server-side rendering can disrupt your testing efforts, if you are using a framework like Angular or React.js. (And the majority of SPAs use these frameworks).
The disruption occurs because the version of your application that exists on the server becomes out of sync with the changes being made by your test scripts on the browser.
NOTE: If your web application uses Angular, React, or a similar framework, you may have already run into client-side testing obstacles. For more on how to overcome these obstacles, and successfully test on AngularJS apps, read this blog post.
Testing on the server side vs. the client side
The original page loads, the content is hidden, the necessary elements are changed in the background, and the ‘new’ version is shown to the user post-change. (Because the page is hidden while these changes are being made, the user is none-the-wiser.)
As I mentioned earlier, the advantages of client-side testing are ease and speed. With a client-side testing tool like VWO, a marketer can set up and execute a simple test using a WYSIWYG editor without involving a developer.
A Quick Hack
There is a workaround if you are determined to do client-side testing on a SPA application. Web developers can take advantage of features like Optimizely’s conditional activation mode to make sure that testing scripts are only executed when the application reaches a desired state.
However, this can be difficult as developers will have to take many variables into account, like location changes performed by the $routeProvider, or triggering interaction based goals.
To avoid flicker, you may need to hide content until the front-end application has initialized in the browser, voiding the performance benefits of using server-side rendering in the first place.
Here is an example where we are testing a pricing change:
“Ok, so, if I want to do server-side testing, do I have to involve my web development team?”
But, this means that testing gets folded into your development team’s work flow. And, it means that it will be easier to integrate winning variations into your code base in the end.
If yours is a SPA, server-side testing may be the better choice, despite the work involved. Not only does server-side testing embed testing into your development workflow, it also broadens the scope of what you can actually test.
Rather than being limited to testing page elements, you can begin testing core components of your application’s usability like search algorithms and pricing changes.
A server-side test example!
For web developers who want to do server-side testing on a SPA, Tom has put together a basic example using Optimizely SDK. This example is an illustration, and is not functional.
In it, we are running a simple experiment that changes the color of a button. The example is built using Angular Universal and express JS. A global service provider is being used to fetch the user variation from the Optimizely SDK.
Here, we have simply hard-coded the user ID. However, Optimizely requires that each user have a unique ID. Therefore, you may want to use the user ID that already exists in your database, or store a cookie through express’ Cookie middleware.
Are you currently doing server-side testing?
Or, are you client-side testing on a SPA application? What challenges (if any) have you faced? How have you handled them? Do you have any specific questions? Let us know in the comments!
A term used to describe test methods or algorithms that continuously shift traffic in reaction to the real-time performance of the test. Also known as “multi-armed bandit testing”, the name is derived from the behavior of casino slot machine players who often play several machines at once in order to optimize their payout. Rather than stay with a single machine, the gambler will often play some percentage of the time on several other nearby machines. In this way, the new “hot” machine can be identified without leaving the original machine behind. When used in website testing, bandit testing represents a…
As more of our interactions — both business and personal — migrate online, intuitive design and user experience have never been more important.
The fast pace at which the digital world is changing means there’s always a new trend on the up and up promising to skyrocket our results.
Last year we saw the rise of mobile-first design, full-width hero images and user-driven storytelling. This year we’re seeing a big push toward hyper-personalization, bots and even (shameless plug) targeted overlays.
Ultimately, though, we marketers are most interested in trends that make the most impact where it truly counts… conversions.
The brilliant folks at The Deep End Design have whittled down the ever-growing list of design and UX trends to bring you only the most promising ones.
Of course, as with all trends, we don’t truly know their worth until we can test them out for ourselves. So don’t take this list as gospel. Rather, use it as a jumping off point when planning initiatives for the upcoming quarter and beyond.
If you’re running a pay-per-click (PPC) traffic campaign, there’s a big chance that you’re sending that traffic to a landing page. Though when using PPC traffic, you can’t just throw up a landing page and expect everything to work out for the best. Rather, you need to ensure that you’re optimizing your landing page for conversions. If you don’t do this, your landing page will never reach its highest potential. In this post, we’re going to cover how you can optimize a PPC landing page. We’ll take a look at the different elements that you need to focus on and…