We spent years debating client versus server rendering. Now, Partial Prerendering (PPR) has quietly killed the argument. Here's what's working, what's breaking, and how to actually ship it.

The End of the Render Wars

You're probably still arguing about Server-Side Rendering (SSR) versus Client-Side Rendering (CSR). Stop. In 2026, the entire debate is dead. Next.js 16 dropped stable Partial Prerendering (PPR) into our laps. It completely rewrites how we build web apps. No fluff. Just a static shell served instantly from the edge, with dynamic data streaming in behind it.

Why the Old Way Broke

We all know the pain. You build a dashboard. You use classic SSR to get fresh data. Every single request hits the server. The user stares at a blank white screen while the database churns. Setup was a pain.

Or maybe you went the other route. You shipped a massive CSR React app. Your users downloaded 4MB of JavaScript just to see a loading spinner. The UI is clunky. SEO tanks.

We tried fixing it with Incremental Static Regeneration (ISR). But that just gave us stale data and cache-invalidation nightmares. You'd update a product price, but the old price stayed up for 60 seconds. Customers complained. Sales dropped. It's a broken system. You shouldn't have to choose between speed and accuracy.

What Actually Works Now

Enter Partial Prerendering. It blends the raw speed of a static site with the living-data punch of SSR.

Here's the thing. PPR splits your page. The static parts your navbar, footer, hero image get baked at build time and shoved into a CDN. When a user clicks, that shell loads instantly.

At the exact same time, the server wakes up. It starts running the dynamic parts. Think shopping cart counts, user profiles, real-time inventory. Next.js marks these holes with <Suspense> boundaries. The server streams that data directly into the static shell. No full page reload. No client waterfall. No double data fetch.

You write a component. You wrap the dynamic piece in <Suspense>. You let the framework handle the rest.

Here's what the performance reality looks like right now:

Time to First Byte (TTFB) Comparison

The Scars to Prove It

PPR is magic on paper. But it bites if you aren't careful.

I saw this fail during a 2 a.m. migration last month. We flipped the experimental_ppr: 'incremental' switch in Next.js 15. The staging site flew. We pushed to production. Suddenly, our database CPU spiked to 100%.

Why? Edge middleware. Our auth middleware was double-invoking the origin server for every single streaming chunk. It hammered the database. We fixed it by aggressively caching middleware responses and moving auth checks directly into the React Server Components payload.

Another nightmare. A client lost $40K in sales because of a misconfig. They dropped a legacy GTM script into the <head> without the strategy="afterInteractive" flag. It blocked the entire HTML stream on Safari. The static shell loaded, but the dynamic cart data never streamed in. Users couldn't check out. We fixed it by ripping out the blocking script and loading it after DOMContentLoaded. Always test your third-party widgets. They break streaming.

The Final Verdict

Don't build new apps without PPR. It's that simple. If you're using React 19 and Next.js 16, use the new Cache Components. They make PPR the default.

Uploaded Image

The web got faster. The code got simpler. Stop fighting the framework and just use the boundaries.