The whole pre-rendered route is rendered again server-side at request time

[charshin]

I have a simple setup below (with cache component enabled, NextJS 16.1.4)

/app/parent/layout.tsx: Simply render the children
/app/parent/child/layout.tsx: Simple render the children
/app/parent/child/page.tsx: render a dynamic component using fetch, which is wrapped in Suspense

next build succeeds.
next start, hitting localhost:3000/parent/child will see a fallback from Suspense and later the correct data as expected. However, I also notice that the entire route is rendered on the server at request time too. Meaning, if you are to put console.log in each file above, you'll see them all on your server's terminal.

Is this the expected behavior? For a while, I assume that only the subtree that is wrapped within Suspense would be rendered on the server at request time.
Also, I think this behavior is necessary when using React API's use to stream data from server to client, since the promise is absolutely outside of Suspense.

[sunnypatell]

this is expected behavior with PPR (partial pre-rendering). the static shell is a delivery optimization, not a computation optimization.

how PPR actually works

at build time, next.js pre-renders everything outside your <Suspense> boundaries into a static HTML shell. the suspense fallback gets baked into that shell. everything inside the boundary (your dynamic fetch component) is deferred.

at request time:

1. the static shell is served immediately (fast TTFB, user sees the layout + spinner instantly)
2. the server re-renders the full component tree to produce the RSC payload for the dynamic parts
3. the dynamic content is streamed into the suspense "holes"

so yes, console.log() in your layouts and page will fire on every request. react needs to traverse the full tree to correctly resolve component references, props, and figure out what to stream into each suspense boundary.

this is confirmed in discussion #58322 where it's explicitly stated that the server still renders the full tree at request time, even with PPR.

what PPR optimizes

without PPR	with PPR
server renders everything, then sends complete HTML	server immediately sends pre-built shell, then streams dynamic content
user sees nothing until all data resolves	user sees page structure instantly

the server workload is roughly the same. the difference is when the user starts seeing content.

if you want to actually skip re-execution

use the 'use cache' directive on components/functions you want to cache:

// /app/parent/layout.tsx
import { cacheLife } from 'next/cache'

export default async function ParentLayout({ children }: { children: React.ReactNode }) {
  'use cache'
  cacheLife('hours')
  console.log('this only runs on first request, then served from cache')
  return <div>{children}</div>
}

with 'use cache', the return value (including JSX) is cached. on subsequent requests, the cached result is used without re-executing the function body. this is the mechanism that actually prevents re-execution, not <Suspense> alone.

the mental model

• <Suspense> = "send this part later" (delivery timing)
• 'use cache' = "don't re-compute this" (computation caching)

you probably want both: <Suspense> for instant shell delivery, and 'use cache' on your layouts/static parts to skip their re-execution.

docs

• partial pre-rendering
• use cache directive
• cacheComponents config
• cache components guide