Next.js SSR vs SSG vs ISR: Leitfaden zur Wahl der Rendering-Strategie

„Warum braucht die Startseite drei Sekunden?“ Der Chef starrte auf den Chrome-DevTools-Waterfall – die rote TTFB-Zeile wirkte wie eine Schlange. Da wurde mir klar: Vielleicht hatten wir von Anfang an die falsche Rendering-Strategie gewählt.

Das ist kein Einzelfall. In den Next.js-GitHub-Issues fragen täglich Leute: „SSR oder SSG?“ „Warum greift mein ISR nicht?“ Auch ich war anfangs unsicher – Dokumentation gelesen, im konkreten Projekt trotzdem ratlos.

Vielleicht kennen Sie ähnliche Fragen:

• SSR eingesetzt – und der First Paint ist zum Verzweifeln langsam
• SSG gewählt – jede Content-Aktualisierung erfordert einen kompletten Rebuild
• ISR klingt ideal – konfiguriert, wirkt aber gar nicht

Es gibt keine „beste“ Strategie – nur die passende. Heute klären wir, welche Strategie wann sinnvoll ist und welche Fallen Sie vermeiden sollten.

Zuerst klären: Was sind die drei Rendering-Strategien?

Bevor wir über die Wahl sprechen, schauen wir uns die drei Konzepte in einfachen Worten an.

SSG (Statische Seitengenerierung): Das vorbereitete Lunchbox-Modell

Stellen Sie sich einen Lunchbox-Laden vor: Morgens bereiten Sie 100 Boxen vor, Kunden greifen und gehen. So arbeitet SSG.

Konkret:

• Wann generiert? Beim next build erzeugt Next.js HTML für alle Seiten
• Beim Besuch: CDN liefert vorgefertigtes HTML – sehr schnell
• Wann passend? Selten geänderte Inhalte: Unternehmenswebsite, Produktseiten, Blog-Artikel

Vorteile:

• Sehr schnell – laut AWS ist SSG 40–60 % schneller als SSR
• TTFB (Time to First Byte) meist unter 50 ms (Vercel-Messungen)
• Kaum Serverlast – auch bei hohem Traffic
• Günstig – statisches Hosting kostet wenig

Grenzen:

• Content-Update? Rebuild der gesamten Site nötig
• Viele Seiten → lange Build-Zeiten (tausende Seiten: bis zu 30 Minuten)
• Keine Personalisierung – alle Nutzer sehen dasselbe

Kurz: SSG tauscht Geschwindigkeit gegen Vorab-Arbeit.

SSR (Serverseitiges Rendering): Frisch zubereitet auf Bestellung

Wieder der Lunchbox-Laden – diesmal ohne Vorbereitung. Bestellt der Kunde, kochen Sie live. Das ist SSR.

Konkret:

• Wann generiert? Bei jedem Request generiert der Server HTML in Echtzeit
• Beim Besuch: Server fragt DB/API ab, rendert HTML, liefert aus
• Wann passend? Echtzeit-Inhalte oder Personalisierung

Vorteile:

• Immer aktuell – Nutzer sehen Daten vom Moment des Requests
• Personalisierung per Cookie, Berechtigung, Präferenz
• Zugriff auf Request-spezifische Infos: Header, Query-Parameter

Nachteile:

• Langsamer – TTFB typischerweise 200–500 ms (Vercel)
• Hohe Serverlast bei Traffic-Spitzen
• Höhere Kosten – Server läuft dauerhaft

Praxis-Fall: Ein E-Commerce-Shop mit SSR – First Paint 2,3 s. Nach Umstellung auf ISR: 0,8 s.

ISR (Inkrementelle statische Regenerierung): Lunchbox plus frische Zubereitung

Sie kombinieren beides: Boxen stehen bereit, alle paar Stunden erneuern Sie den Inhalt. Kunden bekommen meist vorbereitetes Essen, das nicht veraltet ist. Das ist ISR.

Konkret:

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

• Erster Build: next build erzeugt statisches HTML (wie SSG)
• Updates: Nach revalidate regeneriert das System Seiten im Hintergrund
• Beim Besuch: Meist gecachtes HTML (schnell), bei Ablauf Hintergrund-Update

Balance:

• SSG-Geschwindigkeit (statische Dateien)
• SSR-Frische (regelmäßige Updates)
• Kein Full-Site-Rebuild bei jeder Änderung

Konfiguration (App Router):

// app/posts/[id]/page.tsx
export const revalidate = 60; // 60 Sekunden bis zur erneuten Validierung

export default async function Post({ params }) {
  const post = await getPost(params.id);
  return <div>{post.content}</div>;
}

Typische Fallen:

