The flicker effect in A/B testing: why it skews your results (and how to avoid it)

Updated on October 19, 2026

13 milliseconds. That's the time the human brain needs to identify an image, according to a study by neuroscientists at MIT published in 2014. However, the script for a client-side A/B testing tool often takes several hundred milliseconds to modify the page. During this time, your visitor sees the original version, then the variant. They have seen both. Your test, however, assumes they have only seen one.

This flicker effect introduces a systematic bias into your measurements, almost always to the detriment of the variant, and can lead you to discard a good idea or validate a bad one. This guide explains where it comes from, how much it actually costs, how to measure it on your own site, and how to eliminate it.

What is the flicker effect in A/B testing?

The flicker effect (or FOOC, "Flash of Original Content") is the brief display of the original page before the tested variant is applied, because the test script modifies the page after the browser has started to display it. The visitor perceives a jump: a title that changes, a button that changes color, a block that shifts.

This phenomenon is specific to client-side testing. In this model, the server always sends the same HTML page; it's a JavaScript file, loaded by the browser, that decides which group the visitor belongs to and rewrites the DOM accordingly. Until this script has been downloaded, interpreted, and executed, the control is displayed. If you're new to this vocabulary (DOM, variant, control, allocation), our glossary of A/B testing repeats each term.

Why Flicker skews your results

The flicker only affects one of the two groups: the control displays without artifact, the variant appears with a flash. Therefore, you are no longer comparing "design A versus design B", but "design A versus design B with a display defect". This is a bias, not noise: it does not cancel out by increasing the sample size.

Two mechanisms work against the variant:

1. Loss of confidence. A page that "jumps" suggests a poorly designed website. On a payment funnel or a quote request form, this impression alone is enough to raise red flags.
2. The comparison effect. The visitor has seen the old price, title, or image. If the variant tests a crossed-out price or a stronger promise, they see both versions, which changes their perception of the offer.

Sometimes, conversely, the element that "appears" catches the eye and amplifies the variant. In both cases, the result you read in your analytics dashboard does not correspond to what the variant would look like once deployed hard-coded, without a script. This is one of the underestimated sources of false positives (and false negatives) in A/B testing.

The 5 technical causes of flicker

The flicker appears as soon as the variant is applied after the first page rendering. Five factors, which can be combined, lengthen this delay.

1. The script location

A script placed at the end of <body> only executes once the rest of the HTML has been parsed: the browser has already displayed everything. It must be as high as possible in the <head>, before stylesheets and other third-party scripts.

2. Using a tag manager

Google Tag Manager loads its tags asynchronously. The test script therefore waits for the GTM container itself to be loaded, then triggered. Analyst Simo Ahava measured the discrepancy on the same site, with traffic split in two: the page remained hidden. 964 ms on average with the tag passing through GTM, compared to 581 ms with the snippet inserted directly into the page. Nearly 400ms lost solely due to the integration method.

3. Asynchronous loading

An asynchronous script does not block the display: this is its advantage for speed, and the reason why it produces flicker. We will return to this in the next section.

4. Script size and latency

A file containing the configuration for all account tests, including paused ones, takes longer to execute. If it's served from a server far from the visitor, each round trip adds tens of milliseconds.

5. The way the variant is coded

A modification that waits for an element to exist in the DOM before rewriting it (e.g., "replace the button text once it's loaded") will necessarily be applied after it has been displayed. WYSIWYG editors sometimes generate this type of code by default. The documentation for Optimizely recognizes it: its visual changes wait for the element to be available, which causes flashes when many changes are in the queue.

Synchronous or asynchronous snippet: the real decision

A synchronous snippet blocks the display until it executes: no flickering, but a white screen if the script is slow. An asynchronous snippet allows the page to load: no white screen, but flickering. There is no free third way.

Optimizely recommends loading the snippet synchronously while allowing certain variant modifications to run asynchronously. VWO (renamed Wingify in 2026) hides the body of the page while waiting for its library; Kameleoon highlights a "blocking asynchronous" integration.

The right choice depends on a single question: is your script's latency under control? If the file is small and served from a CDN close to your visitors, synchronous mode adds a few tens of milliseconds and eliminates the problem. Otherwise, every network slowdown results in a blank screen. This is the crux of the matter. ultra-fast variant delivery : make the blocking mode short enough to become imperceptible.

The anti-flicker snippet: useful, but it comes at a price.

An anti-flicker snippet hides the page (or part of it) using a CSS rule while the test script runs, then reveals it. It removes the visible Flash, but shifts the cost: the page is displayed later for everyone.

