If you’ve ever run a client-side A/B test, you’ve probably encountered the Flash of Original Content problem. The user loads the page, sees the original version for a split second, and then watches it snap to the variant. A blue button flashes before turning red. A headline appears, then changes. It’s visually jarring, it causes layout shifts, and it undermines the validity of the experiment itself — because the control experience and the variant experience are no longer equivalent.
The industry’s solution to this problem is the anti-flicker snippet, sometimes called a “page-hiding pixel” or similar. It works by injecting CSS that sets the entire page to invisible — typically opacity: 0 on the <body> or <html> element — the moment the page starts loading. The page stays hidden until the A/B testing script has downloaded, executed, determined the user’s variant assignment, and updated the DOM to display the proper experiment variant. Only then does the page become visible.
The intent is reasonable. The execution is devastating.
While the anti-flicker snippet is active, the user sees nothing. A blank white screen. The page’s HTML may have arrived. The CSS may have been parsed. Images may have started downloading. But none of it is visible, because the anti-flicker snippet is holding the curtain closed while it waits for a third-party JavaScript file to finish its work.
These snippets typically include a safety timeout — if the A/B script fails to load or takes too long, the page un-hides after a set interval. That default timeout is usually 2,000 to 4,000 milliseconds. Four seconds! Most teams have never revisited that default.
The impact on Core Web Vitals is direct and measurable. Largest Contentful Paint cannot fire until the page is visible. A site that would otherwise achieve an LCP of 1.0 second will report an LCP of 3.0 seconds or worse with a 2-second anti-flicker delay. That single addition can push a page from Google’s “Good” threshold into “Needs Improvement” or “Poor” — not because the page is slow, but because the testing tool is artificially preventing the browser from showing content it has already loaded.
Client-side A/B testing: the browser is blocked while awaiting third-party script resolution.
And this penalty applies to every page running an experiment, for every user in the test population. If your A/B testing script loads across the entire site (which is the default configuration for most third-party vendors), every page pays this tax whether it has an active experiment or not.
What can teams do to limit the damage?
Scope the hiding. If flicker prevention is necessary, hide only the element under test — not the entire page. If you’re testing a headline, hide the headline container. If you’re testing a CTA button, hide that button. The rest of the page renders immediately, and the user sees content within a normal timeframe.
Lower the timeout. A 4-second timeout means you are willing to show your users a blank screen for 4 seconds in the worst case. Reducing it to 1 or 1.5 seconds limits the downside. Yes, some users may briefly see the original content if the script is slow — but that is almost always a better outcome than a multi-second white screen.
Adopt an “off by default” mentality. If no experiment is actively running on a page, the anti-flicker snippet should not be loading on that page. Some teams implement a global feature flag that controls whether any experimentation code loads at all. When no tests are active, the flag is off, and the performance tax drops to zero.
Question the architecture. If the element under test is on the above the fold — hero images, primary navigation, headline copy — client-side manipulation may simply be too expensive. These experiments should be implemented server-side or at the CDN edge, where the variant is baked into the HTML before it reaches the browser. No flicker. No hiding. No tax.
The anti-flicker snippet exists to solve a real problem. But the cure is often worse than the disease — particularly when the default configuration is never questioned and the performance cost is never measured.
