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.