Nainik Mehta

Posted on Aug 26

Make Navigations Instant with Next.js Partial Prerendering

#nextjs #performance #webperf #prerendering

Why Next.js Partial Prerendering (PPR) matters

If your app uses server-driven rendering but you want the snappy feel of an SPA, Next.js Partial Prerendering (PPR) is the middle path. PPR ships a cached static shell from the edge and streams per-request dynamic regions into the same HTTP response. That means the page chrome (layout, nav, skeletons) arrives immediately while personalized data fills in a beat — without client-side fetches or extra roundtrips.

Next.js Partial Prerendering is particularly powerful on pages that are mostly shared chrome with a handful of personalized cells: product pages, dashboards, or marketing pages with a few user-specific widgets.

The quick checklist I use to roll out PPR

Enable Cache Components / PPR in your Next.js config (Next.js 16+).
Pick one high-traffic route to test — don’t flip the whole site.
Add a cached static shell (layout) and use Suspense fallbacks for dynamic regions.
Opt into cached data / revalidation for fetches that belong in the shell.
Run Lighthouse / RUM to measure LCP and other Core Web Vitals before and after.
Roll out incrementally after the numbers justify more changes.

Enabling PPR (short config)

In Next.js 16 you opt into the Cache Components model, which enables the PPR workflow. A minimal next.config.ts:

// next.config.ts
/**
 * Enable cache components (PPR) so you can mark cached segments with 'use cache'
 */
const nextConfig = {
  experimental: {
    cacheComponents: true,
  },
};

export default nextConfig;

Note: older experimental.ppr flags were used in earlier releases. On Next.js 16+ use cacheComponents and mark cacheable functions with 'use cache'.

Concrete example: product route (route-level)

Goal: static chrome renders instantly; product details stream in.

app/product/layout.tsx — cached shell

// app/product/layout.tsx
export default function ProductLayout({ children }: { children: React.ReactNode }) {
  'use cache'; // mark this segment as cacheable; becomes part of the static shell

  return (
    <html>
      <body>
        <nav>/* site chrome */</nav>
        <main>{children}</main>
        <footer>/* footer */</footer>
      </body>
    </html>
  );
}

app/product/[id]/page.tsx — dynamic hole wrapped in Suspense

// app/product/[id]/page.tsx
import { Suspense } from 'react';
import ProductDetails from './ProductDetails';
import ProductSkeleton from './ProductSkeleton';

export default function ProductPage({ params }: { params: { id: string } }) {
  return (
    <article>
      <h1>Product</h1>

      {/* dynamic region: streams in at request time */}
      <Suspense fallback={<ProductSkeleton />}>
        {/* ProductDetails reads request-time data or uncached fetches */}
        <ProductDetails id={params.id} />
      </Suspense>
    </article>
  );
}

And the server component that fetches data with revalidation:

// app/product/[id]/ProductDetails.tsx
export default async function ProductDetails({ id }: { id: string }) {
  // route-level revalidate: cached data but revalidated every 60s
  const res = await fetch(`https://api.example.com/products/${id}`, {
    next: { revalidate: 60 },
  });
  const product = await res.json();

  return (
    <section>
      <h2>{product.name}</h2>
      <p>{product.description}</p>
    </section>
  );
}

This pattern keeps the layout in the static shell and scopes dynamic work to a Suspense boundary. The shell is cached at the CDN edge; ProductDetails will stream into the same response as it resolves.

What to measure (and how)

Track LCP (largest contentful paint) as your primary signal for perceived speed. Use Lighthouse, WebPageTest, or real-user monitoring (RUM) tools (Datadog RUM, Sentry, Google Analytics custom metrics).
A/B one route — serve the original and a PPR variant — and compare median and 75th-percentile LCP.
Measure TTFB for the shell vs. time to resolve dynamic holes. The shell should show a dramatic TTFB improvement for cached responses.
Watch for regressions in CLS (use proper skeletons sized to avoid layout shift) and JS bundle size.

Measurement is everything: only roll forward once metrics show a net win for your users.

Gotchas and what to watch for

Turbopack file tracing: dev bundlers and file tracing can pull more files into the server bundle than you expect. Inspect traced assets and verify server bundles to avoid accidentally shipping a large server bundle that hurts cold starts.
Caching & revalidation mismatches: PPR’s shell is cached independently of your dynamic holes. If you set revalidation windows inconsistently across fetches or use stale cache keys, users can see inconsistent data. Design revalidate TTLs route-by-route and align cache keys to the identity of the content.
Static shell + client code: minimize client components in the shell. Each client component in the shell increases client JS and delays interactivity, eroding the instant feel. Keep the shell as server components plus small, isolated client islands where necessary.
Request-time APIs leaking into layouts: calling cookies(), headers(), or other request-bound APIs at the layout or page top will opt the whole route into dynamic rendering and kill the static shell. Move such reads into small Suspense-wrapped leaves.
Too-big Suspense boundaries: if you wrap large portions of the page in one Suspense fallback, you reclaim little of the PPR benefit. Place boundaries as low as possible and group by independent data sources.

Rollout advice: start small, iterate

Start with one high-traffic route where the hero content and above-the-fold copy can live in the shell. Product listing pages, landing pages, or a frequently visited dashboard route are good candidates.
A/B and monitor LCP, TTFB, CLS, and error rates. If LCP improves without regressions, expand to more routes.
Keep revalidation conservative initially (short TTLs for frequently changing data) and tune based on observed consistency and performance.

Conclusion

Next.js Partial Prerendering gives you a practical way to combine CDN-served static shells with streamed, per-request content so pages feel instant without sacrificing personalization. The trick is discipline: isolate dynamic reads behind Suspense, mark cacheable data intentionally, measure LCP and rollout incrementally. Do that, and you’ll get the instant navigations users expect while keeping server costs and complexity under control.

If you have one high-traffic route in mind for your app, which would you try PPR on first and why?

DEV Community