Ein statischer Generator erzeugt aus Inhaltsdateien und Vorlagen fertige HTML-Dateien. Diese werden ausgeliefert, ohne dass zur Laufzeit Code ausgeführt oder eine Datenbank befragt wird. Was beim Besucher ankommt, ist genau das, was beim Build entstanden ist.
Der Ansatz ist alt und wirkt zunächst wie ein Rückschritt. In der Praxis ist er für viele Projekte die technisch beste Lösung.
Was daraus folgt
Geschwindigkeit von Haus aus. Es gibt keine Datenbankabfrage, keine PHP-Ausführung, keinen Cache, der ungültig werden kann. Der Server liefert eine Datei aus. Gute Werte bei den Core Web Vitals sind damit der Ausgangspunkt, nicht das Ergebnis von Optimierungsarbeit.
Nahezu keine Angriffsfläche. Es läuft kein Code, es gibt keinen Anmeldebereich und keine Datenbank. Die Klasse von Angriffen, die Websites in der Praxis trifft, findet kein Ziel.
Minimaler Wartungsaufwand. Es gibt keine monatlichen Sicherheitsupdates, weil zur Laufzeit nichts existiert, das aktualisiert werden müsste. Die Abhängigkeiten des Build-Werkzeugs werden gepflegt, aber ein veralteter Build gefährdet die laufende Seite nicht.
Sehr günstiges Hosting. Statische Dateien lassen sich für 0 bis 5 Euro monatlich weltweit ausliefern.
Versionierung. Inhalte liegen in Dateien in einem Repository. Jede Änderung ist nachvollziehbar und rücknehmbar, inklusive Textänderungen.
Ausfallsicherheit beim Veröffentlichen. Schlägt ein Build fehl, bleibt die vorherige Version online.
Die Hürde
Die Redaktion. Inhalte werden in Textdateien mit Markdown gepflegt, in einem Repository verwaltet, und ein Build erzeugt daraus die Seite. Für eine technisch versierte Person ist das komfortabel. Für eine Kollegin, die einen Termin ändern soll, ist es eine Barriere.
Es gibt zwei Antworten darauf:
- Ein Headless-CMS davorsetzen. Redakteure arbeiten in einer Weboberfläche, das System löst beim Speichern einen Build aus. Das kostet ein zweites System. Siehe Headless-CMS.
- Akzeptieren, dass eine Person pflegt. Bei stabilen Inhalten ist das oft realistisch und die einfachste Lösung.
Der zweite Punkt: Es fehlt alles, was serverseitige Logik braucht. Kein Anmeldebereich, keine Suche über eine Datenbank, keine Personalisierung. Für die typischen Fälle gibt es Auswege: Formulare über einen Dienst, Suche als vorberechneter Index im Browser, Kommentare über einen externen Anbieter. Aber es sind Auswege, keine eingebauten Funktionen.
Die gängigen Werkzeuge
Astro. Erzeugt standardmäßig statisches HTML und lädt JavaScript nur dort, wo es gebraucht wird. Inhalte in Markdown mit geprüftem Schema, Vorlagen in einer HTML-nahen Syntax. Gut geeignet für inhaltsgetriebene Seiten mit einzelnen interaktiven Bereichen.
Hugo. Sehr schnelle Builds, auch bei tausenden Seiten. Vorlagensprache mit eigener Logik, die Einarbeitung verlangt. Gut bei großen Beständen.
Eleventy. Schlank und flexibel, ohne festgelegtes Frontend-Framework. Gut, wenn man volle Kontrolle über das ausgelieferte Markup will.
Next.js und ähnliche. Können statisch erzeugen, bringen aber ein Framework mit, das für eine Inhaltsseite meist mehr ist als nötig.
Für ein deutschsprachiges Inhaltsportal oder eine Firmenwebsite ist die Wahl unter den ersten drei weniger wichtig als die Frage, wer die Inhalte pflegt.
Für welche Projekte es passt
Passend:
- Firmenwebsite mit stabilen Inhalten, eine Person pflegt
- Fachportal mit vielen Beiträgen, die selten geändert werden
- Dokumentation
- Landingpages und Kampagnenseiten
- Verzeichnisse und Kataloge, die aus einer Datenquelle erzeugt werden
- Projekte mit hohem Anspruch an Ladezeit und Sicherheit
Nicht passend:
- Inhalte, die sich stündlich ändern und sofort live sein müssen
- Mitgliederbereiche und personalisierte Inhalte
- Shops mit Lagerbeständen in Echtzeit
- Redaktionsteams ohne technischen Zugang und ohne Budget für ein Headless-CMS
Der Umstieg von einem CMS
Inhalte lassen sich aus WordPress exportieren und in Markdown umwandeln. Der Aufwand liegt woanders:
- Vorlagen neu bauen. Das Design wird nicht übernommen, es wird nachgebaut.
- Adressen beibehalten, wo möglich. Jede beibehaltene Adresse ist eine, die nicht weitergeleitet werden muss.
- Weiterleitungsplan für alles, was sich ändert.
- Funktionen ersetzen: Formular über einen Dienst, Suche als Index, Kommentare gegebenenfalls streichen.
- Redaktionsweg festlegen, bevor umgestellt wird. Das ist der Punkt, an dem Projekte hängen bleiben.
Punkt 5 ist entscheidend: Ein technisch exzellenter statischer Build, in dem nach dem Weggang der aufsetzenden Person niemand mehr einen Text ändern kann, ist ein Problem und keine Lösung. Details in System wechseln.