Statische Website-Generatoren erleben einen Aufschwung

Ich bin offensichtlich nicht der Einzige, der gerade seinen Webauftritt umstellt und von einer dynamischen Website (WordPress) auf statische Website-Generatoren umsteigt. Der Beitrag beschreibt 5 wesentliche Vorteile von statischen Webseiten gegenüber Contentmanagement-Systemen, die jede einzelne Seite neu generieren müssen. Der Beitrag schließt mit der Betonung, dass "normale" Textdateien sich ganz besonders gut für versionierte Zusammenarbeit eignen und damit auch ein wichtigen Prozess für reproduzierbare Forschung motivieren.

Structure of static website generators
Static Website Generator, by Masakuni Kato (https://www.slideshare.net/mackato/blogging-on-jekyll)

Ich bin offensichtlich nicht der Einzige, der gerade seinen Webauftritt umstellt und von einer dynamischen Website (WordPress) auf statische Website-Generatoren umsteigt. Der Beitrag beschreibt 5 wesentliche Vorteile von statischen Webseiten gegenüber Contentmanagement-Systemen, die jede einzelne Seite neu generieren müssen. Der Beitrag schließt mit der Betonung, dass "normale" Textdateien sich ganz besonders gut für versionierte Zusammenarbeit eignen und damit auch ein wichtigen Prozess für reproduzierbare Forschung motivieren.

Eine Google-Suche mit transfer blog from wordpress to jekyll ergibt ca. 360.000 Einträge. Auch wenn nicht alle Einträge genau diesen Transfer beinhalten, so ist andererseits Jekyll auch nur ein bestimmtes Produkt – wenn auch aus der großen Familie statischer Website-Generatoren (derzeit gibt es bereits 459 Produkte!) das im Augenblick im Ranking führende Software-Werkzeug.

Es gibt im Netz wörtlich hunderte von Anleitungen, Plugins, Scripts die den Migrationsprozess erleichtern sollen. Einige Beispiele: 

Die meisten Anleitungen und Hilfsmittel betreffen die Migration zu Jekyll. Ist erst dieser Export geschafft, ist es recht einfach auf einen anderen statischen Website-Generator zu wechseln.

Statische Website-Generatoren: Wieso dieser Aufschwung?

Was ist hier los? Wieso diese Flucht weg von WordPress hin zu statischen Website-Generatoren? Wir haben doch alle gedacht, dass die Zeiten, wo wir lokal mühselig HTML-Seiten vorbereiten und dann "hinauf laden" endgültig vorbei sind?

Tsatsächlich haben statische Website-Generatoren eine ganze Reihe von Vorteilen:

  1. Geringere Komplexität: Über ein hierarchisch organisiertes  System von Vorlagen (Templates) werden mit normale HTML-Seiten die komplette Struktur des Websites produziert. Das Tolle daran: Es sind – "out of the box" und wenn keine speziellen Änderungswünsche bestehen – weder HTML, CSS oder Javascript-Kenntnisse erforderlich. Geschrieben wird in einer Auszeichnungsprache (Markup Language, z.B. Markdown), die viele von uns aus der Wikipedia kennen. – Dies gesagt möchte ich nicht verheimlichen, dass zumindest rudimentäre Kenntnisse sehr hilfreich sind, z.B. wenn eine Feature über einen im Netz befindlichen Programmcode eingebaut werden soll.
  2. Höhere Geschwindigkeit: Statische Webseiten sind extrem schnell, weil der Server keine Abfragen oder Berechnungen durchführen, sondern nur die angeforderte Seite zurückgeben muss. Dynamische CMS wie WordPress hingegen alle Seiten aus verschiedenen Templates neu generieren und mit der Benutzung von Plugins kommen wird dieser Auifwand noch vervielfacht, weil eine ganze Reihe von Datenbankabfragen und Auswertungen vom Server erledigt werden müssen. Siehe z.B. den Vergleich zwischen WordPress und Hugo, den statischen Website-Generator, den ich auf meinem neuen englischen Weblog verwende.
  3. Höhere Sicherheit: Es gibt nur statische Websiten und keine Scripts auf Serverseite, die für Einbrüche genutzt werden können. Natürlich heißt das nicht, dass nichts passieren kann, aber die Gefahr für ein Sicherheitsloch ist weit geringer. WordPress ist nicht nur als führendes CMS weit verbreitet, sondern auch gut dokumentiert. Hacker können veraltete Versionen und fehlerhafte Plugin relativ leicht ausnutzen, weil nicht alle Nutzer/innen ständig die neuen (Sicherheits-)update aufspielen und/oder sich der Riskiken nicht bewusst sind.
  4. Leichtere Skalierbarkeit: Mit statischen Websites ist es einfacher die Last auf verschiedene Server zu verteilen. Es muss nur sichergestellt sein, dass der statische Website auf mehreren Servern liegt. Mit WordPress hingegen  geht das nur beschränkt, weil die zentrale Datenbank, die dann ebenfalls auf einen eigenen Server liegt, irgendwann selbst überlastet wird. Wenn aber ein verteiltes System von Datenbank notwendig wird, dann steigt die Komplexität nochmals gewaltig an.
  5. Versionskontrolle: Der für mich wichtigste Vorteil aber ist, dass es sich bei allen Dateien um normale Textdateien handelt. Abgesehen davon, dass sie leicht in ein ZIP-File gepackt und migriert werden können, ermöglichen reine Textdateien die Anwendung von Git und GitHub, einem ausgefuchsten System der Versionskontrolle, das auch das nachvollziehbare kooperative Arbeiten entscheidend erleichtert. Wer kennt nicht die multiplen Word-Versionen, die bei näherkommender Deadline kursieren und wo man/frau niemals sicher ist, in der letzten Version zu arbeiten. Gut, das lässt sich mit einer Cloud-Version leicht abstellen, bezieht sich aber vor allem auf Personengruppen, die sich kennen. GitHub hingegen ermöglicht durch das Konzept des Pull requests (sollte eigentlich wie Yihui richtig anmerkt Merge request heißen) das öffentliche (häufig nur sporadische) kooperative Arbeiten mit (bisher) Unbekannten.

Statische Website-Generatoren: Totgesagte leben länger

Diesen letzte Punkt (normale Textdateien) halte ich für ganz wesentlich für eine Zusammenarbeit. Nicht nur weil jeder Texteditor die Datei öffnen und verarbeiten kann, sondern weil durch Systeme wie GitHub Textbestände den gleichen Status wie Daten- und Code-Repositorien bekommen und damit wesentlich leichter öffentlich und gemeinschaftlich bearbeitet und weiterentwickelt werden können. Hier tut sich ein riesiges neues Gebiet – nicht nur für die Geisteswissenschaften – auf! Besondere Bedeutung hat dies für mich auch im Zusammenhang reproduzierbarer Forschung, weil damit jeder einzelne Arbeitschritt potential nachvollziebar ist und wir uns nicht mehr bloß mit der eigens für die (wissenschaftliche) Öffentlichkeit produzierte Endversion begnügen müssen.

Mein Interesse an den neuen Möglichkeiten (Methoden, Technologien, Initiativen) reproduzierberer Forschung (reproducible research) ist auch der Grund dafür, dass ich ein englisches Weblog neu begonnen habe. – Nur eigenartig: Seit ich https://notes.peter-baumgartner.net gestern mit einem einschlägigen inhaltlikchen Tweet öffentlich gemacht habe, schreibe ich wieder vermehrt deutsche Blogtexte!

Wenn ich Ihr Interesse zu statischer Websites geweckt habe, und Sie mehr dazu wissen wollen: Hier einige Links dazu: 

Von Peter Baumgartner

Seit mehr als 30 Jahren treiben mich die Themen eLearning/Blended Learning und (Hochschul)-Didaktik um. Als Universitätsprofessor hat sich dieses Interesse in 13 Bücher, knapp über 200 Artikel und 20 betreuten Dissertationen niedergeschlagen. Jetzt in der Pension beschäftige ich mich zunehmend auch mit Open Science und Data Science Education.

6 Antworten auf „Statische Website-Generatoren erleben einen Aufschwung“

Technisch gesehen macht es keinen Unterschied, ob eine dynamische Plattform mit einem CDN (content delivery network) versehen wird oder rein statisch ausgeliefert wird. Skalierbarkeit und Versionierung gibt es auch dynamisch, wenn man bspw. statt der Kommentare ohne Bearbeitungsmöglichkeit versionierte Kommentare mit Bearbeitungsmöglichkeit speichert (=echt dynamischer Inhalt, nicht nur Überschrift und Paragraphen). Einen Datenbankcluster zu skalieren und noch viele andere Beschleunigungstechniken (Caching, Sharding, …) einzusetzen ist ein administratives Problem. Einzig die Sicherheit lasse ich als Alleinstellungsmerkmal gelten, da eine HTML-Seite nun mal eine HTML-Seite ist, ganz ohne Backend und Zugangsdaten zu einer Speicherstrategie

Danke für Ihren Kommentar. Ich bin zwar technisch nicht versiert, möchte Ihnen jedoch in zwei Punkten widersprechen: Es ist eine schnellere Ausführbarkeit bei statischen Seiten gegeben, weil keine Datenbank-Abfragen und Templates interpretiert werden müssen. Außerdem führt zusätzliche Funktionalität (durch viele Plugins, die integriert werden) dazu, dass ganz „normale“ dynamische Seiten langsamer werden.

Sie haben natürlich recht, dass einige mögliche Nachteile durch geschickte Administration aufgegangen werden können. Aber das führt dann gerade wieder dazu, dass höhere Kompetenzen für einen guten und schnellen Webauftritt erforderlich sind.

Das ist aber das Zentrum meines Arguments: Während früher Content-Management-Systeme (CMS) gegenüber statische Webseiten eine Vereinfachung waren, werden jetzt – gerade weil es viele neue funktionale Erweiterungen, Zusätze etc. für dynamische Webseiten gibt, die automatisch auch zu höheren Ansprüchen führen – für bestimmte einschlägige Anwendungen, statische Webseiten wieder attraktiv, weil einfacher zu gestalten.

Das Content Delivery Network speichert die dynamische Seite einmal und liefert sie von Stund an statt der Originalseite. Der Traffic wird mithin über das CDN abgewickelt. Auf die dyn. Seite finden keine Zugriffe mehr statt. Erst nach redaktioneller oder gestalterischer Anpassung aktualisiert das CDN die quasi-statischen Abbilder.

Danke für den lesenswerten Artikel – und auch für den Mut, die klaren Vorteile herauszustellen und damit unter Umständen eine ganze Gemeinde von CMS-Freaks gegen sich zu positionieren. Auf einer meiner Spielwiesen habe ich im März 2018 eine Testseite aufgebaut, welche ohne CMS und ohne das Einbinden fremder Bibliotheken ganz wunderbar funktioniert: http://webpin.ch/hamburger/

Hallo,

in bestimmten Situationen kann eine statische Seite auf alle Fälle ausreichend sein. Bei meinen Projekten, wo ja auch oft ein Blog zum Baustein gehört, halte ich WordPress für die momentan beste Variante.

Viele Grüße

Moin, völlig unabhängig von diesem Trend bin ich selbst schon länger am überlegen ein paar Webseiten auf die guten alten HTML-Dateien umzustellen. Das was WordPress und Co inzwischen alles mitliefern und den Quellcode aufblähen macht das ein oder andere Projekt für mich echt unübersichtlich.
Jetzt fühle ich mich gerade etwas bestärkt mich mit den verschiedenen technischen Möglichkeiten dazu auseinander zu setzen.
Ich nutze das jetzt mal als Anstoß und werde versuchen ein Worpress Projekt doch nicht in WordPress zu lösen, sondern statisch anzulegen.
Viele Grüße, Michael

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert