Nuxt/docs/content/2.concepts/3.rendering.md

# Rendering Modes

Both Browser and Server can interpret Javascript code to render Vue.js components into HTML elements. This step is called **rendering**. Nuxt supports both **client-side** and **universal** rendering. The two approaches have pros and cons that we will cover in this section.

## Client-side only rendering

Out of the box, a traditional Vue.js application is rendered in the browser (or **client**). Then, Vue.js generates HTML elements after the browser downloads and parses all the Javascript code containing the instructions to create the current interface.

![Users have to wait for the javascript to be downloaded, parsed and executed before seeing the page's content](/img/concepts/rendering/light/csr.svg){.dark:hidden}
![Users have to wait for the javascript to be downloaded, parsed and executed before seeing the page's content](/img/concepts/rendering/dark/csr.svg){.light:hidden}

While this technique allows building complex and dynamic UIs with smooth page transitions, it has different pros and cons:

### Pros

- **Development speed**: When working entirely on the client-side, we don't have to worry about the server compatibility of the code, for example, by using browser-only APIs like the `window` object.
- **Cheaper:** Running a server adds a cost of infrastructure as you would need to run on a platform that supports Javascript. We can host Client-only applications on any static server, just with HTML, CSS, and Javascript files.
- **Offline:** Because code entirely runs in the browser, it can nicely keep working while the internet is unavailable.

### Cons

- **Performance**: The user has to wait for the browser to download, parse and run javascript files. Depending on the network for the download part and the user's device for the parsing and execution, this can take some time and impact your user's experience.
- **Search Engine Optimization**: Indexing and updating the content delivered via client-side rendering takes more time than an HTML document already built. This is related to the performance drawback we discussed, as search engine crawlers won't wait for the interface to be fully rendered in their first try to index the page. Therefore, your content will take more time to show and update in search results pages with pure client-side rendering.

### Examples

Client-side rendering is a good choice for heavily interactive **web applications** that don't need indexing or frequently use the same users. It can leverage browser caching to skip the download phase on subsequent visits, such as **SaaS, back-office applications, or Online Games**.

## Universal Rendering

When the browser requests a URL with universal (client-side + server-side) rendering enabled, a fully rendered HTML page is returned to the browser. Whether the page has been generated in advance and cached or is rendered on the fly, at some point, Nuxt has run the Javascript (Vue.js) code in a server environment, producing an HTML document. Users immediately get the content of our application, contrary to client-side rendering. This step is similar to traditional **server-side rendering** performed by PHP or Ruby applications.

To not lose the benefits of the client-side rendering method, such as dynamic interfaces and pages transitions, the javascript code that runs on the Server is loaded by the client in the background once the HTML document has been downloaded. Once it is interpreted again by the browser (hence **Universal rendering**), Vue.js takes control of the document and enables interactivity.

Making a static page interactive in the browser is called "Hydration."

Universal rendering allows a Nuxt application to provide quick page load times while preserving the benefits of client-side rendering. Furthermore, as the content is already present in the HTML document, crawlers can index it without overheads.

![Users can access the static content when the HTML document is loaded. Hydration then allows page's interactivity](/img/concepts/rendering/light/ssr.svg){.dark:hidden}
![Users can access the static content when the HTML document is loaded. Hydration then allows page's interactivity](/img/concepts/rendering/dark/ssr.svg){.light:hidden}

### Pros

- **Performance**: Users can get immediate access to the page's content because browsers can display static content much faster than Javascript-generated one. At the same time, Nuxt preserves the interactivity of a web application when the hydration process happens.
- **Search Engine Optimization**: Universal rendering delivers the entire HTML content of the page to the browser as a classic server application. Web crawlers can directly index the page's content, which makes Universal rendering a great choice for any content that you want to index quickly.

### Cons

- **Development constraints:** Server and browser environments don't provide the same APIs, and it can be tricky to write code that can run on both sides seamlessly. Fortunately, Nuxt provides guidelines and specific variables to help you determine where a piece of code is executed.
- **Cost:** In order to render pages on the fly, a server needs to run. This adds a monthly cost like any traditional server. However, the server calls are highly reduced thanks to universal rendering with the browser taking over on client-side navigation.

### Examples

Universal rendering is very versatile and can fit almost any use-case, and is especially appropriate for any content-oriented websites: **blog, marketing websites, portfolio, E-commerce, Marketplaces.**

## Summary

Client-side and universal rendering are different strategies to display an interface in a browser.

By default, Nuxt uses **universal rendering** to provide a better User experience, performance and optimize search engine indexation, but you can switch rendering modes in [one line of configuration](https://v3.nuxtjs.org/docs/directory-structure/nuxt.config#ssr).

## Coming in Nuxt 3

In most cases, universal rendering as performed in Nuxt 2 offers a good user and developer experience. However, Nuxt 3 takes universal rendering a step further by introducing hybrid rendering and edge-side rendering.

### Hybrid Rendering

Hybrid rendering allows different caching rules per route and decides how the Server should respond to a new request on a given URL.

At the moment, every page (or **route**) of a Nuxt application must use the same rendering mode, client-side or universal. But in various cases, some pages could be generated at build time, while others should be client-side rendered. For example, think of a content website with an admin section. Every content page should be primarily static and generated once, but the admin section requires registration and behaves more like a dynamic application.

[Read the open RFC discussing implementation and gathering community feedback](https://github.com/nuxt/framework/discussions/560)

### Rendering on CDN edge workers

Traditionally, server-side and universal rendering was only possible using Node.js. Nuxt 3 takes it to another level by directly rendering code in CDN edge workers, reducing latency and costs.

Nitro is the new [server engine](https://v3.nuxtjs.org/concepts/server-engine) that powers Nuxt 3. It offers cross-platform support for Node.js, Deno, Workers, and more. Nitro's design is platform-agnostic and allows rendering a Nuxt application at the edge, closer to your users, allowing replication and further optimizations.

[Deploy your Nuxt 3 application on serverless providers](https://v3.nuxtjs.org/docs/deployment/presets)