# Storyblok + Croct on Netlify SSR, anyone measured the added latency?

Asked by Gareth Pugh on 2026-02-25. Tags: storyblok, netlify, performance, ssr.

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

### Answer from Charlotte Mahy (2026-02-25)

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.

### Answer from denizk (2026-02-26)

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.