How partial pre-rendering can improve performance

What is it?

Well, simply put, there are two types of web pages: static and dynamic.

Static pages are pages that consists of fixed content (namely HTML, CSS, and JavaScript) that doesn't change. That means when this type of page is requested, the server just sends the content.

Whereas in terms of dynamic pages, some calculations are needed to be done before the page can be sent. So the server does the calculations, injects the required data into the HTML, and then sends the page.

A very significant reason for performance issues is the time it takes for the server to process the page before sending. Whereas static pages can be sent even through something like a file server. This is where partial pre-rendering comes in.

Usually no dynamic pages are fully dynamic. Mostly those pages are static with some dynamic elements. With partial pre-rendering, it's not about static or dynamic page anymore, it's about static or dynamic elements.

How does it work?

At build time, the server pre-renders the static parts of a dynamic page ready to be served. When a dynamic page is requested, the server immediately sends the pre-rendered static part of the page keeping the space empty where the dynamic parts would eventually be and starts processing for the dynamic sections. One the process is complete, the server then streams the dynamic parts to the client filling in the holes.

How to use?

In Next14@canary and Next15, PPR is an experimental feature that can be turned on through Next config file. Once turned on, the server will automatically pre-render the static parts without any changes to the codebase.

This would only effectively work if the pages do not fetch data or do any calculations on request time and the dynamic parts of a page are wrapped in a React Suspense boundary.