Growth Notes

Flicker and Flash of Original Content

Tags: experimentation web-dev concept

Flicker and Flash of Original Content

Date: 2026-08-16

The original renders, then visibly changes into the variant. It’s not a cosmetic annoyance — the flash is itself a treatment, its duration correlates with connection speed, and the standard fix degrades performance for everyone including control.

What it is

Flash of original content (FOOC), usually just called flicker, is the brief period in a client-side test where the browser has rendered the control experience and the variant has not yet been applied.

 0ms   HTML arrives, browser renders ORIGINAL
       ↓
 ~200ms  test script loads
       ↓
 ~250ms  variant assigned, DOM rewritten
       ↓
       user sees VARIANT  — and saw the original for ~250ms

Anyone in the variant sees the change happen. Anyone in control sees nothing unusual.

Why it invalidates rather than annoys

Three separate problems, and the third is the one that matters most.

It’s a treatment in itself. A page that visibly rearranges reads as broken or, worse, as something manipulating the display. That reaction is part of what you measure, and it isn’t part of what you intended to test.

It’s asymmetric. Only the variant flickers. So the variant arm receives the change plus a visual glitch and control receives neither — the comparison is no longer isolating the change.

Its duration correlates with the user. Flicker lasts longer on slow connections, older devices, and where the script is fetched from a third-party origin. Those users skew towards particular demographics and geographies, so the contamination is heaviest in exactly the segments you’d most want to read separately.

In plain terms: you set out to test one difference and accidentally tested two — the change, and a delay whose size depends on who the user is.

The standard fix, and what it costs

The anti-flicker snippet: a small inline script that hides the page — typically body { opacity: 0 } — until the testing library loads or a timeout expires.

It works. It also means:

  • Every visitor waits, including 100% of the control group and 100% of users not in any test
  • Largest Contentful Paint degrades directly. The largest element cannot paint while the body is hidden, so LCP is pushed out by however long the library takes
  • The timeout is a worst case, not a typical case. A 4-second fallback means a user on a poor connection stares at a blank page for four seconds if the script never arrives
  • You’ve traded a variant-only problem for an everyone problem — which is the right trade for validity and the wrong one for performance

This is worth stating plainly because the snippet is usually installed once and never revisited: a testing tool with an anti-flicker snippet is a permanent performance cost on every page, whether or not a test is running.

Reducing it properly

In rough order of effectiveness:

  • Test server-side. Removes the problem by construction — no original is ever rendered. See Client-Side vs Server-Side Testing
  • Load the test script synchronously in <head>, first-party, self-hosted rather than from a vendor CDN. Blocking, but blocking briefly beats flickering
  • Scope the snippet. Hide only the container being tested, not the whole body, and only on pages where a test is actually running
  • Prefer CSS-only variants where possible. A class toggle applies far faster than a DOM rewrite
  • Cut the timeout. A 4-second fallback is a 4-second blank page. Two seconds is usually more honest about what you’d tolerate
  • Measure it. Record time-to-variant-applied as a diagnostic metric, and treat a long tail as an Experiment QA failure

Detecting it in a result

Flicker rarely announces itself. Signs:

  • The variant underperforms on slow connections but matches or wins on fast ones. Segment by connection type or device age if you can
  • LCP is worse in the variant arm — a guardrail worth having on every client-side test, see Guardrail Metrics
  • The effect shrinks as the page gets heavier across a series of tests on the same template
  • A-A Tests look clean but real tests behave oddly — by definition an A/A test cannot flicker, since both arms are identical. This is the specific blind spot of A/A validation

Graph View

Backlinks