In this tutorial, you will learn a little more about the Optimizely Web snippet and the different options you have available to you when adding it to your site. By the end of this tutorial, you will learn about two concepts, the flicker effect and render-blocking, you will also be a master in understanding how both of these things can impact your experiments. To enable Optimizely Web within your site, you need to include a JavaScript snippet. Whenever you embed any client-side JavaScript onto your page, you need to consider page performance. Any script can potentially degrade your page load times and penalise your web vitals score.

When you run any browser-based experiments, something called the flicker effect can occur. Flickering, also known as FOOC, or, Flash of Original Content is a user experience issue. The flicker effect occurs due to latency. The effect occurs usually after the page has loaded. The experiments changes need to be applied on top of the original page layout. When this happens, the site visitor may see a sudden layout jump. If the experiment contains a lot of changes, this jump might be very dramatic and noticeable. The flicker is giving your site visitors a glimpse behind the curtains as to how your page works, not very professional! For a contrite example, let us say that the experiment takes 2 seconds to load. The user will see a noticeable page flicker after 2 seconds when the experiment is loaded.

For the majority of websites that use Optimizely Web, no notable flicker will ever occur. A small majority of websites may be impacted by a flicker, so this raises the question, what causes a flicker on some sites? Like the old saying, how long is a bit of string, there is no simple answer. The reason why a flicker may occur will be based on a combination of your tech stack, your content, and the experiments you are running. There are a number of strategies that can be used to either eliminate or greatly minimise the flicker effect so that it is noticeable on your website. Before thinking of solutions, you will need to understand the trade-off between performance and usability. This is what you will learn today 🔥🔥🔥

Usability Vs Performance

In one extreme, you could stop the whole page from being loaded until the experiment is ready to rock N roll 🤘. Doing this would completely eliminate the flicker, however, your pages web vital score may crash and burn. If a user is presented with a blank page for many seconds, research proves they will hit the back button and leave your site. Blocking page rendering completely until the experiment loads would stop the flicker, however, it might give a worse overall experience. In a perfect world, you will want a solution that provides the best of both worlds, fast page loads and no flickering. How do we achieve this?

The Render Blocking Problem

The problem with preventing the page from loading until the experiment has been loaded is known as render-blocking. The two main culprits for render-blocking are scripts and stylesheets. By loading the Optimizely Web tag before anything else on the page you are adding some level of render-blocking on your page.

The Optimizely script has been designed to be very small and performant, however, in simple terms, all web experimentation tools need to load some code on page load in order to launch an experiment. If your site is super speedy, this delay might only be a few milliseconds and the impact is not noticeable. If your site already experiences sub-optimal page performance, this extra time may only exacerbate page performance 😔. If your page has other rendering blocking calls, the time it takes for the page to load might not be what you hoped it to be. During this loading time, the data says your site visitor will feel frustrated and leave. This is why finding the right balance is key. You want no flicker and no delays in page load.

Unfortunately, there is no one-stop solution that can be applied to every website that will prevent this issue from happening. Anyone claiming anything different is telling porkie pies 🥧🥧🥧. The strategy that best suits your website, will be based on what your website does, how it's been coded and your business goals. Optimizely web does not try to force you down a path. Instead, you have access to a number of strategies that you can pick from to best solve the problem in a way that makes sense to you. You can take one of two approaches to resolve this dilemma. The first lot of approaches will minimise the flicker, however, it may impact page performance. The other approaches will improve page performance but increase the chances of a user seeing a flicker. We will start by reducing the flicker problem 💥

Tips To Reduce The Flicker Effect

To remove a flicker there are several approaches you can adopt. The most common cause is the placement of the Optimizely code snippet on the page:

<head> First: The defacto way of adding Optimizely Web into your page will be to add the snippet to your HTML files within the head section. The Optimizely Web snippet is very small, about 60kb in size. It is recommended to add the tag immediately after the pages <head> tag. This will ensure the script loads before any intensive external resources like, JavaScript libraries, fonts, and style sheets are called. For 90% of the clients, this pattern will eliminate any flickering. Usually, the changes are applied so quickly that it is not noticeable to the end-user. Job done 💥

