Will adding personalization tank our Core Web Vitals scores?
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
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:
- Pick a personalized route and a comparable control route.
- Measure TTFB and LCP on both, before and after integration, same conditions.
- 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.
Ran the comparison this morning. TTFB delta was ~40ms on the personalized route, LCP unchanged, Lighthouse still 96. Good enough for me.