Alternative zum klassischen CMS
Static Site Generators

In einer hoch dynamischen und agilen Welt klingt „static“ erstmal ein wenig fehl am Platz. Die meisten Webseiten sind so heut auch sehr dynamisch, werden also on-the-fly erzeugt. Das erlaubt ein individuelles Nuztererlebnis. Aber natürlich werden im Hintergrund auch die entsprechenden Ressourcen benötigt, welche die Seiten berechnen. Nehmen wir WordPress als Beispiel:

  1. Die Daten werden in einer DB abgelegt
  2. GUI Elemente liegen separat, PHP, CSS und JavaScript Files in Dateisystem
  3. Es wird neben einem Webserver eine PHP Engine benötigt
  4. Wir Content angefordert, dann wird
    1. Die PHP Runtime bemüht
    2. Content aus der DB geladen
    3. Die Seite kompiliert
    4. Das Ergebniss aus Response gesendet.

Das führt zu der Überlegung, ob das denn in der Form immer nötig ist. Denn jeder Request erfordert Rechenkapazitäten, und das, obwohl vermutlich der Content jedes Mal gleich ist. Viel besser wäre es doch, wenn der Content einmalig gerendert, und dann als statische Ressource zur Verfügung gestellt wird.


Back to static, oder was

Genau für diesen Zweck gibt es sogenannte SSGs – Static Site Generators. Der gesamte Content wird vorkompiliert und auf Anfrage bereitgestellt. Es ist als weder eine PHP Runtime (im Beispiel WordPress) oder Datenbank nötig. Nebenbei elimiert diese Tatsache gewisse Security Risiken, die zusätzliche Komplexität mit sich bringen – es gibt keine PHP Runtime , um deren Sicherheitslücken man sich Sorgen muss.

Die Idee ist nicht neu, so gibt es eine ganze Heerschar von SSG, eine Übersicht findet man bei

https://www.staticgen.com/

https://staticsitegenerators.net/

Natürlich muss man sich genau überlegen, ob für seinen Einsatzzweck wirklich SSGs in Frage kommen. Interessante Gedanken finden man hier:

https://www.sitepoint.com/7-reasons-not-use-static-site-generator/

Auch wenn man den administrativen Teil durchaus mit anderen offline Technologien in den Griff bekommen kann, und die Seitenkomplexität und Konsistenz damit ebenso: Wenn das Web-Projekt dynamic erfordert, dann ist das einfach ein Killerargument. So wird man mit SSGs keine Online Banking Portal, kein Facebook und kein Google realisieren können. Also im Prinzip alles, was Interaktion mit dem User bieten will. Hier können SSGs höchstens in Teilbereichen als Technologie eingesetzt werden.

Ein SSG der mir bei den ersten Recherchen als vielversprechend aufgefallen ist :
Hugo – https://www.gohugo.io/
Eine relative junge Lösung, Open Source und eine große Community.


Résumé

Man kann mit einem SSG Ansatz sicherlich die Performance steigern, aber das sollte wohl überlegt sein. Die Liste der Nachteile muss gegen die Vorteile abgewogen werden. Ich würde auf mein WordPress jedenfalls noch ungern verzichten wollen, hier würde sich der Performance und Sicherheitsgewinn nicht lohnen gegenüber dem Aufwand den ich in Administration stecken müssten.
Ein valider Anwendungsfall wären natürlich Online-Webseite-Portale, die Design und Hosting aus einer Hand online anbieten. Dies wäre also ein Fall von Technologischem Teilbereich.

Aber auch sonst steckt potenzial in den Konzepten. So könnte ein Cloud Service sozusagen SSG Frontends anbieten, die dann analog zu heutigen CMSen dem Content Provider die nötigen Redaktionstools bereitstellen. Die Erzeugung kann dann „nach“ beliebige Orte erfolgen – so auch in den eigenen Webspace.


beach, wave and footsteps at sunset time