Difference between partial rendering(PPR) and the current streaming suspense?

[jovanhartono]

next.js 14 introduces new partial prerendering(PPR) feature.

what's the difference with the current streaming and suspense?

https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming

[icyJoseph]

The Partial Rendering, is, what I think Suspense, should've been all along...

It applies at build time, and what it does is, pre-render everything that's not bounded by a Suspense tag.

That means that these parts are effectively part of the HTML, just like getStaticProps, or Automatic Static Optimization would do, but! when the page is served, the server will send the data that goes in between the Suspense boundaries. So you gain:

• Extremely fast Time to Visible, comparable to a page where everything is know at build time
• Still have the option to have dynamic areas within the page, which will receive their data from the React Server

So for example, as an extreme simplification, you could pre-render various parts of a user dashboard, and then the React Server makes sure to place the user data where the Suspense boundaries were, whereas, before you'd need to defer rendering anything in the user dashboard, to on-demand rendering, ala getServerSideProps.

Another example, a blog post, with a views counter. You'd need to either, render the blog post on demand, or pre-render it, and carve out an area where you'd use useState + useEffect to fetch the views count. With Partial Pre-rendering, you can pre-render the blog post, leave the view count between a Suspense boundary, and then at runtime, the React Server injects the views count where the Suspense boundary was. And you can even fetch the views count purely server side!

[Connor-Skudlarek]

PPR lets you render the entire page at build time, with the exception of Suspense wrapped components (likely other exceptions, but specific to this question that's the difference).

With streaming/suspense, you render the entire page on request. Suspense lets you fetch data in parallel, and streaming lets you replace the suspense component with the fully rendered bits as each of them finish. But everything is done on request time.

With PPR, you render part of the page at build time and part of it at request. Anything that can be rendered at build time, is rendered at build time. Everything else should be wrapped in Suspense (with a fallback to prevent jarring CSS behavior).

So instead of needing to render the entire page (the current setup) or generate the entire page at build time (static pages), you can generate a "partial first page" at build time and render out the parts that are dynamic while the server sends that static page. Everything about the app that doesn't change gets to the user fast.

This effectively gets the first paint more quickly, which feels faster even if the actual/real improvements in speed are negligible in some particular app. The user who sees things happening in 100ms increments is usually happier than the one waiting 700ms for something to happen, even if they both waited a total of 700ms.

[lbittner-pdftron]

Hey! Stumbled upon this conversation recently and have a question.

I've been experimenting with PPR and am finding that even the parts of my app that are supposed to be "static" are still writing logs to the server console on request.

This can be reproduced easily by building a simple page like this

function Page() {
  console.log('Render')
 
 return (
   <div>
       <h1>Hello world</h1>
       <Suspense>
            <SomeComponentThatFetchesData />
       </Suspense>
   </div>
 )
}

When I build the project and request this page, I am still seeing the "Render" console log on the server.

Is this expected? I personally wouldn't expect something "static" to ever be executed server side.

[ssijak]

Can you emulate PPR with current Streaming/suspense by setting cache headers on static parts?

[paulgrieselhuber]

This is the best explanation of these concepts that I've seen. We linked to your explanation from our video on the subject: https://youtu.be/hdaE94dP_Vg

[Connor-Skudlarek]

@paulgrieselhuber Yooo! That's so cool. I'm glad it has helped those who have found this. 😄

I do want to amend some of what I said as there seems to be confusion over server rendering and client rendering, and what that means for React. Sorry @lbittner-pdftron if I've misled you.

Worth keeping in mind that the server is rendering ahead of time to reduce the time it takes to send HTML to the client. It isn't preventing the need to render at all.

Even with SSG, where all of the HTML was rendered and nothing on the page is dynamic content. On request, the client will render at least once for React to complete hydration of the page (add event listeners for instance).

If the client rendered page is the same as the server rendered SSG (I'm pretty sure!) the virtual DOM won't update as there is no difference. But because it ran through the function, it will still console.log() during the render.

[aarondentrodev]

While @Connor-Skudlarek 's answer is correct, I'm just going to describe what I understood about the PPR.

Without PPR, there are only 2 options to render the entire page:

• Static rendering (render the entire page at build time)
• Dynamic rendering (render the entire page for each user at request time)

As mentioned here and here, Next.js uses static rendering by default and switch to dynamically rendering if a dynamic function or uncached data request is discovered during rendering or if the route or page is configured to force dynamic rendering.

Streaming is a technique to progressively render UI and only works for dynamic rendering. PPR is a new concept that gives us a 3rd option to render the entire page by combining static rendering and dynamic rendering, which means part of the page is rendered at build time for a fast initial load, while the remaining part is rendered dynamically at request time with streaming.

So I think they are different concepts but look similar because both of them use React's Suspense.