Yes, more importantly we can always show a static shell that the user can see almost immediately, then stream in all the dynamic parts assuming they are appropriately wrapped in Suspense.

Once unstable_nostore becomes stable you'll be able to see more closely the benefite of this rendering pattern.

You can see it right now if you enable PPR and build locally. And not every Suspense will be dynamic, because what's inside Suspense needs to be "Suspense enabled". If your component just makes a fetch, it will be awaited during build time and generated statically. Only if you use stuff like cookies or headers, it will be kept dynamic and the fallback will get rendered statically.

Yeah I'm only interested in production, but, yeah that's why I mentioned unstable_nostore because once that is stable you can call that in any component/function you want to be generated a request time, but, if it's wrapped in suspense the static fallback will be generated a build time, so you get "Dynamic at the speed of static" because now your app is no longer as slow as your slowest dynamic component.

I'm wondering how ppr works with server and client components. Dynamics or not dynamics is understandable. But such a question. Will this rendering generate server components immediately during assembly (static) that do not need dynamics?

i think client components doesnt have an affect in ppr in my logic. since client component are able to render similarly in both static and dynamic rendering

Will this rendering generate server components immediately during assembly (static) that do not need dynamics?

I think this will result in just plain SSG. Creating (o) static routes since the default behavior is 'auto'. So it was never SSR to begin with, therefore ppr isnt used

client components are rendered server side without client-specific features anyways, regardless of PPR or not, so Links are rendered as an <a> normally, buttons are rendered without onClick, forms are rendered without action etc.

Can the PPR "static shell" be cached at a CDN (e.g. Cloudflare)?

yes, that's the point

What's the proper way to cache on cdn? I have a ppr on a page that has a suspense component that grabs the user session but it caches the entire page. So UserB sees UserA's info

nvm, I had proxy_buffering on; in my nginx config... that buffers the response (which includes the dynamic content)
but turning that off breaks caching altogether

^ I'm struggling with this as well

From what I could tell, PPR is mostly useful for serverless. If you're running a container, the default streaming nature of the service makes PPR mute.

correct me if I'm wrong

depends

having an auth cookie might prevent caching

on Vercel i've explored the subject a bit, but a while ago

I'd be eager to get up to date news

check the limits

However, caching in a CDN etc. is basically caching at the network level

but static rendering is a type of caching that happens at application level

so when you use Next.js static rendering you are more on the "application" side anyway

and you will indeed have a static shell

A framework like Remix will prefer caching at network level (they simulate staticness via a dynamic render + HTTP or CDN cache basically)

but that limits personalization

If ppr static shell is at application side then how vercel will deliver static shell from edge and run dynamic parts close to db? Shouldn’t static shell delivery will have latency since it is served from application origin nearby db?

why should it? you can cache the static shell I think

but I think I get the point, since you are streaming, you have basically only one endpoint answering the HTTP request

the dynamic components might be part of the same HTTP request

anyway it's too soon to answer, the question is interesting but it's worth experimenting when PPR is released in a minor version

The thing is that it could render the static shell and send new requests to get the dynamic parts

so the static could come from a edge server and dynamic closer to the db

Ya but they are saying that dymanic parts will be streamed in same http request not two requests

It's possible they're reverse proxying to a "core" dc (that theoretically could be close to your db). That would avoid long waterfalls and then just stream the response to the edge node -> to you.

Sucks that there's basically zero documentation for the infra side of PPR. Hard to evaluate if it will be a good fit or not