When we announced a major innovation a couple of weeks ago, the small world of A/B testing was all shaken up. It’s true that we tackled a problem with big consequences: the Flicker effect. We’re glad that our innovation created such a buzz. Our customers gave us very positive feedback on our new technology which was automatically implemented on their sites and showed immediate results. Other industry players also took the time to analyze the subject and share their comments. But we realized that there was a major incomprehension on the scope of our new technology. We aim at giving new impulses and making the debate more constructive. That’s why we decided to unveil some details on the way our new, 100% Flicker-free technology works.
100% Flicker-free: true or false?Quick recap: The Flicker effect is when on an A/B tested page, users see the reference version before the variation builds up. Let me insist: Kameleoon’s new 100% Flicker-free technology really is an innovative solution to the Flicker effect on your sites! There’s one thing all experts agree upon: The Flicker effect is induced by A/B testing solutions. We wanted to go beyond best practices that reduce the risk, and decided to attack the problem at its root and solve it once and for all. Some will tell you that there is no miracle solution. But we believe that one should always try to go beyond the status quo and find innovative solutions for widely spread problems – such as the Flicker effect. “If I had asked people what they wanted, they would have said faster horses.” – Henry Ford, Founder of the Ford Motor Company
Where does the Flicker effect come from?There’re really two reasons for the Flicker effect. This information is essential to understand how our new 100% Flicker-free technology works.
A. Users: what you can doFirst, the Flicker effect can be caused by the loading of the script itself and the moment when it becomes available and is ready to execute the necessary changes on the pages of your site. Best practice offered by A/B testing tools primarily treats this issue (but beware, not all advice is good advice, as we’ll see later on). One thing’s for sure: The earlier your A/B testing script is available, the better. Different factors impact this first reason for the Flicker effect (the first two in the list below are the most important ones, as they’re linked to the way the script is integrated into your site's code):
- Script hard-coded into the header of your site vs integration via a tag manager
- Position of the script, in the page and with respect to other tags (top/bottom of the page…)
- Weight of the script and performances of the hosting server (the lighter the script and the stronger the server, the faster the script is loaded by the visitor’s browser)
- The browser’s caching capacities
B. A/B-Testing solutions: what they should provideThe second reason for the flicker effect is induced by the way the A/B testing solution interacts with the web page to implement changes. One could think that once the page has loaded, the risk of a Flicker effect disappears. But it doesn’t. The factors that reduce the risk are the quality of the code of the software and the technologies it uses. The A/B testing solution should use as little CPU and RAM as possible while offering the fastest possible interaction with the necessary elements of the page. Our new 100% Flicker-free technology concentrates on the second reason only.
A new 100% Flicker-free technology, available without additional installation and compatible with 92% of all browsers.Our technological innovation impacts the way Kameleoon interacts with the elements on the page once the script is available. The difficulties linked to the refreshment cycle of the browser have been taken into account. Changes are directly applied to the elements as soon as they appear on the page, without need for a white page, and without the risk of your website crashing. For the geeks out there: our technology is based on the DOM Mutation Observers standards, as some of you have correctly guessed (well done, guys!). It’s an industry standard implemented in all (mobile and desktop) navigators supported by Kameleoon, apart from IE 9 and 10 (which raise other issues as well, but here’s not the place to discuss them).
That means that the new Flicker-free technology is compatible with 92% of all existing navigators.More good news: No change of code is needed to benefit from this new technology, it’s available automatically. If the browser isn’t compatible, the Flicker-free technology simply won’t be installed, and your tests continue to run normally. You just run the risk of the Flicker effect, but no more than with any other A/B testing tool. In short, Kameleoon’s new Flicker-free technology is a great improvement, without negative side effects.
So what about best practices?The performances of the new technology we developed put an end to the Flicker effect. But some rules must also be respected. Most of them are well known, some need to be revised. In order to limit the Flicker effect you should follow some advice:
- Install the script of your A/B testing solution as high up as possible in the header of your site.
- Install the script using the asynchronous blocking integration as explained above. If your solution doesn’t offer this integration, we still recommend not using synchronous script. It gives better results for preventing the Flicker effect than an asynchronous script would (not as good as an asynchronous blocking integration though), but it creates the (although small) risk of crashing your entire site!
- Don’t use tag managers, in order to keep control of the order in which scripts load.
- Reduce the size of the script. Kameleoon developed pre-processing a couple of years ago that accelerates the script by loading only what is strictly necessary. If, for example, your A/B test does not need advanced targeting, there is no need to load the corresponding criteria.
- Optimize the loading time of your site and all its elements.
- Use a CDN to accelerate script loading.
- Use style sheet whenever possible. It hardly makes any difference if you use Kameleoon, you are free to choose the implementations that suit you best, without worrying about performance which is taken into account automatically.
- Don’t use jQuery. Kameleoon doesn’t use external libraries, thus reducing the size of the script even further. New sites (many among you are overhauling your websites at the moment) are based on new frameworks such as Angular or React, which most of the time makes jQuery an unnecessary burden. Moreover, you should be careful: If your site already uses jQuery, it may not be sufficient to withdraw it from you’re A/B tests. If the jQuery script loads later, you can still have a Flicker effect. Such unnecessary worries!
ConclusionBest practices offered by editors should be followed. Without these rules, even the most innovative technology can’t hold its promises. Our aim is to deliver continuous innovation to our customers. Thanks to our technology, they went from an already relatively small risk of Flicker effect to the total absence of it. And that’s a major improvement! ?
Ces articles pourraient vous plaire