The principle is simple. A line of code placed at the top of the <head> applied opacity: 0 or visibility: hidden at <body>. When the tool applies the variant, it removes that rule. If the tool doesn't respond, a maximum timeout reveals the page anyway. The default values ​​​​are generous: the old snippet of Google Optimize waited up to 4 seconds, and the SmartCode of VWO / Wingify sets its tolerances at 2000 ms for settings and 2500 ms for the library.

These figures are significant. During this entire time, not a single pixel is painted. An audit published by DebugBear on AdRoll's homepage showed a Largest Contentful Paint (LCP) of 6.0 seconds with masking enabled, compared to 2.7 seconds once masking was disabled. Google considers an LCP above 2.5 seconds "needs improvement" and above 4 seconds "bad": a poorly configured anti-flicker can turn a healthy page into a negative result.

Three rules for using it without damage:

• Hide only the tested area (the hero block, the form), not the <body> entire. The rest of the page displays normally and the LCP is only affected if the hidden element is itself the LCP element.
• Shorten the timeout at 1000-1500 ms instead of 2000-4000 ms. Beyond that, a visitor who sees a blank page is more penalized than a visitor who sees a flash.
• Only enable masking on pages that host a test. An anti-flicker system loaded across the entire site penalizes thousands of pages that don't test anything.

Measuring flicker on your site: the A/A' method

To determine if the flicker biases your tests, run an A/A' test: two groups see the exact same page, but one receives an invisible modification applied by the test script. Any significant difference between the two groups measures the cost of the injection mechanism itself, independent of any marketing considerations.

A standard A/A operation isn't enough: no group undergoes any modification, therefore none experiences flicker. This is the method we recommend at BlastOptimize before launching a series of tests on a new site or a new page template.

The 4-step protocol

1. Create variant A' It applies a modification without visual effect to the element you intend to test (for example, rewriting the title text with the same text, or adding an attribute). data- (at the button). The technical path is identical to that of a true variant.
2. Instrument the delay Record the time between the first display (First Contentful Paint) and the application of the change. The excerpt below is sufficient.
3. Let it run through a complete cycle (at least 2 weeks to smooth out weekday/weekend effects) with your usual conversion target, as defined in your objective and tracking configuration.
4. Read two numbers : the median time and the 90th percentile (slow visitors), then the conversion gap between A and A'.

<script>
// À appeler dans le code de la variante A', juste après la modification
(function () {
  var fcp = performance.getEntriesByName('first-contentful-paint')[0];
  var applique = performance.now();
  var delai = fcp ? Math.round(applique - fcp.startTime) : null;
  // delai > 0 : la variante s'applique APRÈS le premier affichage = flicker visible
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({ event: 'flicker_delay', flicker_ms: delai });
})();
</script>

How to interpret

• Negative or zero delay The variant is applied before the first render. No flickering is possible.
• Median delay less than 100 ms : flicker rarely perceptible consciously, but sufficient to be seen (remember the 13 ms). Monitor the 90th percentile.
• Median delay greater than 300 ms Flicker is visible to most visitors. Do not run any tests on this page until the integration has been fixed.
• Significant conversion difference between A and A' The injection mechanism alone has a measurable effect. All your tests on this template suffer from this bias.

This figure gives the minimum effect size that can be interpreted on this page. If A/A' shows −2% for A', a variant that gains +1.5% may actually gain +3.5%, and a variant at −1% may be neutral.

9 concrete corrections, from the most profitable to the most costly

Most flickers can be fixed without changing tools: by moving the script, lightening it, and coding the variants in CSS rather than JavaScript. Here are the levers, ranked by effort/gain ratio.

1. Place the snippet at the top of the <head>, before CSS and other third-party scripts. Immediate gain, five minutes of work.
2. Exit the test script from Google Tag Manager. Integrate it permanently into the template. The 400ms difference measured by Simo Ahava comes from this.
3. Add a preconnect to the domain that serves the script (<link rel="preconnect" href="…">) to open the connection even before the browser encounters the tag.
4. Code the visual modifications using CSS. A CSS rule injected into the <head> applies as soon as the element is painted, without waiting for it to exist in the DOM. Change a color, hide a block, or reorder two elements with order using flexbox requires no JavaScript. This is also the recommendation in the documentation. Optimizely on the variants that flash.
5. Clean up the code generated by the visual editor : remove redundant selectors, group modifications on the same element, avoid complete rewrites of HTML blocks when a text change is sufficient.
6. Archive completed tests. Each paused test that remains in the configuration increases the file size for all visitors.
7. Only hide the tested area., with a short timeout (1000-1500 ms), rather than the entire page for 4 seconds.
8. Avoid redirection testing on pages with high inbound traffic. Redirecting to URL B after loading URL A results in two page loads: this is the most expensive form of flicker.
9. Serve the script from a CDN close to your visitors, with a configuration limited to only the tests active on the visited page. This is the lever over which you have the least control, as it depends on the tool: ask your provider or consult our page on script distribution BlastOptimize as close as possible to the visitor.

