How does personalization impact site speed?

Marketers and developers have a reputation for not getting along. However, if there is one thing that they agree on, it’s site speed - and how crucial it is. According to a study by Akamai, a 2 second page load delay leads to a 103% increase in bounce rates. It is even worse for mobile visitors: almost 53% of your mobile visitors are likely to leave a site that takes longer than 3 seconds to load. You snooze, you lose.

The damage is not only limited to your bounce rate. A slow website affects your conversion rates, cart abandonment, user experience and even your SEO. As a result, many SaaS tools have taken steps to improve load times of their services. Yet, A/B testing and personalization tools haven’t done a good job handling this issue in the past … and so the fear remains.

Server side versus client side

There are two kinds of personalization tools:

• Server side
• Client side

The server side tools are usually part of a content management system (CMS). The main issue here is usually not speed, but cost - this kind of platform typically needs to be hosted by you and replaces your existing system entirely. And that’s expensive, and usually a permanent decision - even if you don’t like it after all.

Therefore, the majority of on-site personalization- and A/B testing services take a client-side approach. This kind of SaaS can be implemented with a single script snippet on top of any existing system or CMS. That’s a huge advantage: you could change your mind and remove the service without replacing your entire system again. But… speed can be an issue here.

How does client side rendering work? Your original page gets loaded as usual, the snippet executes and then the personalized content will be injected on top of your existing page, right there in the visitor’s browser. Of course, a variation can only replace existing content if that content is already there. So, it’s essentially a two-step approach.

When it comes to speed, this could lead to two negative outcomes. First of all, a badly designed script could slow down your website. Secondly, your visitors may see the unmodified (or original) versions of elements before the changes are injected. For example, they see one headline before it quickly changes to another text. This is called “flash of unrendered content” (FOUC) or “flicker” and is annoying - and it could even bring the accuracy of your test results into question.

What determines speed at Unless?

Rendering speed (or how fast a variation of your page is loaded for your visitor to see), depends on a couple of things.

Synchronous versus asynchronous snippets

If a script snippet loads synchronously, it means that it loads while your web page has to wait for it to finish. So, your web page is temporarily blocked. As opposed to that, if the snippet loads asynchronously, it loads while your web page keeps on loading in parallel. In theory, the latter is superior… but what if your website is faster than the snippet? In that case, you would see a flicker of unrendered content.

Unless uses a combination of tactics to create a best-of-breed solution here. Our snippet loads the required script and personalized data asynchronously, so it doesn’t block your web page. At the same time, this loading is heavily optimized to make sure all assets will be there when your website is done. Over 99.8% of all our customer websites do not show any delay, simply because the load time of the page is longer than our snippet needs to do its thing.

Why is it so fast? Well, for example, we start replacing personalized elements while the existing page is still loading. So, we don’t wait until it is finished. We can do this because we only store the smallest pieces of data: the personalized “delta”. It means that we only store the difference between your original page and the personalized version. This could be just a few words or an image, and smaller data is faster.

The technology that we use for that is very similar to for example Google Docs, where two people can work on a single document at the same time. They see each other’s changes as they type… but that is not really true. Technically, Google sends the small “deltas” over the line very quickly, so it looks like it is live. We do the same. And it is super fast.

For our smart add-ons, it’s even better. Our bars, overlays and side boxes don’t need to wait for your website to be ready at all. Our widgets are entirely asynchronous and non-blocking. Your website will show with its normal speed and the add-ons will appear once your website is ready.

But how can we load our assets so fast? Well, our delivery infrastructure is incredibly efficient.

Effective use of a global CDN

Typically, a snippet for personalization or A/B testing loads a script first. This script will then ask for personalized data, by calling the underlying system of the service. The service will respond with personalized content and the script adds the new variations to the page. Of course, this can only be fast if the delivery of scripts and data is blazing fast.

Now the question is, how does Unless deliver variations? Well, your personal script and all your published content is saved as flat files in AWS S3. That’s like a big hard drive. So, there is no software that we need to run to deliver it and the chance of breaking it is therefore really small. From there, we deliver your content to your website visitor via Cloudfront - the global Content Delivery Network (CDN) of Amazon.

CloudFront leverages a global network of 150 Points of Presence (139 Edge Locations and 11 Regional Edge Caches) in 65 cities across 29 countries. If one of the edge locations goes down, the network automatically selects the next best edge location to serve your content. This literally means that the content is always nearby and therefore fast. Additionally, since there are no servers or running software involved in serving your content, we estimate a minimum of 99.99% uptime. And that's a conservative guess.

The servers - or lack thereof

A critical part of any system is the running software. If your server cluster is slow, the response times of any system will drop and your pages will load slowly. This is the reason why we do not use servers at all!

Unless is famous for a serverless approach to software. We are an early adopter of Amazon Web Services cloud infrastructure. This time however, we chose to do things a little differently. Our entire system runs without any EC2 or RDS cloud server instances that could potentially crash or get stuck. We built an entirely serverless product, based on AWS Lambda functions only. You could think of Lambdas as a bunch of extremely fast, independent functions that only pop up if you need them, while they are not even there if you don’t. Oh, and did I mention that at Unless, they are globally available?

What does this mean for you as a user of Unless? What isn’t up, can’t go down - and so the chance of downtime is nearly zero and the response time is super short. We built this infrastructure in order to ensure that Unless is always fast and reliable.

But what about our database? This can still spoil everything, right?

The giant datastore that we share with Netflix

For databases, the same applies as to servers. If they are clogged, really big or overstimulated, they tend to slow down. This could easily happen with seasonal fluctuations or campaign peaks.

At Unless, we built for scale. All live data lives in DynamoDB. This is the major non-relational database service with top-notch security procedures that we share with big players like Amazon, Netflix, and Twitter. So, if you can still watch your favorite shows, Unless works.

DynamoDB is configured to use Global Tables in the same regions as the system itself, as a multi-region, multi-master database, giving us a very consistent performance across the world, no matter where you are located.

Wait, but what about privacy?

Something that doesn’t have anything to do with speed is privacy. However, when a system is distributed across the world because of speed requirements, this typically also goes for data. This may harm your privacy, because laws may be different everywhere. As a result, we chose a different approach for personal data.

Our data warehouse contains pseudonymized visitor data for analysis purposes. It powers your dashboards, so speed is less important than live personalization in your website. We can therefore store this data in a single location instead. Europe has the strictest laws. So, for privacy compliance reasons, we keep our data warehouse in Ireland. We’ve got your back.

Conclusion

Site speed is a matter we take very seriously and we know you do too. We run plenty of tests to ensure that your speed does not get affected by your use of Unless. We hope to have informed you thoroughly on the various components that may impact speed and how Unless deals with them all.

If you’ve got any more questions please reach out to us!