Partial Prerendering: a practical guide for 2026

Most rendering models force a route-level decision: either the whole page is static (SSG), the whole page is server-rendered on every request (SSR), or it's a cached SSR variant (ISR). PPR replaces that page-level dichotomy with a component-level one. Anything wrapped in a <Suspense> boundary, or that reads a request-time API like cookies(), headers(), or the searchParams prop, becomes a dynamic hole. Everything else - the layout, the headings, the marketing copy, any data marked with 'use cache' - becomes part of the prerendered shell.

The result: a product page can prerender the photo, title, description, and structured data at build time, while the cart count, recommended items, and personalised greeting stream in as the request resolves. Visitors see the layout and primary content instantly; bots see all of it in a single HTML response.

Internally, Next.js's prerender pipeline pauses at Suspense boundaries and at request-time API call sites. It captures the partial HTML and a postponed state value to the build output. At runtime, that postponed state is what the server resumes from to render only the dynamic boundaries.

At runtime, the request lifecycle looks like this:

1. When the shell is cached at the edge, the CDN serves it immediately and TTFB drops to edge latency. On a cold cache or a region without the shell, the response falls back to a regular SSR round-trip.
2. The server resumes rendering using the postponed state, executing only the components inside dynamic boundaries.
3. As each Suspense boundary resolves, its rendered HTML is streamed into the same response using HTTP chunked transfer encoding. From the browser's perspective there is no second request - the dynamic content arrives as additional chunks of the same HTML response, not via a follow-up fetch.
4. The browser reveals each boundary as its HTML chunk arrives, replacing the Suspense fallback with the resolved content. React 18+ hydrates progressively, attaching event handlers to each boundary as its chunk arrives, rather than waiting for the whole document.

For platforms running a CDN-edge + origin-compute split, Next.js exposes adapter hooks so the CDN can forward the postponed state to an origin function and concatenate the streamed result with the cached shell. The exact wire format is implementation-specific; Vercel runs the canonical version on its own infrastructure.

The timeline:

• October 2023 - Announced as experimental at Next.js Conf.
• Next.js 14 (2023-2024) - First implementation behind the experimental.ppr flag, with the 'incremental' mode and experimental_ppr route-level export both available during the 14.x cycle.
• Next.js 15 (October 2024) - PPR continued under the same experimental flags. Vercel still positioned PPR as not yet stable; the 'incremental' opt-in remained the recommended way to try it on a per-route basis.
• Next.js 16 (October 2025) - PPR graduates to stable as part of the Cache Components feature. The previous experimental flags are replaced by the new cacheComponents opt-in.

If you're reading documentation that warns "PPR is experimental, do not use in production," check the publish date. The "experimental" framing from before October 2025 is now outdated, though older articles about the underlying mechanics often remain accurate. The current Next.js docs treat PPR as part of Cache Components rather than a standalone feature flag.

Minimal config:

// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  cacheComponents: true,
}

export default nextConfig

A typical PPR page mixes static and dynamic content like this:

// app/dashboard/page.tsx
import { Suspense } from 'react'
import { cookies } from 'next/headers'

async function UserGreeting() {
  const theme = (await cookies()).get('theme')?.value
  return <p>Hello, your theme is {theme}</p>
}

export default function Page() {
  return (
    <>
      <h1>Dashboard</h1>            {/* static shell */}
      <Suspense fallback={<p>Loading...</p>}>
        <UserGreeting />             {/* dynamic hole */}
      </Suspense>
    </>
  )
}

Cache Components flips the implicit caching model. Previously, fetched data was cached by default unless opted out. Now, nothing is cached unless you explicitly mark it with 'use cache'. A Suspense boundary is a separate mechanism: it doesn't cache anything, but it tells Next.js the boundary is allowed to render at request time and stream into the response. Cached and request-time access aren't interchangeable - request-time APIs like cookies(), headers(), and connection() can't be called inside a 'use cache' scope, because cached output by definition can't vary per request. The build error Uncached data was accessed outside of <Suspense> is the most common gotcha on day one.

For Next.js 15, the legacy API still works on existing apps:

// next.config.ts
const nextConfig = { experimental: { ppr: 'incremental' } }

// app/some-route/page.tsx
export const experimental_ppr = true

The core Next.js rendering modes compared:

