[DynamicIO]PPR pages are rendered every time

[AkifumiSato]

Link to the code that reproduces this issue

https://github.com/AkifumiSato/nextjs-dynamicio-and-ppr-issue-demo

To Reproduce

next build and next start in the reproduction repository.

// app/page.tsx
export default async function Page() {
  console.log("render: Page")

  return (
    <div>
      ...
      <Suspense fallback={<>loading...</>}>
        <Products />
      </Suspense>
    </div>
  );
}

async function Products() {
  console.log("render: Products Components")

  // ...
}

Build log

Route (app)                              Size     First Load JS
┌ ◐ /                                    3.51 kB         118 kB
...

◐  (Partial Prerender)  prerendered as static HTML with dynamic server-streamed content

Request log /(every time)

render: Page
render: Products Components

Current vs. Expected behavior

When a request comes in for a PPR page, we expect only the Dynamic Hole to be rendered. In reality, however, the entire page is rendered. This means that PPR will not work as intended when Next.js is employed for self-hosting.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.4.0: Wed Feb 21 21:44:43 PST 2024; root:xnu-10063.101.15~2/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 8
Binaries:
  Node: 20.10.0
  npm: 10.2.3
  Yarn: N/A
  pnpm: 9.6.0
Relevant Packages:
  next: 15.2.0-canary.60 // There is a newer canary version (15.2.0-canary.61) available, please upgrade! 
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.3
Next.js Config:
  output: N/A
 ⚠ There is a newer canary version (15.2.0-canary.61) available, please upgrade! 
   Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
   Read more - https://nextjs.org/docs/messages/opening-an-issue

Which area(s) are affected? (Select all that apply)

dynamicIO, Partial Prerendering (PPR)

Which stage(s) are affected? (Select all that apply)

next start (local)

Additional context

No response

[janwo]

I have a similar issue. My pages are prerendered although I do not use "use cache" there. IMO this should be the equivalent to "force-dynamic", because otherwise I have no way to disable prerendering for pages.

[AkifumiSato]

While I understand that opt-out is an important point, it would be reasonable to expect the pre-rendering results to be used when dynamicIO and ppr are enabled.

[samcx]

@AkifumiSato This is working as expected for PPR page when there is a dynamic part.

We need to re-run the static part of the render to generate the props and context needed to render the rest of the dynamic parts. The static parts should have all it's data cached (hence why it's static) so it should just be the render-dom code and not hitting the network (outside looking up cache entries).

[AkifumiSato]

Thanks for the response. I omitted it in the issue description, but the sample code actually includes a dynamic fetch.

https://github.com/AkifumiSato/nextjs-dynamicio-and-ppr-issue-demo/blob/main/src/app/page.tsx#L25-L26

I understand running the outer with DynamicIO, but I would have expected the outer components (except the Dynamic Hole) to be rendered statically if PPR is also enabled. Therefore, the current behavior was not consistent with my expectations.

With Dynamic IO enabled, is there any difference in behavior between PPR enabled and disabled?

[samcx]

@AkifumiSato The static shell is still rendered statically, despite seeing the console.log() when refreshing the page. The props, context are required to generate the dynamic part, hence it will include the console.log(). Serving the PPR page will always has a consistent TTFB with the static shell.

When you disable PPR with dynamicIO enabled, the entire page will opt into dynamic, instead of there being a partially static shell.

[AkifumiSato]

@samcx I performed the following verification in the reproduction repository:

1. next build
2. Rewrote the title part ("PPR Page") in the HTML and RSC files under .next/server/app to a test string.
3. next start
4. The rewritten result was not reflected, and the title "PPR Page" appeared on the screen.

This verification suggests that the built static files are not being used. In other words, this suggests that the behavior is the same with PPR enabled or disabled.

Am I wrong in my validation method and the static rendered results are actually being used? If my verification method is correct and static rendered results are not being used, then again, doesn't enabling/disabling PPR make any difference in actual behavior?

NOTE: I understand that modifying the .next directory is not a typical workflow. However, I wanted to ensure I understood the behavior of DynamicIO and PPR.

[rikbrown]

Just so I understand this, as another person who I think stumbled into this same gotcha.

When the dynamic part of the page (inside the Suspense), finishes rendering, the parent (static) page will always re-render despite being "static". For example, in my contrived example below I output the current timestamp in my static shell. This initially appears as the pre-rendered value, but once my dynamic part completes, it updates to a new timestamp. This is expected.

In my real life application, this means that if I am performing any network requests as part of building the static shell, these must be cached themselves and can't rely on just the static build to cache them. (And, I believe, that's what turning on dynamicIO would shout at you for, although I haven't experimented with dynamicIO yet).

https://codesandbox.io/p/devbox/condescending-river-gwlmfc

[rikbrown]

Just bumping this because this is still very unclear and different from all documentation I can find