SSR, SSG und Hybrid-Rendering in Nuxt sauber einsetzen

1. Rendering-Modi in Nuxt 3: Überblick und Entscheidungsrahmen

Nuxt 3 ist das Vue-Framework mit dem breitesten Rendering-Spektrum: Dieselbe Codebasis kann Server Side Rendering, Static Site Generation, Incremental Static Regeneration und Client Side Rendering produzieren — je nach Route-Konfiguration. Das macht Nuxt zur Grundlage für praktisch jeden Web-Anwendungstyp, erzeugt aber auch Verwirrung, wenn die Unterschiede zwischen den Modi nicht klar sind. Die Wahl des falschen Rendering-Modus in Nuxt kann bedeuten, dass eine eigentlich cachbare Marketingseite bei jedem Request serverseitig gerendert wird — oder dass ein Dashboard mit nutzerspezifischen Daten statisch generiert wird und für alle Nutzer identischen Inhalt zeigt.

Der Entscheidungsrahmen für SSR, SSG und Hybrid-Rendering in Nuxt hängt von zwei Fragen ab: Wie oft ändern sich die Daten einer Route, und sind die Daten nutzerspezifisch? Statische Inhalte wie Landingpages, Blogposts und Produktseiten profitieren von SSG oder ISR. Nutzerspezifische Daten wie Warenkörbe, Dashboards und Profile brauchen SSR oder CSR. Hybrid-Rendering in Nuxt 3 ermöglicht, diese Entscheidung route-per-route zu treffen — ohne die Anwendung aufzuteilen.

2. SSR: Server Side Rendering für dynamische Inhalte

Server Side Rendering in Nuxt bedeutet: Bei jedem HTTP-Request wird die Vue-Komponente auf dem Server gerendert, das vollständige HTML wird an den Browser gesendet, und Vue übernimmt dann die Reaktivität im Browser durch Hydration. Der Vorteil gegenüber reinem Client Side Rendering ist dramatisch: Der Browser erhält sofort rendersbares HTML, der Crawler sieht vollständigen Inhalt, das Time-to-First-Byte und der Largest Contentful Paint verbessern sich messbar. Der Nachteil: Jeder Request belastet den Server, Caching ist auf HTTP-Ebene möglich, aber komplexer als bei statischen Dateien.

In Nuxt 3 ist SSR der Standardmodus, wenn ssr: true in der nuxt.config.ts gesetzt ist. Datenfetching im SSR-Kontext erfolgt ausschließlich via useAsyncData oder useFetch — nicht via onMounted oder reaktive Watchers. Warum? In SSR werden onMounted-Hooks nicht auf dem Server ausgeführt — nur im Browser. Daten, die im onMounted-Hook geladen werden, sind beim serverseitigen Rendering nicht vorhanden und erzeugen Hydration-Mismatches. Das ist einer der häufigsten SSR-Fehler in Nuxt.

// nuxt.config.ts — Global rendering mode configuration
export default defineNuxtConfig({
  ssr: true, // Default: SSR for all routes

  // Nitro server configuration for performance
  nitro: {
    compressPublicAssets: true,
    // Server-side cache for API responses
    routeRules: {
      '/api/**': { cache: { maxAge: 60 } }, // Cache API responses for 60s
    },
  },
})

// pages/product/[id].vue — SSR with useAsyncData
// Data is fetched on server before HTML is sent to browser
const route = useRoute()
const { data: product, error } = await useAsyncData(
  `product-${route.params.id}`,   // Unique cache key
  () => $fetch(`/api/products/${route.params.id}`)
)

// WRONG — only runs in browser, causes SSR mismatch:
// onMounted(() => { fetch('/api/products/' + id).then(...) })

// CORRECT — runs on server AND client, result hydrated:
// const { data } = await useFetch('/api/products/' + id)

3. SSG: Static Site Generation für maximale Performance

Static Site Generation in Nuxt bedeutet: Beim Build werden alle Routen gerendert und als statische HTML-Dateien ausgegeben. Kein Server nötig, kein Datenbankzugriff zur Laufzeit — die generierten Dateien werden direkt von einem CDN ausgeliefert. Das ergibt die schnellstmögliche Time-to-First-Byte, da eine statische HTML-Datei vom CDN Edge-Node in unter 10ms ausgeliefert werden kann. Für Inhalte, die sich selten oder nie ändern — Dokumentation, Blogposts, Landingpages — ist SSG die ideale Wahl.

Nuxt 3 mit nuxi generate crawlt alle Links der Anwendung und rendert alle gefundenen Routen. Dynamische Routen müssen entweder über generateRoutes in der Konfiguration oder über den nitro:generate:init-Hook bekannt gemacht werden. Das Limit von SSG: Wenn sich Inhalte ändern, muss ein neuer Build ausgelöst werden. Für Seiten mit häufig wechselnden Inhalten — täglich neue Produktpreise, aktuelle Lagerbestände — ist reines SSG unpraktisch. Hier kommt ISR ins Spiel.

4. ISR: Incremental Static Regeneration als Kompromiss

