Die meisten auf Content fokussierten Websites werden auf Basis eines Content Management Systems (CMS) implementiert. Oft mit Wordpress, manchmal auch mit Drupal oder TYPO3, selten auch mal mit Schwergewichten wie Adobe Experience Manager oder Sitecore.
Gemeinsam haben diese CMS, dass die Website jeweils dynamisch aus Daten und Templates beim Abruf zusammengebaut wird. Bestenfalls liegt noch ein kurzzeitiger Cache dazwischen.
Dieses Pattern hat sich bewährt und bringt einen großen Vorteil: Es kapselt die Technik einer Website weg. Statt zu programmieren, können wir, nun ja, Content managen. Mit Hilfe eines CMS kann ich Inhalte komfortabel und flexibel ergänzen und aktualisieren.
Dafür muss ich aber an einigen Stellen zusätzlichen Aufwand in Kauf nehmen:
Die Technik muss generisch mit allen denkbaren Inhalten zurechtkommen. Das Layout der Seite ist nicht für eine bestimmte Überschriftenlänge passend, sondern für alle Überschriften, die sich ein Content Manager in der Zukunft ausdenken könnte.
Die Server, die die Website ausliefern, müssen performant genug sein, um ständig die abgerufenen Seiten dynamisch nach aktuellem Stand des Contents neu zu generieren. Komplexität und Anforderungen für den Server steigen.
Und nicht zuletzt muss dieses komplexere Setup auch noch sicher sein und bleiben. Je mehr Logik ein System enthält, desto mehr kann auch schief gehen. In jedem verbreiteten CMS werden irgendwann Sicherheitslücken gefunden – und meist auch behoben. Ich muss meinen Server aktuell halten.
Content Manager sollen Inhalte komfortabel und flexibel ändern können.
Oft stellt sich heraus, dass diese Anforderung an eine Website überhaupt nicht stimmt.
Je seltener eine Website aktualisiert wird, desto weniger sind die „Content Manager“ mit dem CMS vertraut. Egal, ob Freelancer oder Agentur: Oft rufen Kund_innen einfach an, wenn sie eine Änderung an ihrer Website haben wollen, oder schreiben eine E-Mail. Das ist auch total OK, denn dafür haben sie ja ihre Agentur.
Nur: Dann können wir auch die ganze komfortable Oberfläche eines CMS in Frage stellen, wenn am Ende doch Expert_innen die Inhalte pflegen.
Bei einem Static Site Generator werden ebenfalls Inhalte in einem generischen Template als Seiten ausgegeben. Aber dieser Prozess passiert nur zum Zeitpunkt der Aktualisierung auf einem Computer, der kein öffentlicher Server ist. Am Ende hat er eine Reihe statischer HTML-Seiten erzeugt, die die komplette Website darstellen.
Diese statischen Seiten lassen sich viel leichter sicher und performant veröffentlichen als eine CMS-Applikation.
Wenn eine Website voraussichtlich nicht mehr aktualisiert werden soll und eventuell nur für eine kurze Lebensdauer vorgesehen ist, lohnt sich der Aufwand für ein generisches Template nicht. Dann kann ich die statische Seite auch manuell zusammenbauen.
Wenn die Seite häufig aktualisiert wird (und die Content Manager daher entsprechend vertraut mit dem CMS sind), lohnt sich ein CMS.
In vielen anderen Fällen macht ein Static Site Generator Sinn.
Lektor ist ein Static Site Generator. Es gibt davon hunderte, https://www.staticgen.com hat eine filterbare Liste. Meine Gründe, für dieses Blog auf Lektor zu setzen sind: