SSG (Static Site Generation) liefert die beste Ladezeit für statische Inhalte mit Werten unter einer Sekunde, SSR (Server-Side Rendering) ist ideal für dynamische Seiten mit SEO-Anforderung, und CSR (Client-Side Rendering) eignet sich primär für Anwendungen hinter einem Login. Die Wahl der Rendering-Strategie beeinflusst direkt die SEO-Sichtbarkeit, Core Web Vitals und Conversion-Rate einer Website. Für die meisten KMU-Websites ist 2026 ein hybrider Ansatz aus SSG und SSR der technische Standard.
Was bedeuten SSR, CSR und SSG?
Beim Server-Side Rendering (SSR) generiert der Server bei jedem Seitenaufruf das fertige HTML. Der Browser erhält eine vollständig gerenderte Seite, die sofort angezeigt werden kann. Frameworks wie Angular Universal, Next.js und Nuxt.js unterstützen SSR nativ.
Client-Side Rendering (CSR) funktioniert anders: Der Server liefert nur ein minimales HTML-Gerüst und JavaScript-Bundles. Der Browser muss erst das gesamte JavaScript laden und ausführen, bevor Inhalte sichtbar werden. Single-Page-Applications (SPAs) wie klassische Angular- oder React-Apps nutzen diesen Ansatz.
Static Site Generation (SSG) erzeugt alle HTML-Seiten bereits zur Build-Zeit. Die fertigen Dateien werden als statische Dateien ausgeliefert, ohne dass ein Server zur Laufzeit rechnen muss. Frameworks wie Astro, Eleventy oder Angular mit Prerendering setzen auf diesen Ansatz.
SEO-Auswirkungen: Warum CSR ein Problem ist
Google kann JavaScript-gerenderte Seiten grundsätzlich crawlen, aber mit Einschränkungen. Der Googlebot hat ein begrenztes Crawl-Budget und verarbeitet JavaScript in einer separaten Rendering-Queue. Laut Google-eigenen Angaben kann die Indexierung von CSR-Seiten Tage bis Wochen länger dauern als bei vorgerenderten Seiten.
SSR und SSG liefern dem Crawler sofort vollständiges HTML. Das bedeutet: schnellere Indexierung, zuverlässigere Erfassung aller Inhalte und bessere Chancen auf Featured Snippets. Für KMU-Websites, deren Sichtbarkeit direkt umsatzrelevant ist, ist das ein entscheidender Vorteil.
- CSR: Indexierung verzögert, Crawl-Budget wird belastet, Meta-Tags oft nicht zuverlässig erfasst
- SSR: Vollständiges HTML bei jedem Request, ideal für dynamische und personalisierte Inhalte
- SSG: Schnellste Auslieferung, perfekt für Content-Seiten, Blogs und Landingpages
- Hybrid: Kombination aus SSG für statische Seiten und SSR für dynamische Bereiche
Performance im Vergleich: Die Zahlen sprechen deutlich
Die Performance-Unterschiede sind messbar und erheblich. Eine typische CSR-Anwendung hat eine Time to Interactive (TTI) von 3 bis 8 Sekunden, abhängig von der Bundle-Größe. SSR reduziert die TTI auf 1,5 bis 3 Sekunden, weil das HTML sofort da ist und das JavaScript im Hintergrund hydratisiert. SSG erreicht Werte unter 1 Sekunde, da kein Server-Rendering zur Laufzeit nötig ist.
Für die Core Web Vitals bedeutet das konkret: SSG-Seiten erreichen nahezu immer grüne Werte beim Largest Contentful Paint (LCP unter 2,5 Sekunden). CSR-Seiten kämpfen oft mit LCP-Werten über 4 Sekunden, besonders auf mobilen Geräten mit schwacher Netzanbindung.
Wann welche Strategie die richtige ist
Die Entscheidung hängt vom Anwendungsfall ab. Nicht jede Website braucht SSR, und nicht jede profitiert von reinem SSG. Entscheidend sind drei Faktoren: Wie dynamisch sind die Inhalte? Wie wichtig ist SEO? Und wie häufig ändern sich die Daten?
- Unternehmenswebsite mit festen Inhalten: SSG ist die beste Wahl. Seiten ändern sich selten, Performance ist maximal, Hosting-Kosten minimal.
- Online-Shop mit Produktseiten: SSG für den Katalog, SSR für personalisierte Bereiche wie Warenkorb und Checkout.
- Web-Applikation hinter Login: CSR ist hier völlig ausreichend, da SEO keine Rolle spielt.
- News-Portal mit häufigen Updates: SSR oder Incremental Static Regeneration (ISR) für aktuelle Inhalte bei gleichzeitig guter Performance.
- Landingpages für Marketingkampagnen: SSG liefert maximale Ladegeschwindigkeit und damit bessere Conversion-Raten.
Frameworks und ihre Rendering-Optionen
Moderne Frameworks unterstützen inzwischen hybride Strategien. Angular ab Version 17 bietet mit dem Application Builder sowohl SSR als auch SSG (Prerendering) mit einer einzigen Konfiguration. Next.js (React) war Vorreiter des hybriden Ansatzes und erlaubt seitenweise Entscheidung zwischen SSR, SSG und ISR. Astro geht einen anderen Weg: Es rendert standardmäßig statisch und liefert kein JavaScript an den Browser, es sei denn, eine Komponente benötigt explizit Interaktivität.
Für KMU-Projekte ist die Wahl des Frameworks oft weniger entscheidend als die korrekte Konfiguration der Rendering-Strategie. Ein falsch konfiguriertes Next.js-Projekt kann schlechter performen als eine gut optimierte WordPress-Seite. Entscheidend ist das Verständnis der Architektur.
Fazit: Hybrid ist der Standard von 2026
Reine CSR-Websites sind für SEO-relevante Projekte nicht mehr zeitgemäß. Der Industriestandard 2026 ist eine hybride Architektur: statische Seiten werden zur Build-Zeit generiert (SSG), dynamische Bereiche nutzen SSR, und interaktive Komponenten hydratisieren selektiv im Browser.
Für KMU bedeutet das: Wer eine neue Website plant oder eine bestehende modernisiert, sollte die Rendering-Strategie früh in der Planung festlegen. Die Entscheidung beeinflusst SEO-Ergebnisse, Ladezeiten und letztlich die Conversion-Rate. Eine fundierte technische Beratung zahlt sich hier direkt aus.
