Statische Website oder Content-Management-System.

Eine statische Website erzeugt ihre Seiten vorab und liefert sie als Dateien aus; ein Content-Management-System erzeugt die Seiten zur Anfragezeit aus der Datenbank.

Diese Entscheidung sieht nicht wie eine Performance-Entscheidung aus, ist aber deren größter einzelner Bestimmungsfaktor. Zeit bis zum ersten Byte, Skalierungsverhalten, Sicherheitsfläche und Wartungskosten — alle vier leiten sich aus dieser Wahl ab. Und die Entscheidung fällt am Projektanfang und wird selten zurückgenommen.

Die Debatte läuft meist auf der falschen Achse: Geschwindigkeit gegen Bequemlichkeit. Die echte Achse ist eine andere — wie oft sich der Inhalt ändert und wer ihn ändert.

Der technische Unterschied

Ein Content-Management-System wiederholt bei jeder Anfrage dieselbe Arbeit: Es fragt die Datenbank ab, verarbeitet das Template, erzeugt das HTML, sendet es. Eine statische Website tut diese Arbeit einmal — im Moment der Veröffentlichung — und sendet danach nur Dateien.

Der Unterschied zeigt sich direkt in der Zeit bis zum ersten Byte. Eine Datei zu senden ist um eine Größenordnung billiger als Datenbankabfrage plus Template-Verarbeitung. Die Live-Messung dieser Website: 0,302 Sekunden, und auf den drei betreuten Projekten liegt der Wert unter 300 Millisekunden.

Der zweite Unterschied liegt in der Skalierung: Statische Dateien lassen sich auf Edge-Servern unbegrenzt cachen, denn sie sind für jeden Nutzer gleich. Verzehnfacht sich der Verkehr, gibt es keine Anwendungsschicht, die skalieren müsste.

Der dritte ist die Sicherheit: Wo kein Code läuft, gibt es keine Lücke. Datenbankinjektion, Plugin-Schwachstellen und Angriffe aufs Admin-Panel — alle drei sind auf einer statischen Website undefiniert.

Die echte Abwägung

Der Preis des statischen Ansatzes liegt in der Bequemlichkeit, und der Preis ist real. Ändert sich der Inhalt, braucht es einen Neubau; für nicht-technische Redakteure kann das ein Hindernis sein. Und wirklich dynamischer Inhalt — sitzungsbasierte Personalisierung, Live-Bestand, Nutzerkommentare — kann nicht statisch sein.

1. Statisch passt — Präsentationsseite, Dokumentation, Blog, Vitrine, Kampagnenseite. Der Inhalt ändert sich selten und ist für alle gleich.
2. Statisch passt nicht — Nutzerkonten, Warenkorb, Live-Preise, personalisierte Inhalte.
3. Hybrid ist möglich — die meisten Seiten statisch, nur die sich ändernden Teile im Client oder in Edge-Funktionen.
4. Das Redakteursproblem ist lösbar — eine an den Build-Prozess gebundene Oberfläche kann dem Redakteur das klassische Panel-Erlebnis geben.
5. Das Entscheidungskriterium — wie oft ändert sich der Inhalt, und wer ändert ihn?

Der dritte Punkt ist heute die häufigste Lösung: der Seitenkörper statisch, nur die wirklich dynamischen kleinen Teile gesondert behandelt. Genau so ist es auf dieser Website — achtundfünfzig Seiten liegen als Dateien, und das einzige zur Anfragezeit laufende Stück Code ist der serverseitige Vermittler des Kontaktformulars.

Die Wartungsseite

Der auf lange Sicht am meisten übersehene Unterschied sind die Wartungskosten. Ein Content-Management-System ist ein ständig zu aktualisierender Software-Stapel: Kern, Plugins, Themes, Datenbank und Laufzeitumgebung. Jedes ist ein eigenes Update und ein eigenes Bruchrisiko.

Auf einer statischen Website geht nur eines in Produktion: Dateien. Selbst wenn das Build-Werkzeug nie aktualisiert wird, läuft die Live-Website weiter — denn es läuft nichts. Für Präsentationsseiten, die drei bis fünf Jahre stehen müssen, ist das ein deutlicher Vorteil.