When to switch to server-side

Server-side testing eliminates flickering by design: the server chooses the variant and sends the correct HTML directly; no script rewrites the page in the browser. The downside is well-known: each test goes through a developer, the visual editor becomes unusable, and the iteration cycle lengthens. Server-side testing is justified for tests on structural elements (pricing algorithm, checkout process, navigation), for pages where even the slightest deviation in LCP is costly, or when your A/A analysis reveals a bias that the nine corrections mentioned above don't resolve. For title, visual, or button tests, a well-integrated client-side approach remains faster to implement. This architectural choice deserves its own guide, which we are dedicating to server-side testing.

Anti-flicker checklist before each launch

Before putting a test into production, check these ten points. Just one "no" on the first four is enough to postpone the launch.

• ☐ The snippet is hardcoded in the <head>, in first position among scripts, excluding tag managers.
• ☐ The loading mode (synchronous/asynchronous) is known and documented for this page.
• ☐ The variant was verified on a real smartphone with the network throttled to "slow 4G" in the development tools.
• ☐ The delay between first display and application of the variant is measured (median and 90th percentile).
• ☐ Visual modifications are done in CSS whenever possible.
• ☐ If masking is used, it targets the tested area and its timeout is ≤ 1500ms.
• ☐ The LCP of the page with and without testing was compared (target difference: less than 100 ms).
• ☐ Completed tests have been archived from the account.
• ☐ No redirection test is launched on a major entry page without a strong reason.
• ☐ An A/A' test was performed on this page template over the last 6 months.

Flickr is added to the list of common mistakes in A/B testing which invalidate a test even before statistical analysis. It is all the more dangerous on the multivariate tests, where several areas are modified simultaneously and where each combination can produce a different flash, and on the e-commerce sites, where product pages load many images and third-party scripts.

FAQ

Does the flicker effect have an impact on SEO?

Indirectly, yes. Flicker itself isn't a penalty, but poorly implemented fixes are: an anti-flicker that obscures the page degrades LCP (Low Page Content), and a variant that inserts blocks increases CLS (Cumulative Layout Shift). Both of these metrics are part of the Core Web Vitals considered by Google. Compare the field data from Search Console on tested and untested pages to verify this.

My tool claims to be "100% flicker-free": can I believe it?

Ask how. "Flicker-free" often means "with masking": the flash disappears, but the page loads later. Check three things: the snippet loading method, the masking timeout value, and the LCP difference measured with and without the script. An A/A test settles the matter on your own site. You'll find the differences in approach in our comparative BlastOptimize / Kameleoon and in our comparison with AB Tasty.

Does a synchronous snippet really slow down my site?

It delays the initial display of the script's download and execution time. With a small file served from a CDN, the difference is a few tens of milliseconds. With a large file or a slow server, it's hundreds of milliseconds, and a provider outage can block the page until the network timeout. Measure the LCP with and without the snippet before deciding.

Can I upload my A/B testing tool via Google Tag Manager?

Technically yes, but this configuration produces the most flicker because GTM loads its tags asynchronously. Published measurements show approximately 400ms of additional masking compared to a direct integration. Reserve GTM for triggering tracking events, not for the script that modifies the page.

Do consent banners worsen flicker?

They can. If your testing tool only loads after cookies are accepted, or if the consent management platform blocks scripts while it reads the visitor's choice, the application of the variant will be delayed accordingly. Check the execution order between the banner and the test snippet in a clean session, without cookies.

Key takeaways

• The flicker effect is the brief display of the original page before the variant. It is specific to client-side testing.
• This is not a simple visual defect: it systematically skews the comparison, because only one of the two groups suffers from it.
• The main causes are a poorly placed script, a passage through GTM, asynchronous loading, a file that is too large, and variants coded in JavaScript rather than CSS.
• The anti-flicker masks the symptom but delays the display: target the tested area and keep a timeout ≤ 1500ms.
• Measure before you correct: the A/A' test gives the true cost of the injection mechanism on your site.
• The server-side eliminates flicker by design, at the cost of a dependency on developers.

You want to see how BlastOptimize does it serve its variants? Check out our offers and prices to launch an initial A/A' test on your site.