• SSG generates HTML at build time and serves it to everyone with no origin compute on each request. PPR adds the ability to stream dynamic data into the same response. Pure SSG still has cost and simplicity advantages when there's no per-request data at all.
• SSR renders the entire page on every request. Useful for fully personalised pages with no cacheable content. Where there's meaningful shared layout or cacheable data, PPR can serve that shell from the edge while only the dynamic boundaries hit your origin.
• ISR caches a fully-rendered page for a TTL and revalidates in the background. Useful for shared content like catalogue pages and news feeds. PPR with 'use cache' and cacheLife covers many ISR use cases and adds per-request dynamic boundaries inside the same response.

If you're not on Next.js, none of these are directly available. A separate category - dynamic rendering services - sits in front of any framework and serves pre-rendered HTML to bot user-agents while humans get the SPA. These solve the SEO problem (giving crawlers fully rendered HTML) without a framework migration, but they don't reduce TTFB for human visitors the way PPR does.

The decision: if you're on the Next.js App Router and willing to adopt Cache Components, PPR is the natural fit for most use cases. If you're on a React, Vue, or Angular SPA - or on Next.js Pages Router - PPR isn't available, and the alternatives are framework migration, static export, or dynamic rendering. Our JavaScript SEO rendering guide covers the trade-offs across these paths.

The SEO upsides:

• TTFB drops to edge latency for the static shell. Google adjusts crawl rate in response to server response speed, so faster TTFB tends to support more efficient crawl budget usage on large sites.
• LCP can improve when hero content lives in the shell, because the shell is served from the edge before any dynamic data resolves. Real-world impact depends on what proportion of above-the-fold content is in the shell vs the dynamic boundaries.
• No two-pass indexing required for shell content. Googlebot's two-phase pipeline processes JavaScript on a separate render queue, which Google has said usually completes within minutes but can take longer for low-priority pages. PPR sidesteps the queue for everything in the static shell.
• Predictable HTML structure. The shell contains layout, navigation, headings, structured data, and hero content - exactly what you want crawled.

Watch for the footguns:

• If your <h1> or primary copy lives inside a Suspense boundary, you've moved it out of the prerendered shell. The streamed version still arrives in the same response, but you've given up the TTFB win for that content. Put dynamic holes around personalised, non-SEO-critical surface area like cart and recommendations.
• generateMetadata can become a request-time bottleneck if it reads cookies, headers, or other dynamic data. Next.js 15.2+ supports streaming metadata so a slow generateMetadata doesn't always block the shell, but cached or fully static metadata still loads earlier and is the safer default. Keep title, description, canonical, and OG tags static or cached where possible.
• Where you place Suspense fallbacks matters. A wide Suspense boundary high in the tree (for example, wrapping the whole layout) effectively pulls the entire subtree out of the static shell, which removes most of the PPR benefit for that route.
• PPR doesn't fix non-Next.js apps. A React SPA on Vite, an Angular app, or a Next.js Pages Router project still needs SSR, SSG, or a dynamic rendering service to give crawlers visible content. Our SEO audit tool shows the rendering gap on any URL.

PPR is a good fit for greenfield Next.js App Router projects and for teams on Next.js 14+ who are willing to migrate to Cache Components. It's not available, or not pragmatic, when:

• You're on a non-Next.js stack (React with Vite, Vue, Angular, Svelte, Solid, Qwik).
• You're on Next.js Pages Router and don't have capacity to migrate to App Router.
• You're building on no-code platforms (Lovable, Bolt, Replit, Webflow, Bubble) where you don't control the rendering stack. (AI-builder tools that emit Next.js code, like v0, are different - you typically can adopt PPR there because you own the generated code.)
• You manage many client sites on different frameworks and need a single solution that works across all of them.

The three realistic alternatives in these cases:

• Migrate to an SSR-first framework - Next.js App Router, Nuxt, SvelteKit, Remix, or Astro with SSR. Solves SEO natively. The migration itself is the cost.
• Generate a static export - viable when content is largely fixed and personalisation is minimal. Doesn't suit dashboards, real-time data, or per-user views.
• Add a dynamic rendering layer - sits in front of the existing app and serves pre-rendered HTML to bot user-agents while humans hit your origin unchanged. PageGlass implements this at the DNS layer with a CNAME record.

Which path is right depends on team capacity, existing stack, and whether the SEO gap is the only driver. PPR is generally the better fit for greenfield Next.js work; the alternatives above apply when a Next.js migration isn't on the cards.