The flash of original content (FOOC), also called flicker, is the split second when a visitor in an A/B test sees the original page before the testing script swaps in the variant.
It happens with client-side testing tools that change the page in the browser after it starts rendering.
Flicker hurts the visitor experience and can bias your results, so fix it before you trust a test.
What the flicker effect in A/B testing is
In a client-side test, the browser loads your normal page, and a JavaScript snippet then edits it for visitors in the variant.
If the page paints before the snippet finishes, the visitor briefly sees the control, then watches it change.
That might be a headline that rewrites itself, a button that jumps color, or a hero image that pops in a beat late.
Optimizely's documentation describes it plainly: when a testing script "is loaded much later than the page, a flicker of the page can occur when the original page loads, followed by the variation," which makes "the outcome of your experiment less reliable" (Optimizely docs).
Flicker only affects visitors in the variant. Control visitors see the page they would have seen anyway.
That one-sidedness is what turns a cosmetic glitch into a measurement problem.
Why flicker happens
The testing vendors' own help pages list the same handful of causes:
- The snippet loads asynchronously. An async script lets the page keep rendering while it downloads. That is faster, but the original content can paint first. Convert's help center says "the only guaranteed way to not flashing in most cases is to load the tracking code in sync mode" (Convert).
- The snippet sits in a tag manager. VWO (now Wingify) warns that adding its SmartCode through a tag manager set to asynchronous can make visitors see the control page for a moment before the changes appear (Wingify help).
- The snippet is in the footer, not the head. The later it runs, the more of the original page the visitor sees first.
- The variant has many changes, or heavy ones. Optimizely notes that variation code waits for each element to exist before changing it, so a long list of visual edits can flash (Optimizely docs). Wingify adds that large new images can leave the original visible while they download.
- Custom JavaScript changes. Visual-editor changes are hidden until applied, but hand-written code often is not.
Above-the-fold image swaps are the classic risk. A test like Dave Diederen's homepage hero image swap (+7.50% revenue per visitor) or Cro Metrics' high-contrast hero for Hivelocity (+180% CTA clicks) changes the very first thing a visitor sees.
Run that kind of change client-side with an async snippet and every variant visitor may see the old hero first.
How flicker biases your results
Flicker changes what the variant actually is. You meant to test "new hero image."
With flicker, you test "old hero image, then a visible swap, then a new hero image."
Visitors can notice the change, and some read it as a broken or slow site.
Speed alone moves conversion. In A/B tests that added artificial delays at Bing, every 100 milliseconds of difference had a 0.6% impact on revenue, according to Ron Kohavi and Stefan Thomke (Harvard Business Review, 2017).
Flicker, and the anti-flicker hiding that tries to cover it, both add delay to the variant only.
Our database shows the same speed effect on smaller stores:
- Vasta's native header test for Canada Welding Supply replaced a third-party app header that loaded extra JavaScript with a theme-native one: +17.02% conversion rate and +6.44% revenue per visitor in a 50/50 split over 14 days.
- Oliver Kenyon rebuilt a landing page natively in Shopify and tested it against the identical page in a page builder: same copy, images and offer. The native build won with +9.9% conversion rate and +20.9% revenue per visitor.
- Vasta's PageSpeed work for a supplement brand took mobile Lighthouse from 35 to 92 and reported +20% conversion rate. That was a before/after comparison, not a split test, so treat it as weaker evidence.
None of these were flicker tests. They show that how a page loads, separate from what it says, can move results by double digits.
So a variant that loads visibly worse than control starts with a handicap.
The bias can run either way. A flicker can hurt the variant by making it feel broken.
It can also help it, because movement draws the eye to the changed element, a little like a novelty effect.
Either way, the result no longer measures the change you designed.
@oliverkenyon
Vasta
@DaveDiederenVastaHow to fix A/B testing flicker
Work through these in order. The first few are free and fix most cases.
1. Put the snippet in the head, loaded synchronously
Place the testing tool's script as high in the <head> as possible, directly in the theme or template, not through a tag manager.
Optimizely's web snippet is synchronous by default for this reason.
The trade-off: a synchronous script blocks rendering until it loads, so a slow CDN response delays the whole page for everyone.
2. Use the tool's anti-flicker setting, with a short timeout
If you must load asynchronously, anti-flicker code hides the page (or just the changed elements) until the variant is applied or a timeout runs out.
Convert's sample async code uses a 500 millisecond timeout and tells you to adjust it.
VWO's SmartCode has two timeout settings, settings_tolerance and library_tolerance, which default to 2,000 and 2,500 milliseconds (VWO help).
Google Optimize's well-known snippet defaulted to a 4 second timeout.
Andy Davies at SpeedCurve showed how that delays first paint and found bounce rates rising the longer pages stayed hidden (SpeedCurve, 2022).
Optimize itself shut down on September 30, 2023 (Google), but copies of that snippet still sit in many site headers. If yours has one, remove it.
3. Move visual changes into CSS
CSS applies as soon as it loads; JavaScript has to wait for elements to exist.
Optimizely recommends moving visual changes to CSS set to synchronous timing to reduce flashing.
Hide only the elements you change, not the whole body.
4. Make the variant lighter
Compress new images, preload the main one, and keep the number of edits small.
A test that rewrites half the page in JavaScript is better run another way.
5. Move the test off the browser
Server-side tests, edge tests and theme tests decide the variant before the HTML reaches the browser, so there is nothing to swap and nothing to flash.
See server-side vs client-side testing and feature flags.
Split URL tests avoid flicker on the page itself but add a redirect, which is its own delay for the variant.
| Fix | Stops flicker? | Cost | Wrong choice when |
|---|---|---|---|
| Synchronous snippet in head | Mostly | Blocks rendering for all visitors while it loads | Your tool's CDN is slow or your page speed is already poor |
| Anti-flicker hiding | Hides it | Delays first paint, mainly in the variant | The timeout is long (seconds), or it hides the whole body for a small change |
| CSS instead of JavaScript | Often | Developer time | The change needs logic or new content, not styling |
| Server-side or edge test | Yes | Engineering setup | You only run a few simple copy tests a year |
| Split URL test | On-page, yes | Adds a redirect to the variant | The redirect is slow or breaks tracking parameters |
How to check whether your test flickers
Most people never notice flicker because they test on a fast office connection. Check under worse conditions:
- Force yourself into the variant with the tool's preview link, then load the page in an incognito window.
- In Chrome DevTools, throttle the network to a slow mobile profile and disable the cache. Record the load in the Performance panel and step through the screenshots.
- Repeat on a real phone on mobile data.
- Compare paint timings (first contentful paint, largest contentful paint) for control and variant. A gap means the variant is slower, even if it does not visibly flash.
Add this to your A/B test QA checklist.
An A/A test run through the same setup is a good way to confirm the snippet itself is not skewing traffic, and a sample ratio mismatch check catches cases where slow loading drops visitors from one arm before they are counted.
When flicker does not matter much
A brief flash below the fold, on a change the visitor scrolls to seconds later, rarely matters.
Neither does a test where the snippet reliably finishes before first paint.
It matters most for above-the-fold changes, mobile traffic, heavy pages and tests on Shopify stores with many apps already competing for load time (see A/B testing on Shopify and page speed and conversion).
If a test in one of those situations produces a surprisingly large win or loss, check for flicker before you ship it.
Browse more results in the test database or start from the A/B testing guide.