SSR, CSR, SSG und ISR: der tatsächliche Unterschied
SSG erzeugt HTML vor dem Nutzerrequest, meist beim Build. SSR erzeugt HTML auf dem Server pro Request. CSR baut große Teile der Oberfläche erst nach JavaScript-Ausführung im Browser. ISR hält statische Ergebnisse vor und regeneriert ausgewählte Seiten nach dem Deployment per Zeitregel oder Cache-Invalidierung. [6][9][16]
Wichtiger als das Label ist daher: Wann entsteht HTML, wie lange wird es gecacht und wie viel Arbeit bleibt dem Browser?
SEO: Google rendert JavaScript, aber CSR ist nicht gleich Prerendering
Google beschreibt JavaScript-Verarbeitung als Crawling, Rendering und Indexing. Fehlt der eigentliche Inhalt im initialen HTML, muss Googles Web Rendering Service JavaScript ausführen und die Seite landet in einer Render-Warteschlange. [1]
Google empfiehlt weiterhin Server-Side Rendering oder Prerendering, weil dies Nutzer und Crawler beschleunigt und nicht alle Bots JavaScript ausführen können. [1]
CSR kann also funktionieren, aber für wichtige öffentliche Inhalte ist fertiges HTML robuster.
SSG: ideal für Inhalte ohne Request-Time-Aktualität
Bei SSG entsteht HTML beim Build und kann danach als statische Datei über ein CDN ausgeliefert werden. Next.js empfiehlt Static Generation, wenn eine Seite vor dem Request vorbereitet werden kann. [9][12]
Typische Fälle sind Landingpages, Dokumentation, Artikel, Hilfeseiten, Portfolios und Teile von Produktkatalogen. [10][16]
Grenzen entstehen bei sehr häufigen Änderungen oder extrem großen Builds.
SSR: wenn Daten frisch oder requestabhängig sein müssen
SSR erzeugt HTML für einen konkreten Request und kann aktuelle Daten, Header, Cookies, Lokalisierung oder Query-Parameter berücksichtigen. [6][10][11]
Für SEO liegt der Inhalt direkt als HTML vor. Dafür fällt Serverarbeit bei jedem Request an, und langsames Rendering kann TTFB erhöhen. [6]
Stabile Teile können trotzdem gecacht werden, während nur requestabhängige Bereiche dynamisch bleiben.
ISR: statisches HTML mit kontrollierter Aktualität
ISR kombiniert statische Auslieferung mit Regeneration nach dem Deployment. Next.js beschreibt die Aktualisierung statischer Seiten nach dem Build, Nuxt 4 bietet ähnliche Mechanismen über `isr` und `swr`. [9][13][16]
Das passt zu Produktkatalogen, Artikeln, Dokumentation und Kategorien, deren Inhalt sich regelmäßig, aber nicht in Echtzeit ändert.
Bei stale-while-revalidate kann der erste Request nach Ablauf noch die alte Version erhalten, während im Hintergrund neu generiert wird. [13][16]
CSR: sinnvoll, wenn Indexierung nicht nötig ist
Bei CSR muss der Browser JavaScript laden, parsen und ausführen, bevor große Teile des DOM entstehen. web.dev weist darauf hin, dass große JavaScript-Pakete insbesondere auf mobilen Geräten INP verschlechtern können. [6][7]
Nuxt nennt SaaS-Oberflächen, Backoffice, Spiele und andere stark interaktive, nicht indexierungspflichtige Anwendungen als passende Fälle. [13]
Für öffentliche Inhalte steigt die Abhängigkeit von JavaScript-Fähigkeiten der Crawler. [1][2]
SEO- und Performance-Vergleich
| Modus | Wann HTML entsteht | Inhalt im initialen HTML | Aktualität | Request-Kosten | SEO |
|---|---|---|---|---|---|
| SSG | Build | Ja | Bis zum nächsten Build | Sehr niedrig | Sehr gut |
| ISR | Build oder Revalidierung | Ja | Abhängig von Revalidierung | Niedrig | Sehr gut |
| SSR | Jeder Request | Ja | Sehr hoch | Höher | Sehr gut |
| CSR | Im Browser | Oft begrenzt | Hoch nach Fetch | Server niedrig, Client höher | Möglich, aber weniger optimal |
Es gibt keine universelle Rangfolge. SSG und ISR haben meist Cache- und Kostenvorteile, SSR liefert Request-Frische, CSR verlagert mehr Arbeit in den Browser. [6][9][13]
Für SEO können SSG, ISR und SSR aussagekräftiges HTML sofort liefern. CSR kann Google indexieren, benötigt aber zusätzliches Rendering. [1][9]
Core Web Vitals: Rendering ist nur ein Faktor
| Metrik | Gut | Schlecht | Misst |
|---|---|---|---|
| LCP | ≤ 2.5 s | > 4.0 s | Laden des Hauptinhalts |
| INP | ≤ 200 ms | > 500 ms | Interaktionsreaktion |
| CLS | ≤ 0.1 | > 0.25 | Visuelle Stabilität |
Google verwendet Core Web Vitals in Ranking-Systemen, betont aber, dass gute Werte keine Top-Position garantieren. Die aktuellen Kennzahlen sind LCP, INP und CLS. [4][5]
Als gut gelten LCP bis 2,5 s, INP bis 200 ms und CLS bis 0,1 am 75. Perzentil. [4][8]
SSG kann HTML schnell liefern und trotzdem durch viel JavaScript schlechten INP erzeugen. SSR kann FCP verbessern, aber ein langsamer Server verschlechtert TTFB. [6][7]
Hydration: SSR ist nach dem HTML noch nicht fertig
Viele Frameworks hydratisieren SSR- oder SSG-Ausgabe, indem sie nachträglich State und Event-Handler an das HTML binden. web.dev warnt, dass vollständige Rehydration TBT und INP belasten kann. [6]
Eine Seite kann deshalb fertig aussehen, aber noch nicht reagieren.
Weniger Client-JavaScript, Code Splitting, Lazy Loading und teilweise Hydration helfen. Nuxt 4 dokumentiert sogar weitgehend statische Seiten mit nahezu keinem JavaScript. [7][14]
Cache und Aktualität: die zentrale Entscheidung
SSG verwendet ein Ergebnis bis zum nächsten Build. ISR ergänzt Revalidierung. SSR kann pro Request neu rendern, aber ebenfalls Server- oder CDN-Caching nutzen. [6][13][16]
Die richtige Strategie hängt vom maximal akzeptablen Datenalter ab. Minutenalte Produktdaten können ISR erlauben, ein aktueller Kontostand eher nicht.
Cache sollte möglichst mit realen Inhaltsänderungen statt willkürlich kurzen TTLs verknüpft werden.
SEO besteht aus mehr als Rendering
HTML ersetzt keine korrekten HTTP-Statuscodes, crawlbaren Links, Canonicals, Sitemaps, Titel oder Metadaten. Google empfiehlt eindeutige URLs und crawlbare Links für wichtige Inhalte. [1][2]
Auch SSR kann fehlerhafte 200-Seiten, Duplikate oder falsche Metadaten erzeugen. Rendering ist nur ein Teil technischen SEO.
Dynamic Rendering wird von Google nicht mehr als langfristige Lösung empfohlen. Stattdessen nennt Google SSR, Static Rendering oder Hydration. [3]
Welche Strategie für welche Seite
Landingpages, Blogs und Dokumentation passen meist zu SSG. Große Kataloge oder periodisch aktualisierte News passen oft zu ISR. Requestabhängige öffentliche Inhalte können SSR brauchen. Private Dashboards können CSR bleiben. [9][13]
E-Commerce kann mehrere Modelle kombinieren: statische Kategorie, ISR für Produktseiten, SSR für Session-Daten und CSR für Filterinteraktion.
Die Entscheidung sollte pro Route getroffen werden.
Realität 2026: hybride Modelle werden granularer
Next.js 16.3.4 dokumentiert Cache Components, `use cache`, Revalidierung auf Daten- und UI-Ebene, statische Shells und Streaming für Request-Time-Daten. Die aktuelle Caching-Dokumentation wurde am 25. August 2026 aktualisiert. [11]
Nuxt 4 erlaubt `prerender`, `ssr`, `swr` und `isr` über Route Rules pro Route. [13][14]
Die vier Begriffe bleiben nützliche Denkmodelle, beschreiben aber nicht mehr jede moderne Seite komponentengenau.
CSR für SEO schrittweise verbessern
Zuerst sollten nur öffentliche Routen identifiziert werden, die organischen Traffic erhalten sollen. Ein privates Dashboard muss nicht allein aus Konsistenzgründen zu SSR werden.
Danach gehören kritischer Inhalt, Titel, Metadaten und Links in HTML, das vor Client-JavaScript entsteht. Google empfiehlt SSR oder Prerendering statt Dynamic Rendering. [1][3]
Anschließend müssen Search Console, gerendertes HTML und Felddaten der Core Web Vitals überprüft werden.
Praktische Entscheidungsregel
Kann eine Seite vorab erzeugt werden und ist ihr Inhalt für alle gleich, starte mit SSG. Ändert sie sich periodisch, prüfe ISR. Muss das Ergebnis requestabhängig und im HTML vorhanden sein, nutze SSR. Ist es eine private Anwendung ohne SEO-Ziel, reicht oft CSR. [9][13]
Validiere anschließend TTFB, LCP, INP, CLS, Serverkosten, Änderungsfrequenz, Seitenanzahl und Personalisierung.
- Muss der Hauptinhalt indexiert werden?
- Kann HTML vor dem Request entstehen?
- Wie frisch müssen Daten sein?
- Hängt das Ergebnis von Cookies, Session oder Request ab?
- Wie viele Routen müssen gebaut werden?
- Kann die Seite sicher gecacht werden?
- Wie viel JavaScript muss der Browser ausführen?
- Wie sehen LCP, INP, CLS und TTFB in Produktion aus?