• Konfiguration wirkt nicht? Oft Test in next dev – ISR läuft nur in Produktion (next build + next start)
• Hosting ohne native ISR-Unterstützung? Vercel nativ, andere Plattformen ggf. Extra-Setup

ISR ist für mich die meistgenutzte Strategie – sie löst die Schwächen von SSG und SSR elegant.

Entscheidungsbaum: Welche Strategie für welches Szenario?

Konzepte klar – jetzt die Kernfrage: Was passt zu Ihrem Projekt?

Keine Panik – dieser Ablauf führt Sie Schritt für Schritt.

Schritt 1: Drei Fragen an sich selbst

Frage 1: Braucht der Inhalt Personalisierung?

Wenn Seiten je nach Identität, Berechtigung oder Präferenz unterschiedlich aussehen → SSR.

Typische Szenarien:

• User-Dashboard (jeder sieht andere Daten)
• Profilseite
• Warenkorb
• Authentifizierte Bereiche

Warum? Personalisierte Inhalte lassen sich nicht vorab generieren.

Frage 2: Wie oft ändert sich der Inhalt?

Das entscheidet zwischen SSG und ISR.

• Alle paar Sekunden bis Minuten: SSR

  • Börsenkurse, Live-Sport, Chat
  • Hohe Echtzeit-Anforderung – SSR ist die Wahl

• Alle paar Minuten bis Stunden: ISR

  • News, Blog-Startseite, Produktlisten, Lagerbestand
  • revalidate: 300 (5 Min.) – schnell und aktuell genug

• Selten oder manuell: SSG

  • Unternehmenswebsite, Produktseiten, Hilfe-Docs
  • Änderungen alle paar Wochen oder Monate

Frage 3: Wie hoch ist der Traffic?

Traffic beeinflusst Kosten und Performance.

• Sehr hoch (Millionen PV/Tag): SSG oder ISR bevorzugen

  • Statische Dateien über CDN – günstig und schnell
  • SSR unter Last: hohe Kosten und Serverdruck

• Mittel bis niedrig: Alle drei möglich

  • Bei Echtzeit-Anforderung ist SSR vertretbar
  • Wenn ISR reicht – warum nicht nutzen?

Schritt 2: Szenarien auf einen Blick

Typische Fälle zum Abgleich:

SSG:

• ✅ Unternehmenswebsite
• ✅ Produkt- und Pricing-Seiten
• ✅ Marketing-Landingpages
• ✅ Blog-Artikel (nach Veröffentlichung unverändert)
• ✅ Technische Docs, API-Dokumentation
• ✅ Hilfe-Center, FAQ

Stichwort: statisch, öffentlich, selten aktualisiert

SSR:

• ✅ Social-Feed (Facebook/Twitter-Stil)
• ✅ Persönliches Dashboard
• ✅ Warenkorb, Bestellungen
• ✅ Live-Datenpanels
• ✅ Suchergebnisse (Query-abhängig)
• ✅ Authentifizierte Seiten (Cookie-basiert)

Stichwort: dynamisch, personalisiert, Echtzeit

ISR (mein Favorit):

• ✅ Blog-Startseite, Artikellisten
• ✅ News-Websites
• ✅ E-Commerce-Produktdetails (Preis, Bestand)
• ✅ Forum-Threads (Kommentare/Likes mit Minuten-Verzögerung ok)
• ✅ UGC-Plattformen
• ✅ Wetter, Wechselkurse

Stichwort: regelmäßige Updates, akzeptable Verzögerung, hoher Traffic

Schritt 3: Mix ist die Regel

Ein Irrtum: Die ganze Site muss nicht eine Strategie nutzen.

Die meisten Projekte mischen:

• Startseite und Produktliste → ISR (Traffic, regelmäßige Updates)
• Produktdetails → SSG (stabil) oder ISR (Preis/Bestand)
• Dashboard → SSR (Personalisierung)
• Über uns, Kontakt → SSG (statisch)

Unser E-Commerce-Projekt:

• Startseite (ISR, 10 Min.)
• Produktliste (ISR, 5 Min.)
• Produktdetails (ISR, 3 Min. – Bestand ändert sich)
• Warenkorb (SSR, Echtzeit)
• User-Bereich (SSR, personalisiert)
• Über uns, Datenschutz (SSG, fast statisch)

So bleiben Performance und Aktualität im Gleichgewicht.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Merksatz in einem Satz

Im Zweifel:

Statisch → SSG, Echtzeit → SSR, regelmäßige Updates → ISR

Unsicher? Probieren Sie ISR – die ausgewogenste Wahl mit geringstem Fehlerrisiko.

Drei häufige Fallen und Lösungen

Theorie reicht – diese drei Fallen kenne ich aus eigener Erfahrung.

Falle 1: ISR revalidate wirkt nicht

