Flickering effect in Experiments

The flickering effect happens when your website loads its content first, then applies experiment changes a few milliseconds or seconds later. This causes the page to suddenly change appearance, resulting in a poor user experience.

Here's the sequence that causes it:

1. Your website loads its content.
2. The changes in your Experiments load asynchronously after a short delay.
3. The modifications are applied to the page — the content suddenly changes appearance (it "flickers").

What causes the flickering effect

The original basic integration solution has limitations that cause this issue. Changes made in an experiment sometimes appear with a few-second delay, so the visual change happens unexpectedly for the user.

To address this, a new approach to loading and applying experiments was developed. Non-flickering Experiments, sometimes called Guaranteed Experiments, display website changes instantly in real time, even when the website is dynamically updated. You can use this solution with either the Asynchronous or Synchronous integration solution.

Each approach has its own trade-offs. The advantages and disadvantages of each solution are described in Integrating and using experiments.

How non-flickering experiments work

In the original basic integration solution, all modifications were applied at once after the page reached "document ready" status. This created 2 problems:

1. The user was already on the website but couldn't see the changes yet because "document ready" hadn't fired, causing the flickering effect.
2. Modifications were applied only once. Those for which matching elements were found were applied in order, and the experiment ended.

The new non-flickering version initializes before any page content arrives. It monitors every change on the page and instantly modifies new content before it's rendered to the user. Your users only see the modified content; there is no flickering.

This also applies throughout the entire session, including dynamically generated content such as Single Page Applications and modal windows. As a result, experiment modifications may no longer be applied in the same order they were created.

Limitations and workarounds

The non-flickering solution is faster than the original basic integration solution in all aspects. However, the factors below can reduce its speed. Consider these factors and act accordingly.

Customer filter in experiments

If you use a customer filter in an experiment, the experiment may load slightly slower. The experiment becomes personalized and requires additional processing time to render for your users.

The experiment is fetched and loaded only after a second asynchronous request, which may be too late to prevent flickering.

📘

Note

If you're experiencing flickering with personalized modifications, consider using placeholders or transitions.

Jinja in experiments

Each experiment consists of one or more modifications. Modifications can be fast (also called constant or non-flickering) or slow (also called personalized or flickering). If a modification uses Jinja, it becomes personalized and is marked with an icon in the UI.

Marked modifications that use Jinja are loaded asynchronously via a second network request because their processing takes longer. All modifications in an experiment before the first slow modification are fast and applied instantly. All remaining modifications, including the first slow one and any after it, are loaded asynchronously and may flicker.

If you have a fast non-flickering modification placed after a slow personalized one, an orange icon with an exclamation mark appears, recommending that you move the fast modification above the slow one. Only do this if it doesn't affect the final result.

📘

Note

If you're experiencing flickering with personalized modifications, consider using placeholders or transitions.

Improve personalized modifications

Use placeholders

If you're serving personalized content, such as recommendations, use placeholders to improve the user experience.

Add placeholder content to your page using a fast modification, for example, an empty space or a few grey boxes. This placeholder content displays instantly without flickering and prevents the page from shifting when the personalized modifications load.

In your personalized modifications, replace the placeholders with the real content. You can also add a smooth fade-in animation to further improve the experience. Customers are accustomed to placeholders and expect content to follow when they see blank space.

The illustration below shows this approach. The first non-flickering modification adds 10 placeholders to the page, and a second slow modification (half a second later) uses Jinja to load the products for the specific customer.

Use the next page view

This approach saves the result of a slow modification that uses Jinja into localStorage. On the next page view, the data is read from localStorage and applied using a fast modification.

The trade-off is that the experiment doesn't apply to the first page view. The page shows content based on data from the previous page view. In most use cases, this trade-off is acceptable and still delivers a flicker-free experience.

Integrate non-flickering experiments

For details on integrating and using these solutions, see Integrating and using experiments.

Why use the new solutions

The new experiment solutions let you modify your website in a way that users don't notice it's being done by a third-party tool. Two challenges are addressed at once:

• Flickering effect: The website is modified before it's presented to the customer, so they see the final version immediately. This is covered in detail on this page.
• No performance downgrade: The website is not blocked beyond a predefined timeout, and experiments are applied as soon as possible. This is covered in Integrating and using experiments.