Skip to main content

Flicker management

What is flicker and why it can happen

Flicker is a problem commonly occuring with JavaScript based A/B testing solution. When your webpage is loading, it is possible that the original page displays for a split second instead of the variation. This twinkling is called flicker effect or flickering. Of course, this will confuse the visitor and can greatly distort the results of any experiment. Our platform includes built-in advanced techniques to completely eradicate flickering.

Usually, Flickering has two main causes:

  • the moment where the script is loaded and executed happens too late, when the browser has already displayed the page (or parts of the page). This is directly dependent on how Kameleoon has been implemented on your website. If Kameleoon loads too late or in a Tag Management System, nothing can be done to avoid flickering.
  • the engine processing the experiment's variations is too slow, or rather, do not execute and display modifications fast enough.

How to remove flicker in your experiments

To eliminate flickering due to the first reason, you need to implement either our synchronous tag or our asynchronous tag with anti-flicker prevention. These two methods guarantee that Kameleoon's code will be executed before any rendering of the page by the browser.

In the case of synchronous loading, this is guaranteed automatically as long as the tag is included in the HTML <head> section, since the browser will not display anything until the Kameleoon application file is downloaded and executed. However, loading any resource in a blocking way is not a good practice, and thus do not recommend this implementation method, but rather recommend implementing our asynchronous tag with anti-flicker prevention.

Technically, we include a "blocking CSS rule" hiding the entire page's contents and we remove this rule as soon as Kameleoon's application code has been loaded (less than 50ms on average), OR if the specified time out is reached (default at 1000ms), to prevent showing a blank page indefinitely, if the Kameleoon application file is still not loaded. This way, we guarantee that in no circumstances can Kameleoon ever bring your website down.


The timeout is controlled by the kameleoonLoadingTimeout JavaScript variable which you can set according to your needs (in the Kameleoon installation tag). By default it is equal to 1000 milliseconds, and we suggest leaving it as is. It represents the maximum amount of time the Kameleoon installation tag can "block" the display of your site while it is waiting for the Kameleoon application file.

What happens in the case of a timeout, once the Kameleoon code eventually loads, is up to you and is configurable in the advanced confirmation setting of your Kamleeoon project. You can either disable Kameleoon entirely (when a timeout occurs, no experiments or personalizations will be run for this particular visitor), or you can run Kameleoon's code normally (but since it will run late, flickering will occur). Note that if you don't change the default timeout value and under normal conditions (correct Internet speed), timeouts should be rare (2-3% of your visitors).

Even if you use a correct implementation method, flickering effects can still occur, if the underlying engine of your A/B testing solution is not optimized to avoid them. In the case of Kameleoon, we guarantee these optimizations for any modification done by our graphical editor tool. For avanced variations that use custom JavaScript code, we provide APIs to guarantee this as well, but you must of course use them. Any modification on an element, or waiting for an element to appear on the page, should be done via our JavaScript API method (namely Kameleoon.API.Core.runWhenElementPresent()), NOT via hand-coded pollers or other custom code.


When implementing JavaScript code for a variation, always try to think of which modifications you want to provide and on which DOM elements they will be applied. Then, once you have identified the CSS selector for this / these elements, enclose the actual modification call inside a callback that you will provide to Kameleoon.API.Core.runWhenElementPresent(). This has two important benefits: first you ensure that the code will be run at the exact right time, not before the elements are present in the DOM (which can of course lead to unexpected effects if your code is not carefully written). Second, you remove any risk of flickering effects.