EMZETT.
Login

Emzett Wiki

Rendering-Strategien: SSR, SSG, ISR und Client-Rendering im Vergleich

Properties1
tagsglossar, nextjs, frontend

2 Min. Lesezeit

Rendering-Strategien: SSR, SSG, ISR und Client-Rendering im Vergleich

Kurz: Eine Webseite kann beim Build (SSG), bei jeder Anfrage (SSR), zeitweise neu (ISR) oder im Browser (CSR) erzeugt werden; die Wahl beeinflusst Tempo, Aktualität, Kosten und Suchmaschinen-Tauglichkeit.

Genauer: Die Frage ist: Wann und wo entsteht das HTML? Frameworks wie Next.js erlauben, das je Seite zu wählen.

Im Detail

Die Strategien

  • SSG (Static Site Generation): HTML wird beim Build erzeugt und über ein CDN ausgeliefert. Sehr schnell, billig, sicher; aber nur so aktuell wie der letzte Build. Ideal für Blog, Doku, Wiki, Landingpages.
  • SSR (Server-Side Rendering): Der Server erzeugt das HTML bei jeder Anfrage; immer aktuell und personalisierbar (Cookies), aber langsamer und teurer (Rechenzeit, ggf. Datenbank).
  • ISR (Incremental Static Regeneration): statische Seite mit Ablaufzeit (revalidate: 3600); nach Ablauf wird im Hintergrund neu gebaut. Guter Kompromiss für Listen, Shops, Nachrichten.
  • CSR (Client-Side Rendering): Der Browser lädt JavaScript und baut die Seite; gut für Dashboards hinter Login, schlechter für Erstladezeit und SEO.
  • Streaming/Suspense: Seite wird in Teilen ausgeliefert; Wichtiges erscheint zuerst.

Entscheidungshilfe

AnforderungWahl
Selten ändernde Inhalte, viel TrafficSSG
Inhalte ändern sich minütlich/stündlichISR
Pro Nutzer unterschiedlich (Warenkorb, Profil)SSR oder CSR
Hinter Login, interaktivCSR (oder SSR + Client-Komponenten)
SEO wichtigSSG/ISR/SSR
Mischformen sind normal: Statische Hülle, dynamische Teile per Streaming oder Client-Abfrage.

Auswirkungen

  • Datenbank-Last: SSR/ISR fragen sie ab; mit Caching (siehe unstable_cache, Revalidate) und langen Ablaufzeiten sinkt die Last stark, besonders bei serverlosen Datenbanken, die bei Ruhe pausieren und Rechenzeit berechnen.
  • Kosten und Tempo: CDN-Auslieferung statischer Seiten ist am günstigsten.
  • Ausfallsicherheit: Statische Seiten laufen weiter, selbst wenn die Datenbank nicht erreichbar ist; Builds dürfen deshalb nicht von der Datenbank abhängen oder müssen Fehler abfangen.
  • Aktualität: Mit On-Demand-Revalidate (Tags/Pfade) lässt sich nach Änderungen gezielt neu bauen.

Praxis

Beginne statisch, füge Dynamik dort hinzu, wo sie nötig ist. Messe mit Lighthouse/Core Web Vitals (LCP, CLS, INP). Setze Cache-Header passend. Teste das Verhalten bei Datenbank-Ausfall und kalten Starts. In Next.js: export const revalidate = 3600, dynamic = 'force-dynamic', generateStaticParams, Server Components mit fetch und Cache-Optionen (Details der jeweiligen Version in der Doku prüfen, die API ändert sich).

Siehe auch: Next.js App Router, Caching-Strategien, Cache-Tags und revalidateTag, Lighthouse und Core Web Vitals, Serverless

Backlinks