Symptom: Sie setzen revalidate: 60, erwarten minütliche Updates – Inhalt bleibt alt.

Mein erster Frust: Zwei Tage festgehangen, unzählige Docs gelesen – nichts half.

Drei Ursachen:

1. Entwicklungsmodus unterstützt kein ISR

   Häufigste Ursache: Unter next dev läuft ISR nicht – nur in Produktion.

   Lösung:

   # ISR nicht mit next dev testen
   # Erst bauen, dann starten
   npm run build
   npm run start
   
   # Dann Seite aufrufen und testen

2. Hosting ohne ISR-Unterstützung

   Nicht jede Plattform unterstützt ISR nativ. Vercel (Next.js-Hersteller) ja – andere ggf. nicht.

   Netlify: Plugin @netlify/plugin-nextjs für ISR nötig.

   Prüfen: In der Hosting-Doku nach „Next.js ISR support“ suchen.

3. CDN-Cache überschreibt ISR

   CDN oder Reverse Proxy (z. B. Cloudflare) vor Next.js kann Responses cachen und ISR-Updates blockieren.

   Lösung: CDN soll Cache-Control respektieren oder kurze Cache-Zeit für ISR-Seiten.

Tipp: ISR immer in Produktion testen. console.log(new Date()) zeigt die Generierungszeit.

Falle 2: SSR First Paint extrem langsam

Symptom: SSR-First-Paint 2–3 Sekunden – Nutzer springen ab.

Praxis-Fall: Startseite mit SSR für User-Info und Empfehlungen – TTFB 1,2 s, insgesamt 3 s bis sichtbarer Content. Der Chef war nicht begeistert.

Typische Ursachen:

SSR ist langsam, wenn die Datenerfassung auf dem Server dauert:

• Langsame API-Calls (externe Latenz)
• Langsame DB-Queries (fehlende Indizes, komplexe Abfragen)
• Serielle Requests
• Schwache Server oder große geografische Distanz

Vier Lösungsansätze:

1. Streaming SSR und Suspense (React 18+)

   Nicht auf alle Daten warten – zuerst Seitenrahmen, Daten per Stream.

   // app/dashboard/page.tsx
   import { Suspense } from 'react';
   
   export default function Dashboard() {
     return (
       <div>
         <h1>User-Dashboard</h1>
         {/* Schnell renderbarer Teil */}
         <UserInfo />
   
         {/* Langsame Daten in Suspense */}
         <Suspense fallback={<div>Statistiken werden geladen...</div>}>
           <SlowStats />
         </Suspense>
       </div>
     );
   }

   Nutzer sehen die Seite schneller.

2. Parallele Daten-Requests

   // ❌ Seriell: langsam
   const user = await getUser();
   const posts = await getPosts(user.id);
   
   // ✅ Parallel: schnell
   const [user, posts] = await Promise.all([
     getUser(),
     getPosts()
   ]);

3. ISR in Betracht ziehen

   Oft reicht ISR statt SSR.

   Frage: Muss der Inhalt wirklich live sein? Wenn 1 Minute Verzögerung ok ist → ISR.

   Unsere Startseite: ISR mit revalidate: 60 – First Paint von 3 s auf 0,7 s.

4. Edge-Deployment

   Auf Vercel: Edge Functions – SSR näher am Nutzer, geringere Latenz.

   // app/api/data/route.ts
   export const runtime = 'edge'; // nur diese Zeile

Falle 3: SSG-Build dauert ewig

Symptom: Tausende Seiten – next build 20–30 Minuten oder Timeout.

Szenario: E-Commerce mit 5.000 Produkten, Blog mit 3.000 Artikeln – SSG generiert HTML für jede Seite beim Build.

Warum langsam:

SSG baut alle Seiten beim Build. Viele Seiten werden selten besucht (Long-Tail-Produkte, alte Artikel).

Lösungen:

1. Fallback-Strategie

   Nicht alle Seiten auf einmal – nur Top-Seiten vorab, Rest on-demand.

   // app/posts/[id]/page.tsx
   export async function generateStaticParams() {
     // Nur Top-100-Artikel
     const posts = await getTopPosts(100);
     return posts.map(post => ({ id: post.id }));
   }
   
   // Andere Seiten beim ersten Besuch generieren
   export const dynamicParams = true;

2. Mit ISR kombinieren

   Build nur Startseite und Top-Seiten – Rest per ISR on-demand.

   Kürzere Build-Zeit, Besucher merken keinen Unterschied (Cache).

3. Incremental Builds

   Vercel baut nur geänderte Seiten neu. Ein Artikel-Update ≠ Full-Site-Rebuild.

   Andere Plattformen: eigene Logik nötig.

Praxis-Ergebnis:

Blog mit 2.000 Artikeln – reines SSG: 15 Min. Build. Danach:

