Statische Seitengenerierung (SSG)
SSG erzeugt Webseiten zur Bauzeit als statische Dateien und optimiert dadurch Ladezeit, Sicherheit und einfache Auslieferung über CDNs.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Statische Dateien können veralten, wenn Deploy-Prozesse fehlerhaft sind
- Komplexität durch hybride Ansätze (SSG + Client-Hydration)
- Skalierende Builds können CI-Ressourcen belasten
- Inhalte versioniert in Git halten und Builds reproduzierbar machen
- Assets optimieren (Bilder, CSS-Minimierung) in der Build-Pipeline
- Cache-Invalidation und Deploy-Strategien klar definieren
I/O & Ressourcen
- Content-Quellen (Markdown, MDX, CMS-Export)
- Template-Engines und Layouts
- Build-Tools und Asset-Pipeline
- Statische HTML-, CSS- und JS-Artefakte
- Sitemap, RSS-Feeds, Asset-Manifeste
- Deploybare Bundles für CDN/Hosting
Beschreibung
Static Site Generation (SSG) ist ein Architekturparadigma, bei dem Webseiten zur Bauzeit in statische HTML-, CSS- und JavaScript-Artefakte kompiliert werden. Dadurch entstehen performante, sichere und einfach skalierbare Auslieferungswege ohne serverseitige Rendering-Logik. SSG eignet sich besonders für Content-Websites, Dokumentation und Marketingseiten mit vorhersehbarem Inhalt.
✔Vorteile
- Hohe Auslieferungsperformance durch vorgerenderte Assets
- Reduzierte Angriffsfläche ohne serverseitiges Rendering
- Einfache Skalierbarkeit und günstiges Hosting
✖Limitationen
- Eingeschränkte Unterstützung für stark personalisierte Inhalte
- Längere Build-Zeiten bei sehr großen Sites
- Erfordert zusätzliche Lösungen für dynamische Funktionen (z. B. Suche, Auth)
Trade-offs
Metriken
- Build-Zeit
Gesamtdauer eines vollständigen Builds; beeinflusst Release-Geschwindigkeit und CI-Kosten.
- Zeit bis zum ersten Byte (TTFB)
Maß für die wahrgenommene Ladeperformance beim Erstzugriff auf eine Seite.
- Cache-Hit-Rate
Anteil der Anfragen, die direkt aus dem CDN/Cache beantwortet werden.
Beispiele & Implementierungen
Hugo-Dokumentation
Dokumentation eines Open-Source-Projekts, das Hugo für schnelle, statische Seiten verwendet.
Jekyll auf GitHub Pages
Publikation persönlicher und Projektseiten mittels Jekyll und GitHub Pages als Hosting-Workflow.
Gatsby-Marketingseite
Marketing-Website, die SSG für SEO und Performance kombiniert mit Client-side Hydration für interaktive Komponenten.
Implementierungsschritte
Wahl eines geeigneten SSG-Tools (z. B. Hugo, Jekyll, Gatsby)
Aufsetzen von Templates, Layouts und lokalen Build-Prozessen
Integrieren in CI/CD, automatisierte Builds und Deploys konfigurieren
CDN- und Cache-Strategie definieren und testen
⚠️ Technische Schulden & Engpässe
Tech Debt
- Monolithische Build-Skripte ohne Modularisierung
- Hardcodierte CDN-Pfade in Templates
- Fehlende Automatisierung für Cache-Invalidation
Bekannte Engpässe
Beispiele für Missbrauch
- Einsatz von SSG für stark personalisierte Dashboard-Anwendungen
- Wegen Build-Geschwindigkeit auf manuelle Deploys setzen
- Weglassen von Cache-Invalidation nach Seitenupdates
Typische Fallen
- Nicht berücksichtigte Such-Index-Updates bei Content-Änderungen
- Fehlende Strategie für private oder geschützte Inhalte
- Unterschätzung der Build-Zeit bei wachsender Seitenanzahl
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Echtzeit-Daten erfordern zusätzliche APIs oder Funktionen
- • Skalierende Seitenanzahl erhöht Build- und Deploy-Aufwand
- • Abhängigkeit von externen Diensten für dynamische Inhalte