Nuxt 4 Rendering Modes

Nuxt 4 Rendering Modes

Nuxt 4 can render the same application in several different ways, and choosing the wrong strategy can create unnecessary server costs, slower initial loading, stale content, or avoidable SEO complexity.

The important distinction is that Nuxt does not force an entire website into one rendering strategy. Universal rendering is the default, but individual routes can be prerendered, cached, rendered on demand, or moved to client-side rendering through hybrid rendering and routeRules. Edge rendering adds another option for where server rendering happens rather than introducing a completely different rendering model. (nuxt.com)

Direct Answer

By default, Nuxt 4 uses universal rendering. Nuxt generates the initial HTML on the server, sends it to the browser, and Vue then hydrates that HTML so the page becomes interactive.

You can instead use:

• Client-side rendering (CSR) with ssr: false
• Prerendering to generate HTML during the build
• SWR to cache rendered responses and refresh them in the background
• ISR to persist generated pages in supported CDN environments
• Hybrid rendering to combine these strategies route by route

Nuxt's routeRules configuration is what makes that mixture possible. (nuxt.com)

Rendering Modes Compared

The table simplifies deployment details, but the central idea is useful: the best rendering strategy can be different for different URLs in the same Nuxt application.

Universal Rendering

Universal rendering is Nuxt's default behavior. The Nuxt configuration option ssr defaults to true. (nuxt.com)

When someone requests a page:

1. Nuxt executes the Vue application on the server.
2. The server produces HTML.
3. The browser receives and displays that HTML.
4. The client-side JavaScript loads.
5. Vue hydrates the existing HTML and attaches interactivity.

Hydration does not mean replacing the whole server-rendered page. Vue connects its application to the existing DOM and attaches the behavior required for buttons, state changes, navigation, and other interactive features. (vuejs.org)

For example:

<script setup lang="ts">
const count = ref(0)

function increment() {
  count.value++
}
</script>

<template>
  <button @click="increment">
    Count: {{ count }}
  </button>
</template>

The initial button markup can be produced by the server. The click interaction becomes functional after hydration in the browser.

Universal rendering works particularly well for public content such as product pages, blogs, marketing sites, marketplaces, and other pages where immediately available HTML is valuable. (nuxt.com)

Hydration Has Constraints

Because much of the application executes once on the server and again in the browser, both environments should initially produce compatible markup.

Random values, browser-only APIs, invalid HTML structure, or timezone-dependent output can create hydration mismatches when the client's expected DOM differs from the server-generated HTML. Vue attempts to recover from such mismatches, but recovery can introduce extra work and should generally be avoided. (vuejs.org)

INTERNAL LINK: Nuxt Hydration Mismatch Explained

Client-Side Rendering

You can disable server-side HTML rendering globally:

// nuxt.config.ts
export default defineNuxtConfig({
  ssr: false,
})

With client-side rendering, the browser receives the application shell and JavaScript creates the interface in the browser instead of Nuxt producing the page content through SSR. (nuxt.com)

This can be useful for applications such as:

• authenticated dashboards,
• back-office systems,
• highly interactive tools,
• interfaces where public search indexing is irrelevant.

CSR also removes many server/browser compatibility concerns because page rendering happens entirely in the browser.

The trade-off is that users may need to download, parse, and execute JavaScript before the main interface appears. The result therefore depends more heavily on JavaScript execution and the user's device.

CSR and SEO

It is inaccurate to say that Google simply cannot index client-rendered JavaScript.

Google documents a crawling, rendering, and indexing process in which its Web Rendering Service can execute JavaScript. However, pages whose meaningful content exists only after client-side execution depend on that rendering stage. Google also notes that server-side rendering or prerendering remains useful for users and crawlers, and that not every crawler necessarily executes JavaScript. (developers.google.com)

The practical distinction is therefore not "SSR is indexed, CSR is not."

It is closer to:

Server-rendered or prerendered content reduces the amount of work required before useful page content exists in the received HTML.

