Partial Prerendering

// next.config.js
module.exports = { experimental: { ppr: 'incremental' } }

// app/problems/[slug]/page.tsx
export const experimental_ppr = true

export default async function Page({ params }) {
  const problem = await getProblem(params.slug)     // static: build time

  return (
    <>
      <ProblemHeader problem={problem} />           {/* prerendered shell */}
      <ProblemBody problem={problem} />             {/* prerendered shell */}

      <Suspense fallback={<BookmarkSkeleton />}>
        <BookmarkState slug={params.slug} />        {/* reads cookies() —
                                                        streamed per request */}
      </Suspense>
      <Suspense fallback={<CommentsSkeleton />}>
        <Comments slug={params.slug} />             {/* live data */}
      </Suspense>
    </>
  )
}

// What the user gets:
//   ~0ms   the shell, from the CDN — content is readable immediately
//   ~200ms the personalised holes fill in
// Before PPR this page had to be entirely dynamic because of one
// cookie read.

// Anything reading a dynamic API MUST be inside a Suspense boundary,
// or the whole route falls back to dynamic — the build tells you:
//   "Route / couldn't be partially prerendered because it used
//    cookies outside a Suspense boundary"

// So the discipline is: wrap every dynamic read at the smallest
// possible level, and make the fallback something the shell can show
// with confidence.

// The fallback IS part of the static shell, so it must not itself
// read request data:
<Suspense fallback={<span>Loading…</span>}>    // fine
<Suspense fallback={<UserName />}>             // not fine

// Design implication worth internalising: the shell should be
// meaningful on its own. A page whose static part is only skeletons
// gains nothing from PPR. Put the article, the product, the concept
// in the shell — and only the "is this bookmarked" in the hole.

// This is the same skill as the Suspense concept, applied with a
// different goal: there you were hiding latency, here you are
// deciding what can be cached at the edge.

// Experimental at the time of writing. It needs the flag, it is
// tied to recent Next versions, and self-hosting support lags behind
// Vercel. Do not put it under a deadline.

// What is worth saying in an interview: PPR removes the per-route
// static-or-dynamic choice by making the boundary per-COMPONENT
// instead. The shell is cacheable at the edge; only the parts that
// genuinely depend on the request are computed per request.

// The useful part, available today with no flag: the discipline it
// asks for. Wrapping dynamic reads in small Suspense boundaries makes
// a route faster under plain streaming too, and it means the route is
// already PPR-shaped when the feature stabilises.

// Compare with the alternatives you would otherwise reach for:
//   whole route dynamic   simple, slowest, most expensive
//   client-side fetch     static shell, but a spinner and a round trip
//   PPR                   static shell AND no client round trip

// This codebase runs Next 14.2, so PPR is not available here yet —
// which is exactly why the isolate-the-dynamic-part pattern from the
// previous concept is the one to use now.