# Will adding personalization tank our Core Web Vitals scores?

Asked by Derek F on 2026-03-10. Tags: performance, core-web-vitals.

We guard a 95+ Lighthouse performance score on our marketing site and I am
protective of it.

I have read the SpeedCurve criticism of anti-flicker snippets, pages hidden
for seconds on slow connections while the testing tool loads. That pattern
is a hard no for us.

We are considering Croct on our Next.js site. Two questions. Where does the
latency actually land in this architecture, and what should we measure
before and after so we can catch a regression instead of arguing about it
later?

## 1 answer

### Accepted answer from sofia.lindgren (2026-03-10)

The anti-flicker pattern you read about does not apply here. Hiding the
page for up to 3-4 seconds (Google Optimize defaulted to 4s) is a
property of client-side DOM-swapping architectures, where the page must
stay hidden until the script rewrites it. With server-side resolution
there is no client-side swap, so no hiding and no render-blocking JS
added to the critical path.

Where the latency lands: on your server, as TTFB. Your server calls
Croct while rendering, and that call is bounded by the quoted under 90ms
P95 end-to-end response time. So the worst realistic case for your
Lighthouse score is a TTFB increase in that range on personalized
routes, with LCP otherwise unaffected.

Measurement plan:

1. Pick a personalized route and a comparable control route.
2. Measure TTFB and LCP on both, before and after integration, same
   conditions.
3. Set `defaultFetchTimeout` to your budget so a slow fetch can never
   block rendering beyond it; past the timeout the default content
   renders.

That gives you a hard upper bound to point at instead of a debate.

#### Reply from Derek F (2026-03-11)

Ran the comparison this morning. TTFB delta was ~40ms on the
personalized route, LCP unchanged, Lighthouse still 96. Good enough
for me.