INTERNAL LINK: JavaScript SEO Explained

Prerendering

Prerendering moves rendering from request time to build time.

Instead of generating a page every time someone requests it, Nuxt generates an HTML file during deployment and serves that already-built output later.

Nuxt supports prerendering with commands such as:

npx nuxt generate

or:

npx nuxt build --prerender

Nuxt's prerender crawler starts from discoverable routes and follows links to find additional pages that can be generated. Routes can also be configured explicitly. (nuxt.com)

Prerendering is especially useful when the same content can safely be served to everyone until the next deployment—for example:

• an About page,
• documentation,
• many blog articles,
• landing pages.

The limitation is freshness. If the source content changes after the build, the generated HTML does not automatically change unless another mechanism regenerates it.

A fully static nuxt generate deployment also does not include a runtime Nuxt server, so server endpoints from the application cannot operate there in the same way they do with a server deployment. (nuxt.com)

Hybrid Rendering

Real applications rarely fit perfectly into "everything dynamic" or "everything static."

Consider an e-commerce website:

• homepage: mostly stable,
• product pages: periodically updated,
• account area: highly interactive,
• checkout: personalized and dynamic,
• blog: changes occasionally.

Rendering all of those routes identically would be unnecessary.

Nuxt solves this with hybrid rendering and routeRules. Nitro, Nuxt's server engine, applies the appropriate behavior according to the requested route. (nuxt.com)

For example:

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },

    '/products/**': {
      swr: 3600,
    },

    '/blog/**': {
      isr: 3600,
    },

    '/admin/**': {
      ssr: false,
    },
  },
})

Here the website effectively contains several rendering strategies inside one Nuxt application.

The homepage is generated at build time. Product pages can be cached and refreshed. Blog pages can use ISR on compatible deployment platforms. The admin interface skips SSR and behaves as a client-rendered application. (nuxt.com)

That is one of the most important architectural advantages of Nuxt's rendering system.

SWR vs ISR

SWR and ISR are closely related, but they should not automatically be treated as interchangeable names.

SWR

With:

'/products/**': {
  swr: 3600,
}

Nuxt can cache the rendered response for a configured TTL. Once the cached response becomes stale, the existing response can still be served while a newer version is regenerated in the background.

The objective is to avoid rendering the same expensive page on every request while still allowing it to refresh.

ISR

For example:

'/blog/**': {
  isr: 3600,
}

Nuxt documents ISR as having similar regeneration behavior, but with integration into the CDN cache on supported platforms. The Nuxt rendering documentation currently identifies Netlify and Vercel support for this route-rule behavior. (nuxt.com)

Deployment platform therefore matters. Do not select ISR merely because the acronym sounds preferable to SWR.

INTERNAL LINK: ISR vs SWR in Nuxt

Edge Rendering

Edge-side rendering is often grouped with Nuxt rendering modes, but Nuxt itself makes an important distinction: edge rendering is more accurately a deployment target than a separate rendering mode.

The page is still server-rendered. The difference is that execution happens in an edge environment closer to the requester rather than exclusively on one traditional origin server. (nuxt.com)

Nitro is what allows Nuxt applications to target multiple server environments, including conventional servers, serverless platforms, and edge runtimes. (nuxt.com)

Edge deployment can reduce network distance, but it does not automatically make every application faster. Database location, API calls, runtime restrictions, cache strategy, and cold-start behavior still matter.

Choosing a Strategy

A useful decision process is to ask two questions for each route:

Does this page need request-specific HTML?

If no, prerendering may be enough.

How quickly must changes become visible?

If content changes only with deployments, prerender it. If it changes occasionally, caching through SWR or ISR may be appropriate. If it must reflect each request, normal SSR may be simpler. If it is private and highly interactive, client-side rendering can be reasonable.

This often leads to an architecture such as:

