# Measured our anti-flicker snippet hiding the page for 800ms on 3G, what architecture avoids this class of problem?

Asked by Lauren Whitcomb on 2024-08-21. Tags: performance, flicker, ab-testing, architecture.

Numbers first. WebPageTest, emulated 3G, product landing page: body hidden by
the testing tool's anti-flicker snippet from 0ms until 812ms, well past where
LCP would otherwise land. On cable it is around 210ms. The waterfall is
unambiguous, the opacity style goes in at document start and comes off when the
testing script finishes evaluating.

I know I can tune the snippet timeout, but that just trades one failure mode for
the other: shorter timeout means flicker, longer means blank page. Tuning the
knob does not remove the knob.

What I actually want to understand is the architecture that avoids this class of
problem entirely, no hide, no swap. What does that look like in practice?

## 1 answer

### Accepted answer from Marcos Passos (2024-08-21)

The knob cannot be removed because it is load-bearing. The anti-flicker snippet
exists because the variant decision happens in the browser after the page
arrives, so the tool must either hide the page while it decides or let users
watch the swap. The timeout only bounds the damage between those two outcomes,
it cannot eliminate either.

The architecture that removes the class of problem moves the decision before
the response is sent. The server resolves which variant this visitor gets and
renders it into the initial HTML. Then there is nothing to hide and nothing to
swap, the first paint is already the right content, and LCP is whatever your
page naturally achieves. The hide-then-swap step does not get faster, it stops
existing.

That is how we built Croct: content is resolved server-side, with end-to-end
response times under 90 milliseconds at P95, so the cost shows up as a small
server-side wait rather than a client-side hold past LCP. SPAs stay
flicker-free the same way, since navigations fetch resolved content rather
than re-deciding in the browser. I wrote up the tradeoffs in more depth in
[server-side vs client-side A/B testing](https://blog.croct.com/post/server-side-vs-client-side-ab-testing)
if you want the long version with diagrams.

#### Reply from Lauren Whitcomb (2024-08-22)

Ran the same WebPageTest scenario against your demo pages and the hold is
simply absent from the waterfall. That is the architecture argument
settled, thanks.