Partial prerendering replaces the old binary model of rendering. Before, there were 2 cases. Either the entire route was statically rendered at build time or – if any component in the route had a dynamic element – the entire route was dynamically rendered, that is, rendered server-side at request time.
Dynamic rendering is triggered automatically when a component uses:
-
headers,cookiesorconnectionfunction -
searchParamsorparamspage prop draftMode- dynamic fetch (fetch with no cache)
The downside to dynamic rendering is obvious. Components that could be statically rendered aren’t because the route contains a dynamic element. This is exactly what PPR solves. When a route is made up of static and dynamic components, PPR will statically render the static components into a static shell for the route. The dynamic components must be wrapped inside suspense. The suspense fallback is included into the static shell and the dynamic component itself will be streamed in at runtime.
Example
Note: the examples are available on a new repo on github.
First off, we need to turn on PPR. This is simple, add following config option:
// next.config.ts
const nextConfig: NextConfig = {
cacheComponents: true,
};
We will create some components to form our static shell:
// components/global/Header.tsx
export default function Header() {
return <header>**** Header ****header>;
}
// components/global/Footer.tsx
export default function Footer() {
return <footer>**** Footer ****footer>;
}
Then we create a dynamic component. We use connection to keep it simple.
// components/ppr/SimpleConnection.tsx
export default async function SimpleConnection() {
await connection();
return <div>Hello world!div>;
}
Finally, we put it all together in a route:
// ❌ this example fails, see below
// app/chapter-12/connection/page.tsx
export default function Page() {
return (
<>
<Header />
<SimpleConnection />
<Footer />
);
}
This is not how you should do it. We needed to wrap suspense. But I wanted to demonstrate it first without. When we run next build, we get an error and the build fails:
Error: Route "https://dev.to/chapter-12/connection": Uncached data was accessed outside of . This delays the entire page from rendering, resulting in a slow user experience.
...
This is great; when we forget suspense, Next shouts at us! We update the example with suspense:
export default function Page() {
return (
<>
<Header />
<Suspense fallback='...loading'>
<SimpleConnection />
Suspense>
<Footer />
);
}
This is pure and simple PPR. Given what we learned we expect 2 things:
- At
build time: A static shell with header, footer and the loading fallback. - At
runtime: the fallback gets swapped with the resolved component.
1. We expect a static shell
We run Next build. The build log gives us the first information:
Route (app)
├ ◐ /chapter-12/connection
○ (Static) prerendered as static content
◐ (Partial Prerender) prerendered as static HTML with dynamic server-streamed content
We have partial prerendering.
Let’s take a look at the static shell now. We know from earlier chapters that Next will generate HTML and rsc at build time. This is also true for PPR. On top of that the build folder is the same. So, we can take a look at it. Here is a cleaned-up version of the prerendered HTML:
lang="en">
id="B:0">...loading
**** Footer ****