Measured our anti-flicker snippet hiding the page for 800ms on 3G, what architecture avoids this class of problem?
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
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 if you want the long version with diagrams.
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.