Der Preis: Die Produktionskette selbst ist eine Abhängigkeit, und bricht diese Kette, lässt sich kein neuer Inhalt veröffentlichen. Die Kette einfach und abhängigkeitsarm zu halten verkleinert dieses Risiko.

Wo kein Code läuft, stürzt kein Code ab — aber bricht der erzeugende Code, erscheint auch kein neuer Inhalt.

Migration: eine bestehende Website umziehen

Ein bestehendes Content-Management-System auf eine statische Architektur umzuziehen ist eine häufigere Entscheidung als gedacht, und meist geht es schrittweise. Statt der Vollmigration liefert das Statifizieren eines Teils der Seiten in den meisten Fällen den Großteil des Nutzens.

1. Den Inhalt exportieren — die Daten des bestehenden Systems werden in eine strukturierte Form übersetzt.
2. Die URL-Struktur bewahren — ändern sich die Adressen, geht die angesammelte Suchsichtbarkeit verloren; ist die Änderung unvermeidlich, werden Weiterleitungen eingerichtet.
3. Mit den verkehrsstärksten Seiten beginnen — der Gewinn kommt von dort.
4. Die dynamischen Teile herauslösen — Formular, Suche, Kommentare. Sie werden gesondert behandelt.
5. Den Redaktionsfluss lösen — eine nicht-technische Person muss Inhalte ändern können.
6. Die Messung zuerst einrichten — um zu zeigen, dass die Migration gewirkt hat, muss das Vorher gemessen sein.

Der letzte Punkt wird am meisten übersprungen und erzeugt die meiste Reue: Um nach der Migration die Frage „wurde es schneller“ zu beantworten, muss das Vorher gemessen sein. Eine nachträglich eingerichtete Messung kann diesen Vergleich nie leisten.

Der zweite Punkt ist die riskanteste Seite der Migration. Ändert sich die Adressstruktur, können angesammelte Indexierung und Linkwert verloren gehen; selbst mit Weiterleitungen bleibt ein Verlust. Die Adressen bewahren zu können ist die wertvollste Entwurfsbeschränkung der Migration.

Eine praktische Checkliste

Übersetzt man diese Seite in einen Prüfschritt, ist für die Architekturentscheidung Folgendes zu prüfen. Die Liste bleibt kurz, denn lange Listen werden nicht abgeschritten; sechs Punkte passen in eine Sitzung.

1. Wie oft ändert sich der Inhalt — täglich oder monatlich?
2. Wer ändert ihn — jemand Technisches oder ein Redakteur?
3. Gibt es wirklich personalisierte Inhalte?
4. Schwankt der Verkehr — ist Skalierung ein Thema?
5. Wie groß ist die Wartungskapazität — wer trägt die Update-Last?
6. Wie breit darf die Sicherheitsfläche sein?

Die ersten zwei Punkte geben den Großteil der Entscheidung. Inhalt, der einige Male im Monat von jemandem Nicht-Technischem geändert wird, passt zur Hybridlösung; Inhalt, der viele Male am Tag von vielen geändert wird, besser zum klassischen System.

Eine Warnung zum Schluss: Diese Entscheidung ist keine Ideologiefrage. Verfechter des statischen Ansatzes präsentieren ihn manchmal als für jede Lage passend, und das schadet der entscheidenden Person. Ein wirklich dynamisches System statifizieren zu wollen bringt weder Performance noch leichtere Wartung — nur zusätzliche Komplexität.

Die richtige Frage ist nicht „welches ist besser“, sondern „wozu passt mein Inhalt“. Die Antwort kommt aus der Änderungsfrequenz des Inhalts und aus der Person, die ihn ändert — nicht aus einer Technologievorliebe. Auf dieser Website lautete die Antwort statisch, weil der Inhalt sich selten ändert und die ändernde Person technisch ist — in einem anderen Projekt kann dieselbe Frage anders beantwortet werden, und das ist auch richtig so.