Was ist der Unterschied?
Die Render-Strategie bestimmt, wann und wo HTML erzeugt wird. Das hat direkte Auswirkungen auf First Contentful Paint (FCP), Server-Last, Hosting-Kosten und die Art, wie du Caching und CDN nutzen kannst.
Server-Side Rendering (SSR) erzeugt HTML bei jeder Anfrage auf dem Server. Der Browser bekommt fertiges HTML — gut für SEO und personalisierte Inhalte, aber höherer Server-Bedarf. Frameworks: Next.js, Nuxt.js, SvelteKit.
Static Site Generation (SSG) erzeugt HTML einmal beim Build und liefert dieselbe Datei an jeden Besucher. Extrem schnell, minimale Server-Kosten, aber keine personalisierten Inhalte ohne Client-Side hydration. Frameworks: Gatsby, Hugo, Astro, Eleventy.
Incremental Static Regeneration (ISR) — der Mittelweg in Next.js: Seiten werden statisch ausgeliefert, aber bei Bedarf im Hintergrund neu gebaut. Das erlaubt hybrid-Architekturen ohne die Einschränkungen klassischer SSG.
Wichtig: Rendering = nicht dasselbe wie ein Vollständiges Laden
SSR und SSG bestimmen nur den initialen HTML-Output. Ob die Seite danach interaktiv ist (SPA-Verhalten, Client-seitige Navigation, hydration) hängt von der gewählten Client-Architektur ab. Eine "statische" Seite kann also durchaus React-Hydration nutzen — nur das erste HTML wurde vorab generiert.
Performance: Wer ist schneller?
SSG dominiert bei roher Geschwindigkeit — weil serverseitig nichts passieren muss. Eine statische HTML-Datei, die von einem CDN-Edge-Server ausgeliefert wird, erreicht TTFB-Werte unter 50ms. SSR-Seiten müssen erst berechnet werden, auch wenn der Server schnell ist.
Die Differenz wird sichtbar, wenn du die Core Web Vitals betrachtest:
- LCP (Largest Contentful Paint): SSG gewinnt deutlich — fertiges HTML bedeutet, der Browser kann sofort rendern. SSR muss erst den Request senden, Server muss HTML bauen, Netzwerk-Latenz dazukommt.
- INP (Interaction to Next Paint): Beide Ansätze ähnlich, wenn das Framework dieselbe Hydration-Architektur nutzt (z.B. Next.js im SSG- vs. SSR-Modus).
- CLS (Cumulative Layout Shift): SSG hat Vorteil, weil Layout-Inhalte im HTML feststehen. SSR kann durch spätes Script-Loading CLS verursachen.
Cache invalidation bei SSR ist teuer
SSR erzeugt pro Request frisches HTML — das klingt nach hoher Freshness, bedeutet aber, dass du für personalisierte Inhalte (Warenkorb, User-Dashboard, A/B-Tests) keine statischen Assets cached. SSG-Seiten mit gleichem Inhalt für alle Nutzer sind dagegen perfekte CDN-Kandidaten. Wenn du 100.000 Pageviews pro Tag hast, ist das ein massiver Kosten- und Performance-Unterschied.
SEO: Was bringt dir was?
Beide Strategien liefern vollständiges HTML — das ist besser als eine JavaScript-SPA, die erst im Browser rendert (Googlebot muss dann ein zweites Mal crawlen, um den Content zu sehen). Trotzdem gibt es Unterschiede:
SSR-Vorteile für SEO: Die Seite ist sofort beim ersten Request fertig — auch ohne JavaScript. Das vereinfacht das Crawling, besonders bei Seiten mit viel dynamischen Content (z.B. E-Commerce mit Preisen, Lagerbestand, personalisierten Empfehlungen). Google sieht den relevanten Inhalt sofort.
SSG-Vorteile für SEO: Schnellere Ladezeiten = höheres Ranking-Faktor. SSG-Seiten haben systematisch bessere Core Web Vitals. Keine Crawl-Budget-Probleme, weil statische Seiten von Suchmaschinen effizienter gecrawlt werden. Perfekt für Blogs, Dokumentation, Marketing-Seiten.
ISR (Next.js) als SEO-Compromise: Du bekommst SSG-Speed für die meisten Requests (CDN-cached), aber mit automatischer Regeneration bei Content-Updates. Das löst das Problem "Ich will frische Inhalte, aber keine Server-Last" — und ist besonders für Nachrichtenportale und Blogs ideal.
| Kriterium | SSR | SSG / ISR | Empfehlung |
|---|---|---|---|
| TTFB (CDN/Cached) | 80–400ms | <50ms | SSG |
| SEO-Performance | Sehr gut (sofortiges HTML) | Sehr gut (schneller + crawl-freundlich) | SSG |
| Personalisierte Inhalte | Volle Unterstützung | Eingeschränkt (nur client-seitig) | SSR |
| Hosting-Kosten | Server-Ressourcen pro Request | CDN + minimaler Origin | SSG |
| Build-Zeit (große Sites) | Kein Build nötig | Kann minutenlang sein (10.000+ Seiten) | ISR |
| Skalierung bei Traffic-Spike | Server muss skalieren (Auto-Scaling nötig) | CDN fängt Spike ab — kein Server-Scaling nötig | SSG |
| Echtzeit-Daten | Direkt integrierbar | Nur via Client-Side Fetching / WebSockets | SSR |
| Content-Updates | Sofort live (DB → HTML) | Erfordert Rebuild (oder ISR-Revalidation) | ISR |
Hosting-Anforderungen im Detail
SSR: Was du brauchst
SSR braucht einen Server, der bei jedem Request HTML generiert. Das bedeutet:
- Node.js-fähiger Server (Next.js, Nuxt, SvelteKit) oder PHP-Server (Symfony, Laravel, Statamic).
- Genug RAM und CPU für gleichzeitige Requests — besonders bei Traffic-Spikes oder aufwendigen API-Calls.
- Environment-Variablen für Datenbank-Verbindungen, API-Keys, Session-Management.
- Auto-Scaling-Kapazität, wenn der Traffic unpredictable ist.
Geeignete Hosting-Typen für SSR: VPS mit Node.js (z.B. Hetzner, DigitalOcean), Managed Node.js Platforms (Railway, Render, Vercel mit SSR-Funktion), Dedicated Server.
SSG: Was du brauchst
SSG braucht einen Build-Prozess (lokal oder CI/CD) und einen statischen Datei-Server oder CDN:
- Build-Toolchain (GitHub Actions, Netlify CI, Vercel Build) — der Build muss irgendwo laufen.
- CDN mit Edge-Servern für die statischen Assets (Cloudflare, Vercel Edge, Netlify CDN).
- Strikte Build-Zeit-Budgets: Wenn du 50.000 Produkte hast, ist ein Full-Rebuild inakzeptabel — du brauchst ISR oder einen On-Demand-Builder.
Geeignete Hosting-Typen für SSG: Vercel, Netlify (beide mit integriertem CDN), Cloudflare Pages, GitHub Pages (für einfache statische Sites), ein einfacher Nginx/VPS für statische Dateien.
Hybrid-Ansatz: Next.js macht es dir einfach
Next.js unterstützt SSR, SSG und ISR im selben Projekt. Du kannst für verschiedene Routen unterschiedliche Strategien wählen: getStaticProps für Blog-Artikel, getServerSideProps für User-Dashboards, und ISR für Produkt-Kategorien. Das vereint die Vorteile beider Welten — ohne separate Projekte.
Caching: Der entscheidende Faktor
Caching entscheidet bei beiden Strategien über die reale Performance — und über Hosting-Kosten:
| Cache-Typ | SSR | SSG | ISR |
|---|---|---|---|
| CDN Cache (Edge) | Kaum nutzbar (dynamisch, personalisiert) | Volle Nutzung — Dateien auf allen Edge-Nodes | Volle Nutzung (Serve stale, revalidate background) |
| Browser Cache | HTML nie cached (personalisiert) | HTML kann gecached werden (aber URLs ändern sich bei Rebuild) | HTML cached mit Cache-Control Header |
| Server-Side Cache (Redis/Varnish) | Möglich, aber macht SSR-Vorteil teilweise zunichte | Nicht nötig | Nicht nötig für gecachte Seiten |
| API-Response Cache | Individualisierbar pro User | Nur für gemeinsame Daten (Product Catalog, etc.) | Gemischte Strategie möglich |
Ein SSG-Blog mit Cloudflare CDN und Cache-Control: public, max-age=31536000, immutable auf statischen Assets liefert praktisch sofort — und verursacht kaum Serverkosten bei 500.000 Pageviews pro Monat. Ein SSR-Setup mit gleichem Traffic braucht deutlich mehr Server-Ressourcen und kann ohne Edge-Caching bei Traffic-Spikes in Probleme laufen.
Kosten im direkten Vergleich
Die Hosting-Kosten hängen stark vom gewählten Setup ab. Hier ein realistischer Vergleich für eine Website mit 200.000 Pageviews/Monat:
SSG-Kostenfallen: Build-Minutes bei Vercel/Netlify (bei vielen Pages), CDN-Bandwidth über Free-Tier, On-Demand-Rebuilds bei grossen Sites können teuer werden.
SSR-Kostenfallen: Auto-Scaling bei Traffic-Spikes, Datenbank-Kosten (Postgres, Redis), Server-Reboot-Zyklus, Monitoring und Logs.
Für ein Blog mit 50+ Artikeln ist SSG auf Netlify ($0 für den Free-Tier bei moderatem Traffic) oder einem eigenen VPS mit Nginx ($3–5/Monat bei Hetzner) unschlagbar. Bei einem E-Commerce mit 10.000 Produkten und personalisierten Recommendations ist SSR + CDN-Strategie unvermeidlich.
Fazit: Wähle based auf deinem Content-Typ
Es gibt kein "besser" — nur "richtig für deinen Anwendungsfall":
- Blog, Portfolio, Dokumentation, Marketing-Site: SSG. Maximale Performance, minimale Kosten, einfaches Hosting. Nutze Astro, Hugo oder Next.js mit
getStaticProps. - Nachrichtenportal, Content-heavy E-Commerce: ISR. Frische Inhalte mit SSG-Speed. Next.js mit
revalidate: 60(Rebuild alle 60 Sekunden im Hintergrund). - User-Dashboard, personalisierter Content, SaaS: SSR. Session-Daten, dynamische Inhalte — hier lohnt sich die Server-Last. Nutze Next.js SSR oder Nuxt.js.
- Hybrid: Next.js, Nuxt, SvelteKit: Alle modernen Full-Stack-Frameworks unterstützen beide Strategien. Nutze das für jede Route individuell.
Der beste Weg: starte mit SSG und wechsle zu ISR oder SSR nur dort, wo du es wirklich brauchst. Das spart Hosting-Kosten und gibt dir die Performance-Vorteile, die für die meisten Websites entscheidend sind.
Performance-optimiertes Hosting finden
VPS mit SSD, Node.js-Support, und CDN-Anbindung — für SSR, SSG und jede hybride Architektur.
Zum Hosting-Vergleich