Partial Prerendering (PPR): Static Speed for Dynamic Pages
Partial Prerendering serves a static page shell instantly, then streams in dynamic parts. It's like getting a pre-built house frame immediately, with custom rooms delivered and slotted in as they're finished.
Why it exists
Traditional Server-Side Rendering (SSR) forces users to wait for the entire page to be generated on the server before they see anything, leading to a slow Time to First Byte (TTFB). Static Site Generation (SSG) is fast but inflexible for dynamic content. PPR was created to combine the instant load of static with the flexibility of dynamic rendering.
The mental model
Think of PPR as serving a pre-fabricated house. The user instantly gets the static shell of the page—the walls, roof, and layout. While they're looking at that, the dynamic parts—the furniture, appliances, and decor—are delivered and slotted into place as they become ready. The user gets an immediate, meaningful view that progressively enhances with dynamic data.
How it works
When a request comes in for a page using PPR, Next.js immediately serves a static HTML shell. This shell is generated at build time or revalidated. The shell contains placeholders for dynamic content, which are wrapped in React Suspense boundaries. After the static shell is sent, the server continues to render the dynamic components. As each component finishes rendering, its HTML is streamed to the client to fill in the corresponding placeholder, without blocking the rest of the page.
When to use it
Use PPR for pages that have a mix of static and dynamic content. It's the default for dynamic pages in the Next.js App Router and is ideal for e-commerce product pages (static description, dynamic reviews), social media feeds (static layout, dynamic posts), or news articles (static article body, dynamic comments section). It dramatically improves the perceived performance for these common use cases.
When not to use it
For purely static content with no dynamic elements, traditional SSG is still simpler and more efficient. For highly interactive, client-heavy applications like a complex dashboard where almost everything is dynamic based on real-time user input, a Client-Side Rendering (CSR) approach might be more straightforward, although PPR can still provide a fast initial skeleton.
One canonical example
An e-commerce product page. The page layout, product title, description, and images are part of the static shell, loading instantly. Meanwhile, components for user reviews, stock availability, and personalized recommendations are wrapped in <Suspense>. They are rendered on the server and streamed in to hydrate the page after the initial static content is visible, giving the user a fast, interactive experience without waiting for every database call to complete.
Interview question
Which approach best describes how Partial Prerendering (PPR) enhances user experience for pages combining static and dynamic elements?
- a.It sends a static HTML shell instantly, then streams server-rendered dynamic content into designated client-side placeholders.Correct
- b.It generates a fully static HTML page at build time, pre-filling all dynamic sections with placeholder data.
- c.It loads a minimal static page, then fetches and renders all dynamic content exclusively using client-side JavaScript.
- d.It renders the entire page on the server and waits for all data, static and dynamic, before sending any HTML.
Why? this is the answer
PPR's key mechanism is to immediately deliver a static HTML shell, providing an instant first meaningful paint. Subsequently, dynamic components are rendered on the server and their HTML is streamed to the client to fill in placeholders, which is distinct from traditional SSR (option D) that waits for all data, or purely client-side rendering (option C).
Just read this? Test yourself on what you have been reading.
Read the original → nextjs.org
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on next.js — each one lists the topics its interview covers.
See open roles