A team turns on Partial Prerendering for a Next.js product route, but the build output still reports the route as fully dynamic and production TTFB is unchanged. How would you diagnose it?

## Split the problem first There are two very different failures wearing the same symptom, and the build output distinguishes them for free. Either **no shell was produced**, in which case the route is rendered per request exactly as before, or **a shell was produced but the user never gets it early**, in which case the win is being destroyed downstream. Next's build output lists each route with a rendering marker and prints a legend explaining them; a partially prerendered route is marked distinctly from a plain dynamic one. Read that before touching code. ## Cause 1: the route is not opted in Partial Prerendering has been opt-in and experimental through Next 14 and 15, configured under the `experimental.ppr` key in `next.config`. That key takes more than a boolean: setting it to `'incremental'` enables PPR only for routes that individually opt in, by exporting `experimental_ppr = true` from the segment. ```js // next.config.js module.exports = { experimental: { ppr: 'incremental' } } ``` ```tsx // app/product/[id]/page.tsx export const experimental_ppr = true ``` The common version of this bug is a team that set the config to `'incremental'` because a guide said so, then never added the per-route export and concluded the feature does not work. Confirm which mode you are in and whether the route in question declared itself. ## Cause 2: a request-time read above every boundary A shell can only be produced if the build can stop cleanly at a `<Suspense>` boundary. A read of request data with nothing above it leaves no fallback to prerender and no resume point, so the whole route falls back to dynamic rendering. When the page itself looks correctly wrapped, the read is usually **not in the page**. A `layout.tsx` renders above every route nested beneath it, so a cookie or header read there sits above all of a page's boundaries. One such read in a shared layout deoptimises every route under it at once — and it is easy to introduce, because reading a session in the layout to decide what the nav shows is a natural thing to write. Walk the layout chain from the route up to the root. ## Cause 3: a segment config forces dynamic If any segment in the route's chain exports `dynamic = 'force-dynamic'`, the route is dynamic by declaration and no amount of boundary work changes that. It is worth grepping the route's segments for it, because it is often left behind from an unrelated debugging session months earlier. ## Cause 4: the response is being buffered This is the one that survives a correct build and is missed most often. PPR's benefit is that the shell leaves the server before the per-request work finishes. Anything in the path that waits for a complete response before forwarding it collapses that back into the original behaviour: the user sees nothing until the last hole resolves, so TTFB looks exactly as it did before. Usual culprits are a reverse proxy or ingress configured to buffer, compression middleware that accumulates the whole body before encoding it, and hosting layers that treat the handler's return value as one atomic payload rather than a stream. Test it directly — issue a request with a client that reports when the *first* bytes arrive rather than when the request completes, and compare against hitting the app process directly with the proxy bypassed. If bypassing the proxy fixes the timing, you have your answer. ## Confirming the fix After each change, re-read the build output first: it is the cheap, deterministic check for causes 1 through 3. Only once the route is marked partially prerendered does field timing become meaningful, and then the metric to watch is time to first byte and the paint that follows it — not total load time, which barely moves because the same total work is being done either way. PPR does not make the personalized query faster; it stops that query from delaying everything around it. ## Two things that are not the cause The holes being slow is not a PPR failure — they are supposed to arrive later. And a page whose above-the-fold content is almost entirely personalized will show a genuinely correct partial prerender with almost no visible benefit, because there was hardly any shell to serve. That is a route-selection problem, not a bug.