Anti-Flicker Behavior

Anti-flicker is the mechanism A vs B uses to prevent visitors from seeing the original page for a split second before the experiment variation is applied. This page explains exactly how it works from a technical perspective.

The mechanism

As soon as the A vs B snippet script tag is parsed by the browser and begins executing, it injects the following style into the document:

1html { opacity: 0 !important; transition: none !important; }

This sets the entire page to invisible. The visitor sees nothing — just the browser's background (typically white). This style is applied synchronously as the very first thing the snippet does, before any network requests or async operations.

After all experiments have been evaluated and all variation CSS and JS has been injected, the snippet removes this style. The page becomes visible. Because the variation code has already been applied, the visitor sees the correct variation immediately — there is no flash.

The 3-second safety timeout

The safety timeout is a fail-safe that prevents the page from staying invisible forever if something goes wrong during initialization. It is set at the same time the page is hidden.

If initialization does not complete within 3 seconds, the timeout fires and forces the page to become visible, regardless of the experiment evaluation state. The user will see the page, though some or all experiments may not have been applied.

Situations that could cause the timeout to fire:

• The CDN is unreachable (network outage, DNS failure).
• The browser is extremely throttled or the connection is very slow.
• A synchronous exception in Project JavaScript or a trigger function halts execution before the page is revealed.

1try {
2  // Your potentially risky setup code here
3  const config = JSON.parse(document.getElementById('app-config').textContent);
4  avsb.track.segment('userTier', config.tier);
5} catch (err) {
6  // Swallow the error — don't let it halt experiment evaluation
7  console.warn('[avb] Project JS error:', err);
8}

When the page is revealed

The page is revealed (opacity restored) immediately after the last experiment in the evaluation queue finishes. For most projects with a handful of experiments, this is nearly instantaneous. There is no artificial delay.

The total time from “page hidden” to “page revealed” is approximately:

• Datafile download time (typically under 20ms on a fast connection due to CDN caching).
• Time to hash the visitor ID and evaluate targeting rules (under 1ms).
• Time for any waitUntil calls in trigger functions to resolve (variable — depends on when the target element appears).

When anti-flicker applies

Anti-flicker is active on every page load, regardless of whether the visitor is assigned to an experiment. This is because the snippet does not know whether the visitor will be assigned to an experiment until it downloads the datafile and evaluates targeting rules. Hiding the page first and revealing it after is the only way to guarantee no flicker.

On pages where no experiments match the current URL, the page is hidden and then revealed in rapid succession (the evaluation is essentially instantaneous). In practice, this is imperceptible.

Disabling anti-flicker

Anti-flicker can be toggled off in Project Settings > Configuration > Advanced settings. When disabled, the snippet skips page hiding entirely. Experiments still evaluate and variations are still injected, but the page is never set to opacity: 0.

Consider disabling anti-flicker if:

• All your experiments are behavioural (redirects, form logic) with no visual changes.
• All visual changes are below the fold.
• You are running server-side experiments only.
• You prefer to avoid any page-hide delay, even if it means occasional flicker.