Incremental Static Regeneration (ISR) in Nuxt kombiniert die Geschwindigkeit statischer Dateien mit der Aktualität von SSR. Eine Route wird beim ersten Request serverseitig gerendert, das Ergebnis wird gecacht und für alle folgenden Requests direkt aus dem Cache ausgeliefert — bis die konfigurierte Cache-Zeit abgelaufen ist. Danach wird die Route beim nächsten Request neu gerendert und wieder gecacht. Das gibt einen konfigurierbaren Kompromiss zwischen Aktualität und Performance: Eine Produktseite kann alle 60 Sekunden aktualisiert werden, ohne dass jeder Request den Server belastet.

In Nuxt 3 wird ISR über Route Rules konfiguriert: routeRules: { '/products/**': { isr: 60 } } gibt an, dass alle Routen unter /products/ für 60 Sekunden gecacht werden sollen. Die Implementierung läuft über Nitros Edge-Cache und ist mit den meisten Deployment-Plattformen kompatibel, die Nuxt's Nitro-Adapter unterstützen — Vercel, Netlify, Cloudflare Pages. Ein wichtiger Hinweis: ISR in Nuxt 3 ist kein statischer Output im nuxi generate-Sinne, sondern ein serverseitiger Cache — ein laufender Nuxt-Server ist erforderlich.

// nuxt.config.ts — Hybrid Rendering with Route Rules
export default defineNuxtConfig({
  ssr: true,

  routeRules: {
    // Landing pages: statically pre-rendered at build time
    '/': { prerender: true },
    '/about': { prerender: true },
    '/blog/**': { isr: 3600 }, // Blog posts: revalidate every hour

    // Product pages: ISR with 60 second revalidation
    '/products/**': { isr: 60 },

    // User-specific routes: SSR, no caching
    '/account/**': { ssr: true },
    '/checkout/**': { ssr: true },

    // Dashboard: client-side only (auth required)
    '/dashboard/**': { ssr: false },

    // API routes: short cache, cors headers
    '/api/public/**': {
      cache: { maxAge: 30 },
      cors: true,
      headers: { 'cache-control': 's-maxage=30' },
    },
    '/api/user/**': { cache: false }, // Never cache user-specific API
  },
})

5. Hybrid-Rendering: Verschiedene Modi pro Route

Hybrid-Rendering in Nuxt 3 ist das mächtigste Feature des Rendering-Systems: Jede Route kann einen eigenen Rendering-Modus haben, ohne dass die Anwendung aufgeteilt werden muss. Eine Nuxt-Applikation kann gleichzeitig statisch generierte Landingpages, ISR-gecachte Produktseiten, SSR-gerenderte Account-Seiten und CSR-only-Dashboards betreiben — alles in einer Codebasis, einem Deployment. Das ist der fundamentale Unterschied zu Frameworks, die sich auf einen einzigen Rendering-Modus festlegen.

Das Hybrid-Rendering in Nuxt basiert auf Route Rules — einer deklarativen Konfiguration in nuxt.config.ts, die für jeden URL-Pfad oder Glob-Pattern den Rendering-Modus, Caching-Strategie und weitere Request-Handler-Optionen festlegt. Route Rules werden von Nitro — dem Server-Framework unter Nuxt — ausgewertet. Dieses System macht es möglich, SEO-relevante Seiten statisch oder via ISR auszuliefern und gleichzeitig hinter Authentifizierung geschützte Seiten immer serverseitig zu rendern.

6. Route Rules: Rendering-Strategie deklarativ konfigurieren

Route Rules in Nuxt 3 sind mehr als nur Rendering-Modi-Switcher. Sie kombinieren Rendering-Strategie, HTTP-Caching-Header, Weiterleitungen, Proxy-Einstellungen und CORS-Konfiguration in einem einzigen deklarativen Objekt pro Route. Das macht die Konfiguration transparent und wartbar: Wer wissen will, wie eine bestimmte Route gerendert und gecacht wird, liest die Route Rules statt durch verteilte Middleware-Dateien zu suchen.

Die wichtigsten Route-Rule-Optionen für das Hybrid-Rendering in Nuxt: prerender: true rendert die Route statisch beim Build. isr: seconds aktiviert Incremental Static Regeneration mit der angegebenen Revalidierungszeit. ssr: false schaltet SSR für die Route ab und liefert eine leere Shell aus, die der Browser mit CSR füllt. cache: { maxAge: seconds } konfiguriert HTTP-Caching ohne ISR. redirect: '/target' richtet serverseitige Weiterleitungen ein. Alle Optionen sind pro Glob-Pattern anwendbar.

7. Hydration-Fehler verstehen und vermeiden

Hydration-Fehler in Nuxt SSR entstehen, wenn das serverseitig gerenderte HTML nicht mit dem HTML übereinstimmt, das Vue im Browser rendern würde. Vue versucht beim Laden, das bestehende Server-HTML zu "hydrieren" — also reaktive Bindings darauf anzuwenden, ohne es neu zu rendern. Wenn die Strukturen nicht übereinstimmen, gibt es Fehler in der Konsole und im schlimmsten Fall ein kaputtes UI, das erst nach einem Client-Re-Render korrekt aussieht. Das kostet Performance und erzeugt Layout-Shifts.