Optimizely Performance Edge: Optimizely also provides an alternative way of adding the snippet onto the page, one that can help reduce the bundle size, Performance Edge. In Performance Edge, code is stripped out of the JavaScript bundle and instead injected during the request. This means the amount of data in that initial script call is reduced. The smaller the bundle size, the smaller the impact of the flicker. When you create a performance edge test, a lot of the code that is usually called in the Web snippet is applied at the edge node layer (CDN). Using this approach will quicken the time it takes for an experiment to load on the page.

The only main trade-off with using a Performance Edge project is that you can not use any of the personalization features available within Optimizely Web. Audiences and segments can only be calculated in the browser, so these features will not work so be warned 🙃

Optimizely FullStack. Flickering is an issue with browser-based experimentation. One way to eliminate the flickering problem is to use an experimentation tool that is not susceptible to flickering. All browser-based tools will experience flickering, however, server-side experimentation tools like Optimizely Fullstack will not experience flickering. Using code-based server-side experiments will allow you to go much deeper within your codebase. Changes will be applied before the page is sent to the client, completely eliminating the flicker.

The big limitation of this approach is that it is code-based. This means you will need input from your developers. You will need to rely on the technical team to create the experiments for you. The great thing about the Optimizely Web visual editor is that non-technical people can run experiments. Clicks, not code 🔥🔥🔥. Depending on the type of company you work within, the ethos of senior management, your budget and the availability of developer resources then Full Stack can be a great solution to completely resolve this issue. The companies that are the most mature with experimentation tend to use a mix-n-match approach. Using both FullStack and Web where best suits their needs.

Optimization: A web experimentation tool is not the only thing that can cause render-blocking on a page. If your web pages take a long time to load before you try experimentation, then no matter how much tweaking you do, you will still bump into issues. Caching, image compression, static-site generation, simplification, minimising bundle sizes (CSS and JS), and removing unneeded requests are all tools that a developer can use to improve performance. Removing any other render-blocking JavaScript that is referenced from your web page, will help improve page performance. Another tip is to use preconnect to cdn.optimizely.com for faster synchronous loading. See this article for more information

Eliminate Unused Experiments From Your Bundle: The more tests you run on a page the bigger the bundle size will become. The aim of using an enterprise-level web experimentation tool is to run lots of tests. I have personally run over 100 tests concurrently in production using Optimizely Web with no noticeable issues. It is recommended to have good hygiene habits. Do not leave unused, unuseful or previously completed tests running for no reason. Leaving tests running that are not giving you good data, will only impact performance and increase the chance that a noticeable flicker effect will occur.

Tips To Reduce The Render Blocking Issues

On the flip side of the coin, you may be experiencing a long delay before your page loads. To fix these types of scenarios, you need to prevent a render block. Lighthouse flags two types of render-blocking URLs: scripts and stylesheets. When you add the Optimizely Web snippet at the top of your head section, some level of page render-blocking will happen. If for whatever reason rendering blocking is a massive problem in your project, you can make the Optimizely snippet request asynchronously. The trade-off with these approaches is the increase of a flicker.

*NOTE: These tips do not follow Optimizely best practices as it increases the chance of flicker, so be warned 🤪

defer and async: Using vanilla Javascript alone, you could apply the defer attribute onto the script tag. The defer attribute can be used to indicate that the browser should run the script after the document has been parsed. This will prevent any page render-blocking. To defer a script is done like this:

It is also possible to decorate your script tag with the async attribute. With async, the script gets downloaded asynchronously. The script will be executed as soon as it’s downloaded. This differs from defer whose script will be loaded after the page load event has been triggered

Tag Manager: If you use Google Tag Manager on your site, you could add the Optimizely snippet within Tag Manager. Adding the script here will mean that it is only fired after the page has loaded. This will prevent render-blocking as it will be loaded after the page has been laoded💥

That covers the problem and the potential solutions. As you can see it is not a simple yes/no question in terms of render-blocking with script tags. I recommend finding the best middle-ground path and using that. Happy Coding 🤘