Was ist Static Site Generation (SSG)?

Was ist Static Site Generation (SSG)?

Static Site Generation (SSG) ist die Praxis, alle Seiten einer Website zur Build-Zeit zu plain HTML-Dateien vor-zu-rendern und diese Dateien dann direkt aus einem CDN zu servieren, ohne Runtime-Datenbank-Queries oder Server-Side-Rendering. Das Ergebnis: Page-Loads schließen in zehn Millisekunden ab, weil der Server (das CDN-Edge) einfach eine fertige HTML-Datei aushändigt. Keine Backend-Logik läuft pro Request. Keine Datenbankverbindung. Keine Template-Engine. Nur Bytes rein → Bytes raus.

SSG ist eine von drei Haupt-Rendering-Strategien für Webseiten. Die anderen sind SSR (Server-Side Rendering. HTML pro Request auf dem Server generiert) und CSR (Client-Side Rendering, leere HTML-Shell mit JavaScript, das Daten im Browser fetcht und rendert). SSG sitzt am schnell-billig-sicheren Ende des Spektrums: Page-Loads sind unschlagbar schnell, Hosting-Kosten tendieren gegen null und die Angriffsfläche ist minimal, weil es keine Runtime-Server-Logik gibt, die ausgenutzt werden kann.

Wie SSG funktioniert

Der Build-Step:

1. Source-Content lebt in Dateien. Markdown, YAML, JSON oder ein Headless CMS. Designer/Writer editieren Content in einem freundlichen Format.
2. Ein Build-Tool liest Content + Templates + Daten. Next.js, Astro, Hugo, Jekyll, Gatsby, 11ty, Nuxt, alle konkurrieren in diesem Space. Das Build-Tool merged Templates mit Daten, um HTML zu produzieren.
3. Seiten rendern zu HTML-Dateien. Eine HTML-Datei pro URL. /blog/post-1.html, /products/widget-x.html etc.
4. Output uploaded zu S3 / CDN. CloudFront, Cloudflare, Netlify, Vercel, das CDN serviert die vorgebauten Dateien.

Der Serve-Step (pro Request):

1. Browser requestet /blog/post-1.
2. CDN-Edge serviert post-1.html. Gecacht am nächsten Edge, 50 KB transferiert, 10-50 ms total.
3. Seite ist sofort interaktiv. Kein Warten auf Backend-Round-Trips. JavaScript hydratisiert bei Bedarf für Interaktivität.

Wann SSG die richtige Wahl ist

• Marketing-Sites und Blogs. Content-Updates sind selten (höchstens täglich). Build-once-serve-cheap passt zum Zugriffsmuster.
• Dokumentations-Sites. Stripe Docs, Tailwind Docs, Stack Overflows Dokumentation sind alle SSG. Suche kann eine separate API nutzen; die Docs selbst sind vor-gerendert.
• E-Commerce-Produktkataloge (meist). Produktseiten rendern einmal pro Build. Echtzeit-Daten (Inventar, Preise) laden via separate API-Calls. Große E-Commerce-Sites nutzen dieses Hybrid-Muster.
• SaaS-Landing-Pages. Die Marketing-Site ist SSG; die App hinter dem Login ist etwas anderes (SSR oder CSR).
• Sites, die Core Web Vitals priorisieren. SSG produziert die schnellsten LCP und TTFB möglich. CrUX-getriebenes SEO favorisiert das.

Wo SSG zu kurz kommt

• Content, der pro Nutzer wechselt. Ein eingeloggtes Dashboard mit nutzerspezifischen Daten kann nicht SSG sein (ohne dynamisches Client-Side-Fetching). Die Marketing-Seiten KÖNNEN; das Dashboard KANN NICHT.
• Echtzeit-Content (Aktienkurse, Live-Scores). SSG würde Rebuilds alle paar Sekunden erfordern. Nutze SSR oder Client-Side-WebSockets stattdessen.
• Sehr große Sites mit häufigen Updates. Eine Site mit 1 Million Seiten, von denen 10K täglich wechseln, ist als reines SSG schwer zu machen, volle Rebuilds dauern zu lange. Incremental Static Regeneration (ISR. Next.js-Begriff) adressiert das durch on-demand Page-Rebuilds innerhalb eines SLA.
• Such-Funktionalität. Statische Sites können keine serverseitige Suche laufen lassen; du brauchst entweder eine Third-Party-Such-API (Algolia, Typesense) oder Client-Side-Fuzzy-Search auf einem vorgebauten Index.
• Formulare und Mutations. SSG kann Form-Submissions nicht direkt akzeptieren. Kombiniere mit einem separaten Form-Handling-API-Endpoint oder nutze einen Service wie Formspree.

Die großen SSG-Frameworks (2026-Landschaft)

• Next.js (React). Hybrid SSG/SSR. Beliebtestes React-basiertes Framework. Vercel-nativ, aber funktioniert auch anderswo. Heavy aber Feature-vollständig.
• Astro. Component-agnostisch (React, Vue, Svelte alle in einem Projekt). Liefert standardmäßig null JavaScript, außergewöhnliche Core Web Vitals out of the box.
• Hugo (Go). Kompiliertes Binary, unglaublich schnelle Builds (1000+ Seiten pro Sekunde). Begrenzte dynamische Fähigkeiten, aber unübertroffene Build-Geschwindigkeit.
• 11ty (Eleventy, Node). Minimal, flexibel. Beliebt für einfache Sites, die kein JavaScript-Framework auf dem Client brauchen.
• Gatsby (React). Reif, plugin-reich. Weitgehend von Next.js überholt, aber noch gepflegt.
• Nuxt (Vue). Vues Antwort auf Next.js. SSG/SSR-Hybrid.
• Jekyll (Ruby). Das ursprüngliche SSG. Treibt GitHub Pages standardmäßig. Älter, aber funktioniert noch.

SSG und Core Web Vitals

SSG produziert die besten CWV-Metriken am Markt:

• LCP: Vor-gerendertes HTML + kritisches CSS inlined gibt typischerweise Sub-1.5s-LCP aus jeder Region mit CDN-Coverage.
• FCP: Sub-1s in den meisten Fällen. Das HTML kommt im ersten Paket an.
• CLS: Gleiche Einschränkungen wie jede andere Rendering-Strategie, hängt vom Markup ab, nicht vom Build-Ansatz. SSG macht CLS weder schlecht noch gut.
• INP: Wenn die Site meist statisch ist (kein heavy JavaScript), ist INP exzellent. Wenn die Site heavy Client-Side-Hydration nutzt, kann INP wie eine CSR-Site sein.
• TTFB: Beste der Klasse. CDN-gecachtes HTML serviert in Millisekunden, weit unter 200 ms auch aus entfernten Regionen.

FAQ: Static Site Generation

Was ist der Unterschied zwischen SSG und SSR?

Timing der HTML-Generierung. SSG generiert alle Seiten zur Build-Zeit; SSR generiert jede Seite pro Request auf dem Server. SSG ist schneller (keine Pro-Request-Arbeit), aber stale (Content zum Build-Zeitpunkt fixiert). SSR ist frischer (Live-Daten), aber langsamer pro Request.

Können SSG-Sites dynamisch sein?

Ja, das statische HTML kann JavaScript enthalten, das nach Page-Load dynamische Daten fetcht. Der Basis-Content ist vor-gerendert (gut für SEO) und dynamische Features (Cart-Count, Personalisierung) laden danach. Das ist das dominante Muster für modernes E-Commerce.

Was ist mit SSG mit Millionen von Seiten?

Build-Zeiten werden ein Problem. Lösungen: Incremental Static Regeneration (Next.js) baut Seiten beim ersten Request und cached; verteilte Builds über CI-Worker (Vercel, Netlify); oder akzeptieren, dass manche Seiten als SSR leben, während populäre SSG bleiben.

Ist SSG immer schneller als SSR?

Für First-Byte und gesamte Page-Load fast immer ja. Für Daten-Frische nein. SSR kann Daten zeigen, die Sekunden alt sind, SSG zeigt Daten vom letzten Build. Die richtige Antwort hängt von deinem Use Case ab.

Funktioniert SSG mit Personalisierung?

Ja, via Client-Side-Data-Loading. Das geteilte HTML ist SSG; nutzerspezifische Elemente (Name, Cart, Empfehlungen) laden via JavaScript nach Page-Load. Gleiches Muster wie Stripe-Checkout-Seiten, Notion-Docs etc.

Was ist der Catch mit SSG?

Build-Zeiten skalieren linear mit Content-Größe. Sites mit 100K+ Seiten brauchen sorgfältige Build-Strategien. Content-Updates erfordern einen Deploy (oder ISR). Und dynamische Features (Formulare, Suche, Kommentare) brauchen separate Infrastruktur.

Wie LoadFocus SSG-Performance misst

LoadFocus führt Lighthouse-basierte Speed-Tests aus 25+ Regionen aus und erfasst TTFB, LCP, INP und CLS. SSG-Sites zeigen typischerweise im obersten Dezil der CWV-Scores, aber du solltest über Regionen verifizieren, weil CDN-Coverage variiert. Lasttest mit JMeter/k6 bestätigt auch, dass dein CDN Spike-Traffic gut handhabt. SSG mit einem starken CDN ist einer der wenigen Stacks, der 10x-Traffic-Spikes graceful handhabt.