• Build nur der neuesten 50 Artikel
• Rest mit dynamicParams = true on-demand
• Alle Artikel-Seiten mit ISR (revalidate: 3600)

Build: 2 Minuten – Besuchergeschwindigkeit unverändert.

Next.js 15: React Server Components und PPR

Kurz zwei Neuerungen in Next.js 15 – sie sind keine „Rendering-Strategien“, beeinflussen aber, wie wir Seiten bauen.

React Server Components (RSC): SSR auf Komponentenebene

Mit Next.js 13+ App Router nutzen Sie Server Components bereits.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Unterschied zu klassischem SSR:

• Klassisches SSR: ganze Seite serverseitig
• RSC: Komponenten standardmäßig serverseitig – nur interaktive Teile im Client

Vorteile:

1. Kleineres JS-Bundle

   Server-Component-Code landet nicht im Client-Bundle. Laut Next.js 30–50 % weniger Client-JavaScript.

   Schnellere Ladezeiten, weniger Last auf dem Handy.

2. Direkter Backend-Zugriff

   Server Components können DB und Dateisystem direkt ansprechen – ohne API-Layer.

   // app/posts/page.tsx
   // Server Component – direkter DB-Zugriff
   async function getPosts() {
     const posts = await db.posts.findMany();
     return posts;
   }
   
   export default async function PostsPage() {
     const posts = await getPosts();
     return (
       <div>
         {posts.map(post => (
           <PostCard key={post.id} post={post} />
         ))}
       </div>
     );
   }

Praxis-Empfehlung:

• Standard: Server Component (App Router-Default)
• Client Component nur bei Interaktion ('use client')
• Daten und statische UI: Server Component; Buttons, Formulare, Animation: Client Component

So behalten Sie SEO-Vorteile von SSR bei minimalem JS-Bundle.

Partial Prerendering (PPR): Statisch und dynamisch auf einer Seite

PPR (Next.js 15, experimentell) mischt statische und dynamische Teile auf derselben Seite.

Beispiel E-Commerce-Produktseite:

• Beschreibung, Bilder (statisch, beim Build)
• Bestand, Preis (dynamisch, pro Request)

Statischer Teil beim Build, dynamischer bei jedem Request – schnell und aktuell.

Verwendung:

// next.config.js
module.exports = {
  experimental: {
    ppr: true,
  },
};

// app/products/[id]/page.tsx
export const experimental_ppr = true;

export default function ProductPage({ params }) {
  return (
    <div>
      {/* Statisch: beim Build */}
      <ProductDescription id={params.id} />

      {/* Dynamisch: pro Request */}
      <Suspense fallback={<div>Wird geladen...</div>}>
        <DynamicStock id={params.id} />
      </Suspense>
    </div>
  );
}

Wichtig:

PPR ist noch experimentell – nicht für Produktion empfohlen. Auf unkritischen Seiten testen.

Wenn stabil (evtl. Next.js 16?), wird es sehr mächtig.

Wie passen RSC/PPR zu SSR/SSG/ISR?

• RSC + SSG: Server Components standardmäßig statisch – ideal mit SSG
• RSC + ISR: Server Component + revalidate – statisch und regelmäßig aktualisiert
• RSC + SSR: dynamische Route oder dynamic = 'force-dynamic'
• PPR: SSG und SSR in einer Seite vereint

Mein Verständnis: RSC ist die Architektur-Ebene, SSG/SSR/ISR die Strategien darauf – sie ergänzen sich, statt zu konkurrieren.

Fazit

Zurück zur Kernfrage: SSR, SSG oder ISR?

Es gibt keine Standardantwort. Projekt, Traffic und Budget unterscheiden sich. Mit drei Fragen wird die Wahl einfacher:

1. Personalisierung nötig? → SSR
2. Wie oft Updates? → Echtzeit SSR, regelmäßig ISR, selten SSG
3. Wie viel Traffic? → Sehr hoch: SSG oder ISR

Erinnern Sie sich an die Startseite mit 3 s Ladezeit? Nach Umstellung von SSR auf ISR (revalidate: 60): 0,8 s. Chef zufrieden, Nutzer auch.

Empfehlung:

• Im Zweifel ISR – ausgewogen, schnell, Inhalt bleibt frisch
• Nach Go-Live: Chrome DevTools Performance – TTFB, FCP messen
• Pro Seite andere Strategie – nicht dogmatisch

Rendering-Strategien sind nicht für immer. Mit Wachstum und neuen Anforderungen anpassen. Next.js macht Wechsel relativ günstig.

Ich hoffe, Sie vermeiden ein paar Fallen. Praxis-Erfahrungen oder eigene Geschichten? Teilen Sie sie gerne in den Kommentaren!