What does adding an experimentation tool do to LCP on a slow connection?
I build for users in Nairobi where many connections are 3G-class, so we keep a strict LCP budget. I recently trialed a popular experimentation tool and measured its impact myself: even the trimmed snippet was around 200KB and it was render-blocking for roughly 500ms on a throttled connection, with zero experiments actually running. That alone blew our budget.
Before I trial Croct I would like to understand the architecture. What exactly does it add to the critical rendering path, and where does the personalization cost land on a slow connection?
2 answers
The architectures are fundamentally different, which is why your measurement came out the way it did. Client-side tools have to download the SDK plus the experiment rules before first paint, otherwise you get the flash of original content, so they load synchronously and block rendering. The 60-400KB snippet range and ~500ms of blocking you measured is typical for that category even with nothing running.
With Croct there is no render-blocking snippet required. When you use server-side resolution, the personalization cost moves to the server request: your server calls Croct while building the page, and the quoted figure is end-to-end response times under 90 milliseconds at P95. On a slow client connection that matters a lot, because server-to-server latency does not scale with the user's bandwidth. The user downloads one HTML document that is already final.
So for your budget the question becomes "what does <90ms of server-side latency do to TTFB", not "what does 200KB of blocking JS do to LCP on 3G". Very different math.
Adding the SPA case since not everyone has SSR. If your app is fully client-rendered, the JS SDK is small and content is fetched per slot with a fallback, so the page shell paints immediately and only the personalized slots resolve after. You do not get the everything-blocked behavior you measured, but the slots themselves do arrive after first paint, so for a strict LCP budget the server-side path is the one to prefer when you can.
Thank you both, this is exactly the level of detail I needed. We have SSR, so I will trial the server-side path and measure TTFB deltas.