Die häufigsten Ursachen von Hydration-Fehlern in Nuxt sind: Datumswerte, die sich zwischen Server und Client unterscheiden — zum Beispiel new Date(), das auf Server und Client in unterschiedlichen Zeitzonen ausgeführt wird. Math.random()-Aufrufe, die auf Server und Client verschiedene Werte produzieren. Browser-APIs wie localStorage, window oder document, die auf dem Server nicht verfügbar sind. Das Muster zur Vermeidung: Alle browser-spezifischen Werte entweder in onMounted setzen oder mit dem <ClientOnly>-Wrapper von Nuxt umschließen, der die Komponente nur im Browser rendert.

// Hydration error: Math.random() differs between server and client
// WRONG — causes mismatch:
// const id = Math.random().toString(36).slice(2)

// CORRECT — use useId() (Vue 3.5+) or generate in onMounted:
const id = useId()

// WRONG — localStorage is not available on server:
// const theme = localStorage.getItem('theme') ?? 'light'

// CORRECT — use Nuxt's useCookie or access in onMounted:
const theme = useCookie('theme', { default: () => 'light' })

// CORRECT — ClientOnly wrapper for browser-only components:
// <ClientOnly fallback-tag="div" fallback="Wird geladen...">
//   <BrowserOnlyComponent />
// </ClientOnly>

// CORRECT — useAsyncData with server/client data parity:
const { data } = await useAsyncData('products', async () => {
  // This runs on both server (SSR) and client (navigation)
  // Same result ensures no hydration mismatch
  return $fetch('/api/products', {
    headers: useRequestHeaders(['cookie']), // Forward auth cookies
  })
})

8. Server-Caching mit useFetch und useAsyncData

In Nuxt SSR und ISR ist Caching auf mehreren Ebenen möglich. Die erste Ebene ist Nitros eingebautes Route-Caching via Route Rules. Die zweite Ebene ist das Datenfetching-Caching von useAsyncData und useFetch: Diese Composables cachen das Ergebnis ihrer Fetch-Funktion unter dem angegebenen Key und geben bei erneutem Aufruf mit demselben Key das gecachte Ergebnis zurück, ohne eine neue Netzwerkanfrage zu machen. Das verhindert doppelte Fetch-Aufrufe bei clientseitiger Navigation und SSR-Rendering in derselben Request-Pipeline.

Die dritte Caching-Ebene in Nuxt SSR ist der Nitro-Server-Cache mit cachedFunction: Beliebige asynchrone Funktionen — zum Beispiel Datenbankabfragen — können auf dem Nitro-Server gecacht werden. Das gibt die Kontrolle über Caching-Strategie auf Funktionsebene: Ein Produkt-Lookup kann für 60 Sekunden gecacht werden, ein Nutzer-Datensatz nie. Diese Granularität macht Nuxt-Backends deutlich leistungsfähiger als naive SSR-Implementierungen, die bei jedem Request dieselbe Datenbankabfrage ausführen.

9. SSR vs. SSG vs. ISR vs. CSR im direkten Vergleich

Das Fazit für Hybrid-Rendering in Nuxt ist eindeutig: Es gibt keinen universell besten Rendering-Modus. Statische Landingpages und Blogposts profitieren von SSG. Produktseiten mit häufig wechselnden Preisen passen perfekt zu ISR mit kurzer Revalidierungszeit. Nutzerprofile und Warenkörbe brauchen SSR. Hochinteraktive Dashboards hinter Authentifizierung können als CSR-only laufen, um den Server zu entlasten. Nuxt 3 mit Route Rules erlaubt, alle vier Modi in einer Anwendung zu kombinieren.

10. Zusammenfassung

SSR, SSG und Hybrid-Rendering in Nuxt 3 sind kein akademisches Konzept, sondern direkte Performance- und SEO-Hebel. SSR rendert bei jedem Request auf dem Server — ideal für nutzerspezifische, hochdynamische Inhalte. SSG rendert beim Build — ideal für statische Inhalte mit maximaler Auslieferungsgeschwindigkeit. ISR kombiniert beide Welten mit konfigurierbarer Revalidierungszeit. CSR belastet den Server nicht und ist für auth-geschützte, hochinteraktive Interfaces sinnvoll.

Das Hybrid-Rendering von Nuxt 3 über Route Rules ist der entscheidende Vorteil gegenüber Frameworks mit einer einzigen Rendering-Strategie. Hydration-Fehler vermeiden bedeutet: Kein Math.random() oder new Date() ohne serverseitig konsistente Werte, kein Browser-API-Zugriff im SSR-Kontext ohne <ClientOnly>-Wrapper, Datenfetching immer via useFetch oder useAsyncData statt onMounted.

11. FAQ: SSR, SSG und Hybrid-Rendering in Nuxt