WEBSITE PERFORMANCE
Next.js Partial Prerendering: the decision tree for turning it off.
Partial Prerendering (PPR) shipped experimental in Next 14, stable in Next 15 (Oct 2024). The promise is simple: static shell, dynamic holes streamed in. In practice it is the feature we have argued with the loudest in 2024-2025.
What PPR does
Renders the route's static shell at build time. Marks dynamic content (inside Suspense boundaries with dynamic data sources) as holes. At request time, serves the static shell immediately and streams the dynamic parts as they resolve. Result: fast TTFB, fast LCP for content above the fold, progressive hydration for below.
When to keep it on
Product pages with personalisation (price, stock, recommendations) below the fold.
Marketing pages with a logged-in/logged-out variant in a small region (nav, CTA).
Blog or content sites with dynamic comments, reactions, or related posts.
When to turn it off
The dynamic content is above the fold. PPR is optimised for "shell first, dynamic after." If your LCP element is inside a Suspense boundary, you get the worst of both worlds: fast shell, slow LCP.
Your dynamic data depends on the user in complex ways. A/B test assignments, geography-based content, auth-gated UI. PPR's caching boundary is at the request, but if nearly everything is dynamic, PPR adds complexity without value.
You are on edge runtime with low TTFB. If your static render is already fast (sub-200ms at p75), PPR's benefit narrows. Shipping a more traditional SSG or SSR path can be simpler and as fast.
You cannot control third-party scripts firing in the static shell. Analytics tags that run pre-hydration can still block INP. PPR does not fix this. If third-party script hygiene is bad, fix that first.
The trap
PPR encourages a mental model of "everything is static except where I mark it dynamic." In reality most real apps have a lot of conditional rendering, and each conditional is a potential dynamic hole. We have seen sites with 30+ dynamic holes on a single page. A build error waiting to happen. The tool rewards simple page shapes. Complex pages should be plain SSR.
Sources: Next.js PPR documentation; production rollout observations, Oct 2024 to Jan 2025.