Skip to content


    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.

    Rendering Environments

    There are two environments where your application code can be rendered: the client and the server.

    Client and Server Environemnts
    • 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.

    Next.js provided an easier way to break down your application into pages and prerender on the server by generating HTML and sending it to the client to be hydrated by React. However, this led to additional JavaScript needed on the client to make the initial HTML interactive.

    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 app router uses Server Components, allowing you to easily render components on the server and reducing the amount of JavaScript sent to the client.

    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.

    Static 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.
    • Server Components are rendered on the server by React, and their payload is used to generate HTML. The same rendered payload is also used to hydrate the components on the client, resulting in no JavaScript needed on the client.

    Dynamic Rendering

    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.

    Next Steps

    Now that you understand the fundamentals of rendering, you can learn more about implementing the different rendering strategies and runtimes:

    Was this helpful?