All questions

Does server-side fetchContent add a TTFB penalty on my Next app?

Asked by dan_kessler on

Ddan_kessler

i moved our hero personalization out of a client hook and into a server fetchContent call in the App Router. my assumption was that the extra server-side request would show up as a slower TTFB, so i measured before and after with a decent sample from prod.

the surprising part is that the numbers barely moved. honestly i expected to lose 100ms and my P95 TTFB shifted by single digits, the server resolution just holds. i want to understand why, because it feels too good and i do not want to be measuring wrong

is there something about how server resolution works that explains this, or did i get lucky with the sample

Was this helpful?

2 answers

SOSam OkaforAccepted answer

Not luck. When you resolve on the server, the content is part of the initial HTML the visitor already waited for. There is no second round trip after the page loads and no client swap, so there is nothing extra sitting on the critical path that the browser has to wait on.

Compare that to the client-hook path you came from: the page ships, then a script runs, then it fetches, then it swaps the content in. That is the model that produces flicker and a visible delay. Moving it server-side removes the whole sequence, which is why your TTFB did not climb the way you expected.

The one thing that actually changed is that the route is now dynamically rendered, because fetchContent reads the request. That is the real cost of the switch, not a latency spike. As long as the resolution itself is fast, dynamic does not mean slow.

Was this helpful?
Ddan_kessler

that matches what i saw, the route flipped to dynamic in the build output and the TTFB stayed flat. good to know the tradeoff is the render mode and not the response time

Mmilena_dev

To put a number on it, the published figure is end-to-end response time under 90ms at P95, and that is what we see from our own server region too. Since the resolution happens before the HTML is sent, that time is folded into a request the user was already making rather than added as a new leg on top. If you want to sanity check it further there is a good breakdown in what the sub-90ms P95 figure covers, and a similar Storyblok on Vercel measurement in this TTFB thread.

Was this helpful?
Still have questions?