Statisch oder dynamisch: was die Entscheidung wirklich kostet

Die Frage, ob eine Website statisch oder dynamisch ausgeliefert werden soll, wird gern als Glaubensfrage geführt. Sie lässt sich nüchterner beantworten: Es geht darum, zu welchem Zeitpunkt der Rechenaufwand anfällt und was du dafür aufgibst. Beides lässt sich für ein konkretes Projekt ziemlich genau abschätzen.

Wo der Aufwand landet

Ein dynamisches System erzeugt eine Seite bei jedem Aufruf: Datenbank abfragen, Vorlage füllen, Zwischenspeicher prüfen. Ein statischer Generator erzeugt sie einmal beim Veröffentlichen. Der Besucher bekommt danach eine fertige HTML-Datei, die der Webserver ohne PHP und ohne Datenbank ausliefert. Den Begriff erklärt das Lexikon unter Static Site Generator.

Spürbar wird das an der Zeit bis zum ersten Byte, kurz TTFB. web.dev nennt 0,8 Sekunden oder weniger als gute Richtgröße und mehr als 1,8 Sekunden als schlecht ^[1]. TTFB ist selbst kein Core-Web-Vitals-Wert, liegt aber vor allen Werten, die Nutzer wahrnehmen. Ein langsamer Server verzögert deshalb First Contentful Paint und Largest Contentful Paint gleichermaßen ^[1]. Beim Largest Contentful Paint ist die TTFB der erste von vier Teilabschnitten ^[2]. Serverseitiges Rendern kann die TTFB laut web.dev verlängern, weil es zusätzliche Rechenzeit auf dem Server braucht, und Vorrendern ist für die Leistung in der Regel die bessere Wahl ^[2]. Wie sich das auf die Core Web Vitals auswirkt, behandelt der Beitrag Core Web Vitals bei statischer Auslieferung genauer.

Was noch dazukommt

• Angriffsfläche: Im Auslieferungspfad läuft kein Programmcode. Was nicht ausgeführt wird, lässt sich auch nicht über eine Lücke im Code ausnutzen.
• Lastspitzen: Eine Datei zehntausendmal auszuliefern, kostet einen Webserver wenig. Dieselbe Seite zehntausendmal zu erzeugen, kostet deutlich mehr.
• Ausfälle: Fällt die Datenbank aus, bleibt die Website erreichbar. Nur der nächste Bauvorgang scheitert.

Die Verwaltung bleibt natürlich dynamisch. Sie ist aber nur für die Redaktion erreichbar und lässt sich getrennt absichern.

Was es kostet

Drei Dinge gibst du auf, und sie lassen sich nicht wegkonfigurieren.

Erstens die Verzögerung: Eine Änderung ist erst nach einem Neubau sichtbar. Bei wenigen Seiten dauert das nach unserer Erfahrung Sekunden, bei Zehntausenden länger. Wer häufig veröffentlicht, automatisiert den Ablauf, etwa als nächtlichen Auftrag oder ausgelöst durch das Speichern in der Verwaltung.

Zweitens die Personalisierung: Alles, was für jeden Besucher anders aussehen soll, fällt weg. Warenkorb, Kundenkonto, Preise nach Kundengruppe oder eine Live-Verfügbarkeit lassen sich nicht vorab als Datei erzeugen. Das ist eine Folge der Bauart.

Drittens die Dateirechte, die oft übersehen werden. Läuft der Build einmal unter einem anderen Systembenutzer als der Webserver, darf dieser die erzeugten Dateien danach nicht mehr überschreiben. Auffällig wird das erst, wenn der Build aus der Verwaltung heraus scheitert, und die Fehlermeldung zeigt dann oft in eine falsche Richtung. Ähnlich verhalten sich Sperrdateien. Im SEO CMS verhindert eine Sperre, dass zwei Bauvorgänge gleichzeitig in dasselbe Verzeichnis schreiben. Weil sich mehrere Installationen auf einem Server das temporäre Verzeichnis teilen, fand ein Build früher die Sperrdatei eines anderen Systembenutzers und brach ab. Inzwischen trägt die Sperrdatei einen eigenen Namen je Installation.

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 sich nicht nur Teile neu bauen lassen.

Wann statisch passt

Verzeichnisse, Lexika, Ratgeber, Regionalportale, Unternehmenswebsites und Dokumentationen haben eines gemeinsam: Die Inhalte entstehen redaktionell und sehen für alle Besucher gleich aus. Für solche Projekte ist statische Auslieferung nach unserer Erfahrung die einfachere Wahl, weil sie im Betrieb weniger bewegliche Teile hat. Das SEO CMS ist für genau diesen Fall gebaut. Wie Build und Auslieferung dort zusammenspielen, beschreibt die Funktionsseite Statischer Build und Auslieferung.

Vier Fragen für die eigene Rechnung

Für ein konkretes Projekt reichen meist vier Fragen. Wie viele Seiten hat die Website, und wie lange dauert ein vollständiger Bauvorgang damit? Wie oft ändert sich etwas, und muss die Änderung sofort sichtbar sein oder reicht der nächste Lauf? Gibt es Bereiche, die je Besucher anders aussehen, und lassen sie sich auf eine eigene Anwendung auslagern? Und welche Eingaben nimmt die Website an, vom Kontaktformular bis zum Eintrag im Verzeichnis? Wer die erste und dritte Frage ehrlich beantwortet, hat die Entscheidung meist schon getroffen. Die übrigen zwei bestimmen, wie viel Automatik der Build braucht.

Der Zwischenweg

Formulare funktionieren auch auf statischen Websites. Sie brauchen nur einen kleinen dynamischen Endpunkt, der die Eingabe annimmt. Ein Eintragungsformular, ein Kontaktformular oder eine Suche, die im Browser gegen eine beim Bauen erzeugte Datei läuft, ändern nichts daran, dass die Seiten selbst als Dateien ausgeliefert werden. Wie das ohne JavaScript geht, zeigt der Beitrag Formulare ohne JavaScript. Die Grenze ist erreicht, wenn die Ausgabe selbst für jeden Besucher anders sein muss.

Wer zwischen beiden Welten schwankt, findet im Glossar unter Server-Side Rendering die dritte Bauart, bei der der Server jede Seite beim Aufruf fertig erzeugt.

Du überlegst, ob sich dein Projekt für statische Auslieferung eignet, und willst die Nachteile vorher durchgehen? Bring Seitenzahl und Formulare deines Projekts in die gratis Sprechstunde mit, dann sprechen wir darüber.

1. Organisation Time to First Byte (TTFB). web.dev, Google. Stand 18.11.2025. abgerufen am 31.10.2026
2. Organisation Optimize Largest Contentful Paint. web.dev, Google. Stand 31.03.2025. abgerufen am 31.10.2026

Zuletzt geprüft am 03.11.2026, nächste Prüfung spätestens im November 2027. Fehler entdeckt? Schreib uns.