Rendering Modes — SSR, SSG, and CSR

Nuxt can produce the same app in a few different ways depending on when and where your Vue components run. Picking the right one is a performance and infrastructure decision, not a coding one — the components themselves usually don't change.

Server-Side Rendering (SSR) — the default

With SSR, Nuxt runs your app on the server for every request, producing full HTML before it reaches the browser. The browser then "hydrates" that HTML — attaching event listeners and making it interactive — instead of building the page from scratch.

// nuxt.config.ts
export default defineNuxtConfig({
  ssr: true, // the default — no need to set it explicitly
});

SSR is the best default for content that needs to be fast on first load and indexable by search engines — a blog, a marketing site, most e-commerce pages — because the user sees real content immediately rather than a blank page while JavaScript loads.

Static Site Generation (SSG) — pre-render at build time

If your pages don't depend on per-request data (a docs site, a portfolio), you can pre-render them once at build time instead of on every request:

npx nuxi generate

This crawls your routes, renders each one to a static HTML file, and outputs plain files you can serve from any static host or CDN — no Node.js server required at runtime. It's the fastest possible option because there's no rendering work left to do when a request arrives, but it means content is only as fresh as your last build; a purchase count or live price shown this way would need a separate mechanism to update.

Client-Side Rendering (CSR) — render only in the browser

Some routes — an authenticated dashboard behind a login, for instance — gain nothing from SSR, since search engines never see them and the content is user-specific anyway. Nuxt lets you disable SSR per-route:

<!-- pages/dashboard.vue -->
<script setup>
definePageMeta({
  ssr: false,
});
</script>

This page renders empty on the server and builds itself entirely in the browser, like a traditional single-page app. It trades a slightly slower first paint for skipping server rendering work that would have been thrown away anyway (since the content isn't public or indexable).

Choosing per route, not per app

The mistake to avoid is treating this as one global decision. A single Nuxt app commonly mixes all three: SSR for public marketing and content pages, SSG for a docs section, and CSR for an authenticated dashboard. definePageMeta({ ssr: false }) and route rules in nuxt.config.ts (covered alongside nuxt-config-basics) let you make that call per section of the site rather than committing the whole app to one rendering strategy.