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

Asked by dan_kessler on 2026-07-25. Tags: nextjs, performance, ssr.

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

## 2 answers

### Accepted answer from Sam Okafor (2026-07-26)

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.

#### Reply from dan_kessler (2026-07-27)

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

### Answer from milena_dev (2026-07-27)

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](/answers/sub-90ms-p95-what-it-covers),
and a similar Storyblok on Vercel measurement in
[this TTFB thread](/answers/storyblok-nextjs-vercel-ttfb).