Was ist Static Site Generation (SSG)?

Was ist Static Site Generation (SSG)?

Static Site Generation (SSG) ist ein Rendering-Ansatz, bei dem ein Build-Schritt Ihre Inhalte und Templates vorab in reine HTML-Dateien verwandelt. Diese Dateien liegen auf einem Host oder CDN und werden unverändert ausgeliefert, sodass beim Seitenaufruf weder Code noch eine Datenbankabfrage läuft. SSG ist eine von mehreren Web-Rendering-Strategien.

So funktioniert SSG

1. Inhalte liegen in Quelldateien oder einem CMS. Markdown, JSON, YAML oder die API eines Headless-CMS.
2. Ein Build-Tool kombiniert Inhalte, Templates und Daten. Es schreibt pro URL eine HTML-Datei, dazu CSS, JavaScript und Bilder.
3. Das Ergebnis wird veröffentlicht. Die Dateien landen in Objektspeicher oder auf einem statischen Host, meist hinter einem CDN.
4. Jede Anfrage ist ein Dateizugriff. Der Edge liefert die fertige Datei, die Time to First Byte hängt daher vor allem an der Netzwerkdistanz.

Frameworks wie Astro, Hugo, Eleventy, Jekyll, Next.js und Nuxt können statisch ausgeben. Astro rendert Komponenten laut Islands-Dokumentation zu HTML und CSS und liefert JavaScript nur für die Teile, die Sie als interaktiv markieren. In Next.js schreibt next build mit output: 'export' einen statischen Ordner aus HTML, CSS und JavaScript.

Wann SSG die richtige Wahl ist

• Marketingseiten, Blogs und Dokumentation: Inhalte ändern sich nach Redaktionsplan, nicht pro Besucher.
• Landingpages, die schnell sein müssen: Vorgebautes HTML vom CDN ist der kürzeste Weg zum ersten Byte.
• Katalog- oder Listenseiten mit clientseitigem Preis- oder Bestandsaufruf: Die Hülle ist statisch, eine kleine API-Anfrage liefert die Live-Daten.
• Websites mit günstigem, einfachem Hosting: Ein statischer Host hat keinen Anwendungsserver, den man patchen oder skalieren müsste.

Wo SSG an Grenzen stößt

• Nutzerspezifische Inhalte. Ein Dashboard nach dem Login lässt sich nicht für jeden Nutzer vorbauen. Nutzen Sie Server-Side Rendering oder laden Sie Daten im Browser.
• Live-Daten. Spielstände oder Lagerbestände, die sich alle paar Sekunden ändern, brauchen SSR oder eine clientseitige Anfrage.
• Sehr große, sich schnell ändernde Websites. Tausende Seiten bei jeder Änderung neu zu bauen wird langsam. Incremental Static Regeneration baut nur geänderte Seiten neu.
• Serverfunktionen. Der statische Export hat keine Logik zur Anfragezeit. Next.js führt Cookies, Redirects, Rewrites, Header, Server Actions und ISR bei output: 'export' als nicht unterstützt auf, das erledigen Sie also am Host oder CDN.

Beispiel: eine Dokumentationsseite

Eine Doku hat 400 Markdown-Seiten. Der Build wandelt sie in 400 HTML-Dateien um, ein CI-Job lädt sie in den Speicher hoch, und das CDN cacht sie weltweit. Korrigiert eine Redakteurin einen Tippfehler, baut und veröffentlicht die Pipeline neu und leert den CDN-Cache für die geänderten Pfade. Die Suche läuft über einen vorgebauten Index im Browser oder eine gehostete Such-API.

Häufige Fehler

• Den CDN-Cache nach dem Deployment nicht zu leeren, sodass Besucher weiter die alte Seite sehen.
• Beim Build eine langsame Drittanbieter-API ohne Timeout aufzurufen, sodass ein einziger Ausfall den ganzen Build scheitern lässt.
• Statisch für automatisch sicher zu halten: Hosting, Formulare und alle APIs brauchen weiterhin Schutz.
• Große Client-Bundles auf einer statischen Seite zu laden und den Geschwindigkeitsvorteil zu verspielen.
• Daten fest einzubauen, die zur Anfragezeit geladen werden sollten, etwa Preise.

SSG, Performance-Tests und Monitoring

Statische Seiten nehmen dem Backend die meiste Variabilität. Beobachten Sie daher CDN-Cache-Trefferquote, Time to First Byte aus verschiedenen Regionen und die Größe der ausgelieferten Dateien. Verfolgen Sie Seitengeschwindigkeit und Core Web Vitals nach jedem Deployment mit LoadFocus Page Speed Monitoring, das geplante Lighthouse-Audits aus 25 Cloud-Regionen ausführt. Der Beitrag Tipps für mehr Seitengeschwindigkeit (auf Englisch) behandelt die Frontend-Arbeit, die auch bei einer statischen Seite zählt.

Ruft eine statische Seite APIs für Suche, Formulare oder Live-Daten auf, zeigt sich die Last an diesen Endpunkten. Fahren Sie vor einem Traffic-Peak einen Lasttest dagegen.

Häufige Fragen: Static Site Generation

Was ist der Unterschied zwischen SSG und SSR?

Der Zeitpunkt. SSG erzeugt das HTML einmal, bevor ein Besucher kommt. SSR erzeugt es bei jeder Anfrage auf dem Server. SSG ist günstiger und schneller auszuliefern, SSR kann anfrageabhängige oder Live-Daten zeigen.

Ist eine statische Website eine Website ohne JavaScript?

Nein. Eine statische Website kann im Browser trotzdem JavaScript für Menüs, Suche oder Widgets ausführen. Statisch heißt, dass das HTML vorab gebaut ist, nicht dass die Seite nicht interaktiv wäre.

Ist SSG gut für SEO?

Ja. Crawler erhalten sofort vollständiges HTML, und schnelle Seiten helfen bei den Core Web Vitals. Ein Ranking garantiert SSG allein aber nicht: Inhaltsqualität und Links entscheiden weiterhin.

Wie aktualisiere ich Inhalte auf einer statischen Website?

Quelle ändern, Build starten, neue Dateien ausliefern. Die meisten Hoster und CI-Systeme erledigen das automatisch bei jedem Commit oder wenn Ihr CMS veröffentlicht. Bei sehr großen Websites baut die inkrementelle Regeneration nur das Geänderte neu.

Kann eine statische Website Formulare, Suche oder Logins haben?

Ja, indem der Browser APIs aufruft oder gehostete Dienste für Formulare und Suche genutzt werden. Die Seite bleibt statisch, der dynamische Teil läuft woanders.