Rendering strategy sounds academic until it shows up in your bounce rate or your server bill. Nuxt's quiet superpower is that rendering is a per-route decision, not an architecture commitment: one app can serve a static marketing page, a server-rendered product page, and a purely client-side dashboard, each route using what suits it.
The four modes in one breath each
- Universal (SSR): the server renders HTML per request, then the browser hydrates it into a live app; best for content that changes and needs SEO.
- Static (SSG): pages render once at build time and ship from a CDN; unbeatable speed and cost for content that changes rarely.
- Incremental (ISR/SWR via route rules): pages render on demand, get cached for a window, and refresh in the background; the middle ground for large or semi-fresh catalogs.
- Client-only (SPA): the browser does everything; fine for logged-in tools where SEO is irrelevant, at the cost of a blanker first paint.
Route rules make it concrete
In nuxt.config.ts, routeRules assigns strategy per path pattern: prerender the marketing routes, apply stale-while-revalidate to blog paths, mark the dashboard client-only. This is the feature to reach for before spinning up a second application because "the marketing site and the app need different things." They can be the same Nuxt app with different rules.
Choosing without overthinking
Ask two questions per route: does a crawler or link preview need real HTML, and how fresh must the content be? Static wins wherever both answers permit; SSR covers the rest of the public surface; client-only serves the private tooling. And whatever you pick, remember hydration: code that touches window belongs in onMounted or behind import.meta.client checks, because on the server there is no window to touch.