Marketing pages  → prerender
Blog             → prerender or ISR
Product catalog  → SWR / ISR
Search results   → SSR
User dashboard   → CSR or SSR
Account data     → dynamic server APIs

There is no universal rule requiring one rendering strategy for the entire project.

Common Mistakes

One common mistake is treating SSR and static generation as competing frameworks. They are rendering strategies that Nuxt can combine.

Another is enabling ssr: false globally because one browser-dependent component causes problems. A client-only component or route-specific configuration may solve the actual problem without converting the entire public website to CSR.

The opposite mistake is rendering every request dynamically even when the output rarely changes. That spends server resources producing HTML that could have been generated or cached once.

Finally, do not confuse edge rendering with prerendering. A prerendered page is generated before the request. An edge-rendered page may still be generated dynamically when a request arrives.

SeoNest Recommendation

Start with Nuxt's default universal rendering unless the application's requirements give you a clear reason not to.

Then optimize at the route level:

Static enough?      → prerender
Reusable briefly?   → SWR
CDN regeneration?   → ISR where supported
Request-specific?   → SSR
Private app UI?      → consider CSR

Measure the actual behavior after deployment rather than assuming that one architecture is inherently faster. Response caching, JavaScript size, API latency, hydration cost, CDN configuration, and data dependencies can matter as much as the rendering label itself.

FAQ

Is Nuxt 4 SSR by default?

Yes. Nuxt's ssr configuration defaults to true, and its standard model uses universal rendering. (nuxt.com)

Is prerendering the same as SSR?

Not exactly. Both can produce HTML before the browser renders the application, but SSR normally creates HTML in response to a request, while prerendering creates it during the build.

Can one Nuxt site use multiple modes?

Yes. Hybrid rendering and routeRules allow different routes to use prerendering, caching, SSR, or client-side rendering. (nuxt.com)

Does CSR prevent Google indexing?

No. Google can execute JavaScript during its rendering process. However, server-rendered or prerendered HTML reduces reliance on client-side execution, and other crawlers may have different JavaScript capabilities. (developers.google.com)

Is edge rendering another form of static generation?

No. Edge rendering describes where server-side execution occurs. Static generation describes when HTML is generated.

Final Takeaway

Nuxt 4 rendering is best understood as a toolbox rather than a single SSR-versus-SPA switch.

Universal rendering is the default foundation. Prerendering removes unnecessary request-time work for stable pages. SWR and ISR reuse generated responses when content does not need to be rebuilt on every request. CSR remains useful for browser-focused application areas. Hybrid rendering connects those strategies so each route can use the behavior that matches its actual requirements.

The question is therefore not "Which Nuxt rendering mode is best?"

It is "What does this particular route need?"

Sources

1. Nuxt — Rendering Modes, Nuxt 4 documentation. Primary reference for universal rendering, CSR, hybrid rendering, route rules, SWR, ISR and edge-side rendering. (nuxt.com) Nuxt: Rendering Modes
2. Nuxt — Prerendering, Nuxt 4 documentation. Primary reference for build-time generation and prerender crawling. (nuxt.com) Nuxt: Prerendering
3. Nuxt — Server, Nuxt 4 documentation. Reference for Nitro, universal deployment and hybrid routeRules. (nuxt.com) Nuxt: Server
4. Nuxt — Configuration Reference, Nuxt 4. Reference for the ssr configuration option and its default value. (nuxt.com) Nuxt: Configuration Reference
5. Vue.js — Server-Side Rendering. Reference for Vue SSR, client hydration and hydration mismatches. (vuejs.org) Vue.js: Server-Side Rendering
6. Google Search Central — Understand the JavaScript SEO Basics. Reference for Google's crawling, JavaScript rendering and indexing process. (developers.google.com) Google: JavaScript SEO Basics
7. Google Search Central — Dynamic Rendering as a Workaround. Reference for Google's current preference for SSR, static rendering or hydration rather than dynamic rendering workarounds. (developers.google.com) Google: Dynamic Rendering