Storyblok + Croct on Netlify SSR, anyone measured the added latency?
Client site is Storyblok with SSR on Netlify. We are evaluating Croct and I want field reports, not vendor claims.
The tools I used previously were all client-side with an anti flicker snippet, so the "cost" was a hidden page while the script loaded. With a server-side fetch the cost moves into the request instead, which I actually prefer, but I want to know what it measures in practice.
Specifically: what does the extra server-side fetch per request add, and what happens when the API has a slow day? Does the page just hang?
2 answers
We host three Storyblok client sites on Netlify with SSR and added Croct to two of them last year, so here are actual measurements.
The documented figure is end-to-end response times under 90 milliseconds at P95, and our observations are consistent with that. On Netlify functions in Frankfurt we see the slot fetch add roughly 40-70ms to the server render at the median. The fetch happens inside the render, so it is one added upstream call, same category as your Storyblok API call.
The comparison with your previous setup is worth stating plainly: there is no anti-flicker snippet in this model because there is nothing to hide or swap on the client. The variant is in the HTML that leaves the server. So the latency you pay is visible in TTFB instead of being paid twice, once in TTFB and once in a hidden page.
On slow days: you pass explicit fallback content with the fetch, and the request has a timeout. If the response does not arrive in time, the render proceeds with the Storyblok default. The page does not hang indefinitely, worst case a visitor gets the non-personalized version.
One nuance to add from our Netlify experience: where your SSR function runs matters more than the vendor latency. Our function region was us-east-1 while most traffic was European, and that added more to TTFB than any content fetch did. Worth checking your function region before attributing latency to the personalization layer.
Also test the fallback path deliberately (block the API host locally and watch the render). Seeing the default appear with no error is what convinced our client to sign off.