Rendering converts the code you write into user interfaces.
React 18 and Next.js 13 introduced new ways to render your application. This page will help you understand the differences between rendering environments, strategies, runtimes, and how to opt into them.
There are two environments where your application code can be rendered: the client and the server.
- The client refers to the browser on a user's device that sends a request to a server for your application code. It then turns the response from the server into an interface the user can interact with.
- The server refers to the computer in a data center that stores your application code, receives requests from a client, does some computation, and sends back an appropriate response.
Note: Server can refer to computers in regions where your application is deployed to, the Edge Network where your application code is distributed, or Content Delivery Networks (CDNs) where the result of the rendering work can be cached.
Component-level Client and Server Rendering
Before React 18, the primary way to render your application using React was entirely on the client.
Now, with Server and Client Components, React can render on the client and the server meaning you can choose the rendering environment at the component level.
By default, the
Static and Dynamic Rendering on the Server
In addition to client-side and server-side rendering with React components, Next.js gives you the option to optimize rendering on the server with Static and Dynamic Rendering.
With Static Rendering, both Server and Client Components can be prerendered on the server at build time. The result of the work is cached and reused on subsequent requests. The cached result can also be revalidated.
Note: This is equivalent to Static Site Generation (SSG) and Incremental Static Regeneration (ISR) in the Pages Router.
Server and Client Components are rendered differently during Static Rendering:
- Client Components have their HTML and JSON prerendered and cached on the server. The cached result is then sent to the client for hydration.
With Dynamic Rendering, both Server and Client Components are rendered on the server at request time. The result of the work is not cached.
Note: This is equivalent to Server-Side Rendering (
getServerSideProps()) in the Pages Router.
To learn more about static and dynamic behavior, see the Static and Dynamic Rendering page. To learn more about caching, see the Caching sections.
Edge and Node.js Runtimes
On the server, there are two runtimes where your pages can be rendered:
- The Node.js Runtime (default) has access to all Node.js APIs and compatible packages from the ecosystem.
- The Edge Runtime is based on Web APIs.
Both runtimes support streaming from the server, depending on your deployment infrastructure.
To learn how to switch between runtimes, see the Edge and Node.js Runtimes page.
Now that you understand the fundamentals of rendering, you can learn more about implementing the different rendering strategies and runtimes: