Flicker

Flicker (also called "flash of original content" or FOOC) is when a visitor briefly sees the original version of your page before the variation appears. It looks broken, and it weakens your results, because visitors in the variant group saw the control first.

This page is the diagnosis checklist. For how the protection works, see Anti-Flicker: the short version is that your first install tag hides the page before the browser paints it, and the snippet reveals it again once variations are applied.

First, narrow it down

Reload the page with DevTools open, throttled to Slow 3G (Network tab), and watch what happens:

• Blank, then the correct variation. Working as intended, just slowly. The page was hidden while the bundle loaded.
• Original content, then it changes. The hide never happened. Work through the causes below.
• Correct variation, then it changes again later. Not load-time flicker. Skip to a change that keeps blinking.

Also check the browser console. When something is genuinely broken (missing key, blocked CDN, paused project) A vs B now prints one plain-English error saying what failed and where to fix it. No error at all means the snippet ran fine.

Causes and fixes

Only the loader tag was pasted

The most common cause. The install is two tags, and the hide lives in the first one. Paste only the second and experiments still run, but nothing hides the page.

Fix: copy the whole snippet again from Project Settings → Snippet and paste both tags. The first tag is the inline <script> block; the second is the one with src=".../snippet.js".

The tags are in the body, or late in the head

If the tags sit after your content, or after other blocking scripts, the browser has already painted by the time the hide runs.

Fix: move both tags into <head>, as early as possible, ideally right after the opening <head> tag and ahead of other scripts and stylesheets.

<head>  <!-- A vs B: both tags, first thing -->  <script>  window.avsb=window.avsb||{};window.avsb.q=window.avsb.q||[];  /* ... rest of the stub, including the hide line ... */  </script>  <script src="https://cdn.avsb.cloud/snippet.js?id=YOUR_SNIPPET_KEY" data-avsb="YOUR_SNIPPET_KEY" async></script>  <title>My Website</title>  <!-- other head content --></head>

Anti-flicker protection is switched off for the project

With the project toggle off, the snippet reveals the page as soon as it has read your config, without waiting for variations to be applied.

Fix: go to Project Settings → Configuration → Advanced settings and turn Anti-flicker protection on.

A tag manager is loading the snippet

Deploying through Google Tag Manager (or any tag manager) means the snippet only runs after the tag manager itself has loaded, which is usually after the first paint. The hide is then too late no matter how it is written.

Fix: for above-the-fold experiments, put both tags directly in your HTML rather than in the tag manager. See Google Tag Manager.

The safety timeout is firing

If the bundle or the config takes longer than the timeout (3 seconds by default), the page reveals itself and the variation lands afterwards, which reads as a flash.

Fix: check the Network tab for what is delaying snippet.js or datafile.json. Blocking scripts ahead of the tags are the usual culprit. You can also raise or lower the timeout with data-avsb-timeout on the first tag, though a longer timeout trades flicker for a longer blank page. See Anti-Flicker.

The variation waits for something slow

If your variation code waits for an element that appears late, the page is revealed before the change is applied.

Fix: keep the change itself immediate where you can, and use avsb.waitUntil() only for the parts that genuinely depend on late elements.

SPA navigation

Client-side navigation inside a single-page app is not hidden. The page is already visible, so the variation is re-applied in place and a large change can be visible as it happens.

There is one exception: on a split-URL experiment, a route change that lands on the control address briefly re-hides the page, in case A vs B is about to redirect the visitor. If nothing redirects (the visitor was excluded from the experiment, say), the page reveals itself again right away. You do not need to configure this; it only affects split-URL experiments.

Fix: for above-the-fold changes on SPA routes, apply changes as early in the route's render as you can, and prefer changes that are less noticeable in flight (text and colour over layout). See Single Page Apps.

A change that keeps blinking

Load-time flicker happens once. If instead you see the same element being rewritten over and over on a page that is otherwise idle, that is not flicker: something on the page is undoing the variation, and A vs B is putting it back.

A vs B re-applies a change only when the page has genuinely reverted it, for example when an app framework re-renders a section and wipes the modified element. It compares the live page against the intended result before every re-apply, so its own writes never trigger another write: a correctly applied change is left alone, including multi-line text edits, colour and font changes, and removed elements.

If you still see steady churn, the page's own code is actively fighting the change (a script that re-sets a style or re-inserts content on a timer, say).

Fix: find the site script that keeps rewriting the element (DevTools → Elements → right-click the element → Break on → attribute modifications helps) and either scope your change to a different element or adjust the script. On pathological pages the snippet automatically slows its re-apply rate to protect performance, and the tug-of-war does not run forever: after a few consecutive fights over the same change, A vs B gives up on it for that page view rather than keep fighting, so the element stays in whatever state the site's own script left it in. Check the experiment error log for a "flap stopped" entry naming the change, which confirms this happened and points at the exact element.