What is Partial Prerendering (PPR) and how does it relate to SSG?

Question

Accepted Answer

Partial Prerendering (PPR) represents a fundamental shift in how Next.js approaches rendering. Before PPR, a route had to be either entirely static (SSG/ISR) or entirely dynamic (SSR/streaming). If any component in a route needed dynamic data like cookies or headers, the entire route would switch to dynamic rendering, losing the performance benefits of static generation . PPR eliminates this trade-off by allowing developers to mark dynamic boundaries with Suspense, enabling Next.js to prerender a static shell at build time while leaving "holes" that are filled dynamically at request time . The static shell—including layouts, static components, and Suspense fallbacks—is served instantly from the edge, while dynamic components stream in parallel . **Build-time prerendering:** Like SSG, PPR prerenders static content at build time. The layout, static components, and Suspense fallbacks become part of the cached static shell . **ISR compatibility:** The static shell in PPR retains all the benefits of Incremental Static Regeneration—it can be updated via time-based revalidation, on-demand revalidation with tags/paths, or webhooks, just like traditional ISR . **Static by default:** PPR follows the same philosophy as SSG—static optimization is on by default. Components remain static until they explicitly access dynamic APIs like cookies(), headers(), or searchParams . **Dynamic boundaries:** Suspense boundaries mark where dynamic content begins. When a component inside Suspense uses dynamic APIs, only that boundary becomes dynamic while the surrounding shell stays static . **No more route-wide downgrade:** This is the key improvement over traditional SSG—in the past, any dynamic component forced the entire route to become SSR; PPR confines the dynamic behavior to the component level . // next.config.ts import type { NextConfig } from 'next'; const nextConfig: NextConfig = { experimental: { ppr: 'incremental', // Enable incremental adoption }, }; export default nextConfig; // app/product/[slug]/page.tsx import { Suspense } from 'react'; import { ProductDetail } from '@/components/ProductDetail'; // Static import { DynamicStockAndRecommendations } from '@/components/DynamicStockAndRecommendations'; // Dynamic export const experimental_ppr = true; // Opt-in this route export default async function ProductPage({ params }: { params: { slug: string } }) { // This runs at build time (or ISR time) - part of static shell const product = await getProductStatic(params.slug); return (

{/* Static content - prerendered in shell */}

{product.name}

{product.description}

{/* Dynamic boundary - hole in the shell */} Loading stock and recommendations...

}> {/* More static content */} ); } // components/DynamicStockAndRecommendations.tsx import { cookies } from 'next/headers'; // Dynamic API export default async function DynamicStockAndRecommendations({ productSlug }: { productSlug: string }) { // Accessing cookies makes this component dynamic const session = (await cookies()).get('session')?.value; // This fetch is dynamic because of cookies access const dynamicData = await fetch(`https://api.example.com/products/${productSlug}/dynamic`, { headers: { Authorization: `Bearer ${session}` } }).then(r => r.json()); return (

Current Stock: {dynamicData.stockStatus}

Recommendations: {dynamicData.recommendations.join(', ')}

); } At build time, Next.js prerenders a static shell for each route with PPR enabled. This shell includes the layout, all static components, and the fallback UI from Suspense boundaries . When a user visits the page, this shell is served instantly from the edge CDN. While the user is viewing the static content, the server renders the dynamic components in parallel and streams them to the client, where they replace the fallback UI . **Crucially, this entire process happens in a single HTTP request—there's no extra round trip for the dynamic parts, which would defeat the performance benefits .** **Dynamic APIs:** Using cookies(), headers(), or reading searchParams inside a component makes it dynamic **Cache directives:** Fetch requests with { cache: 'no-store' } or using noStore() in a component triggers dynamic rendering for that boundary **Request-time data:** Any component that needs access to request-specific information must be wrapped in Suspense to become a dynamic boundary **Important:** Wrapping a component in Suspense doesn't make it dynamic—the dynamic API usage inside does. Suspense is just the boundary marker // app/dashboard/page.tsx import { Suspense } from 'r

What is Partial Prerendering (PPR) and how does it relate to SSG?

Partial Prerendering (PPR) is an experimental rendering strategy in Next.js that combines static prerendering (SSG/ISR) with dynamic streaming, allowing static and dynamic content to coexist in the same route without compromising performance

What is Partial Prerendering (PPR) and how does it relate to SSG?

Partial Prerendering (PPR) is an experimental rendering strategy in Next.js that combines static prerendering (SSG/ISR) with dynamic streaming, allowing static and dynamic content to coexist in the same route without compromising performance

Scenario Questions

Follow-up Questions