Die Diskussion wird meist als Glaubensfrage geführt. Sie ist aber eine Rechenaufgabe: Es geht darum, an welchem Zeitpunkt der Aufwand anfällt und was man dafür aufgibt.

Wo der Aufwand landet

Ein dynamisches System erzeugt eine Seite bei jedem Aufruf: Datenbankabfragen, Vorlagen rendern, Zwischenspeicher prüfen. Ein statischer Generator erzeugt sie einmal beim Veröffentlichen. Der Besucher bekommt eine Datei, die der Webserver ohne PHP und ohne Datenbank ausliefert.

Praktisch bedeutet das eine Serverantwortzeit im niedrigen zweistelligen Millisekundenbereich statt im dreistelligen. Weil die Antwortzeit unmittelbar in den Largest Contentful Paint eingeht, verbessert sich damit auch ein Messwert, an dem sonst mühsam gefeilt wird.

Was noch dazukommt

  • Angriffsfläche. Im Auslieferungspfad läuft kein Code. Was nicht ausgeführt wird, kann auch nicht ausgenutzt werden.
  • Lastspitzen. Eine Datei zehntausendmal auszuliefern ist für einen Webserver keine Aufgabe. Dieselbe Seite zehntausendmal zu rendern schon.
  • Ausfallverhalten. Fällt die Datenbank aus, ist die Website weiterhin erreichbar. Nur der nächste Build funktioniert nicht.
  • Wartung. Ohne Paketverwaltung gibt es keine monatliche Aktualisierungspflicht für Abhängigkeiten, die man nie bewusst installiert hat.

Was es kostet

Drei Dinge, und sie sind nicht verhandelbar.

Erstens: Verzögerung. Eine Änderung ist erst nach einem Neubau sichtbar. Bei dreißig Seiten dauert das Sekunden, bei dreißigtausend Minuten. Wer stündlich veröffentlicht, muss den Ablauf automatisieren – etwa als nächtlicher Auftrag oder ausgelöst durch das Speichern im Backend.

Zweitens: keine Personalisierung. Alles, was je Besucher unterschiedlich aussehen soll, geht nicht. Warenkorb, Login-Bereich, Preise nach Kundengruppe, Live-Verfügbarkeit. Das ist keine Frage der Konfiguration, sondern der Bauart.

Dritter Punkt, der oft übersehen wird: Dateibesitz. Wenn der Build einmal als anderer Benutzer gelaufen ist als der Webserver, darf dieser die erzeugten Dateien nicht mehr überschreiben. Das fällt erst auf, wenn der Build aus dem Backend scheitert – und die Fehlermeldung zeigt dann in die falsche Richtung.

Wann statisch die falsche Wahl ist

  • Bei einem Shop mit Warenkorb und Kundenkonten
  • Bei Buchungssystemen mit Live-Verfügbarkeit
  • Bei Portalen, in denen Nutzer selbst veröffentlichen und das Ergebnis sofort sehen sollen
  • Bei sehr großen Beständen mit ständigen Einzeländerungen, wenn kein Teilbau möglich ist

Wann sie richtig ist

Bei Verzeichnissen, Lexika, Ratgebern, Regionalportalen, Unternehmenswebsites, Dokumentationen – also überall dort, wo Inhalte redaktionell entstehen und für alle gleich aussehen. Das ist der weitaus größte Teil dessen, was im Web veröffentlicht wird.

Der Zwischenweg

Formulare funktionieren auch auf statischen Websites; sie brauchen nur einen kleinen dynamischen Endpunkt. Ein Eintragungsformular, ein Kontaktformular, eine Suche im Browser gegen eine beim Bauen erzeugte Datei – all das geht, ohne die Auslieferung wieder dynamisch zu machen. Erst wenn die Ausgabe selbst je Besucher unterschiedlich sein muss, ist die Grenze erreicht.