Renaissance der statischen Websites

Viele Webauftritte (u.a. auch verschiedene Blogs) verwenden aktuell (wieder) statische HTML-Seiten anstelle von Content Management Systemen (CMS) und setzen damit auf eine Technik aus den Anfangstagen des World Wide Web.

Im folgenden Artikel werde ich beschreiben welche Gründe heute (wieder) für statische Websites sprechen und mit welchen Werkzeugen man diese sehr einfach erzeugen kann.

Doch zunächst ein kleiner Ausflug in die Historie der Webentwicklung.

Anfangszeit des WWW

In der Anfangszeit des WWW Anfang der neunziger Jahre des vergangenen Jahrhunderts waren Webseiten statisch, d.h. man benutzte auf dem PC einen Editor um die einzelnen HTML-Dateien eines Webauftritts zu erstellen. Bei großen Websites mit vielen Seiten konnte das schon mal recht aufwändig wären. Daher gab es auch schon damals Tools, mit deren Hilfe die Seiten zumindest teilweise automatisch erzeugt wurden konnten.

Content Management Systeme

Um die Jahrtausendwende entstanden dann die ersten Content Management Systeme wie z.B. TYPO3, Joomla!, Drupal oder WordPress. Die CMS sind meistens in der Skriptsprache PHP implementiert. Einige auch in Ruby oder Perl.

Allen gemeinsam ist ihre Arbeitsweise: Inhalte und Darstellung werden voneinander getrennt gespeichert. Für die Speicherung der Inhalte wird im Regelfall eine Datenbank (z.B. MySQL) verwendet. Dabei können die Texte meistens Online in einem Texteditor (z.T. mit WYSIWYG-Möglichkeit) erfasst werden.

Für die Aufbereitung verwenden alle CMS eigene Template-Mechanismen. Die Templates sind i.d.R. eine Kombination aus HTML-Quellcode mit speziellen Platzhaltern bzw. direkten PHP-Aufrufen. Die einzelnen Template-Dateien werden zu sogenannten Themes zusammengefasst. Jedes CMS kommt mit einer mittlerweile großen Zahl an vorgefertigten Theme und es gibt eigene Marketplaces mit kostenlosen und kostenpflichtigen Themes.

Wird im Webbrowser des Besuchers eine Seite aufgerufen, führt der Webserver (vereinfacht gesagt) eine PHP-Funktion aus, die die Texte aus der Datenbank liest und diese dann mit den jeweiligen Templates kombiniert um eine HTML-Seite zu erzeugen, die dann an den Browser übermittelt wird. Je nach Komplexität der Templates und auch Auslastung des Servers kann es hierbei durchaus zu Performance-Problemen kommen. Daher gibt es für die diversen CMS auch die verschiedensten Caching-Lösungen um dies in den Griff zu bekommen (mit mehr oder weniger großem Erfolg).

Static Site Generators

Ende der 2010er Jahre begann mit der Veröffentlichung von Jekyll ein Trend weg von dynamisch erzeugten Websites und wieder zurück zu statischen Websites.

In der Folge entstanden eine ganze Reihe von Generatoren von Webseiten, sogenannte Static Site Generators (kurz “SSG”). Ähnlich wie CMS verwenden SSGs auch Templates (die durchaus ähnlich wie bei den CMS strukturiert sind), allerdings werden die Texte einfach als Textdateien gespeichert. Dabei wird im Regelfall aber nicht direkt HTML, sondern eine Auszeichnungssprache wie Markdown (seltener auch Textile oder ASCIIDoc) verwendet.

Bei Änderungen an den Texten oder Templates wird dann durch Aufruf des Generators der Webauftritt neu generiert. Die erzeugten Dateien (HTML-, CSS-, JavaScript-Dateien) müssen dann noch in ein entsprechendes Verzeichnis des Webservers kopiert werden, damit sie ausgeliefert werden können. Die Webserver (Apache, NGINX, etc.) benötigen dann keine zusätzliche Software wie eine MySQL-Datenbank oder PHP mehr.

Waren die ersten SSGs wie Jekyll und das darauf basierende Octopress eher Werkzeuge für Softwareentwickler und gerade unter Microsoft Windows nicht so einfach ans Laufen zu bekommen, so gibt es mittlerweile eine Reihe von SSGs, die sich wesentlich einfacher einrichten und verwenden lassen. Das erklärt auch warum es immer mehr Webauftritte gibt, die auf diese Art entstehen.

Vorteile der statischen Generatoren

Geschwindigkeit

Die Geschwindigkeit, mit der die Seiten ausgeliefert und im Browser angezeigt werden, ist sicherlich einer der größten Vorteile der SSGs. Auf dem Server sind keinerlei Datenbankzugriffe oder die Ausführung von (PHP)-Script nötig und das führt zu einer messbar deutlich besseren Antwortzeit der Server (und damit zu einem besseren Ranking in den Suchmaschinen).

Sicherheit

Jedes CMS hat mehr oder weniger große Sicherheitslücken. Diese befinden sich einmal in der Implementierung des CMS selbst, aber auch in den diversen installierten Plugins ohne die kein CMS auskommt.

Ich weiß schon gar nicht mehr wie häufig versucht wurde, meine (noch auf WordPress basierende) Website zu hacken. Als Betreiber eines Servers geht so viel Zeit für die Absicherung des Systems und das Einspielen neuer Updates drauf.

Bei einem SSG gibt es diese Probleme nicht. Der Code wird auf dem PC generiert und angreifbar wäre höchstens die Webserver-Software selbst. Mir ist allerdings aktuell keine ausgenutzte Sicherheitslücke in Apache oder NGINX bekannt.

Daher war das auch für mich der Hauptgrund für den Umstieg.

Einfacher Server ist ausreichend

Für ein CMS benötigt man auf dem Webserver neben der Server-Software noch mindestens PHP und eine MySQL-Datenbank.

Bei Verwendung eines SSGs reicht die Server-Software. Wenn man seine Webseite extern hostet (das dürfte der Regelfall sein) reicht damit häufig ein günstiger Tarif aus.

Beliebiger Texteditor

Die Texte können mit einem beliebigen Texteditor geschrieben werden. Hilfreich ist es, wenn der Editor eine Vorschau für die verwendete Auszeichnungssprache besitzt. Aber im Prinzip reicht unter Windows schon Notepad aus.

Ich habe diesen Text z.B. in Atom geschrieben.

Einfacher Backup und Versionierung

Da sowohl die Templates als auch die eigentlichen Inhalte (Texte, Fotos) in Dateiform vorliegen ist ein Backup sehr einfach möglich.

Auch eine Versionierung insbesondere der Inhalte ist mit Hilfe eines beliebigen Versionsverwaltungssystems (git, Subversion) möglich.

Nachteile

Fehlende integrierte Suchfunktion

Die meistens CMS enthalten eine eingebaute Suchfunktion, die die in der Datenbank gespeicherten Inhalte durchsucht. Das fehlt bei einer statischen Website und für eine Suchfunktion muss auf einen externen Dienst wie Google Custom Search oder Swifttype zurückgegriffen werden.

Keine integrierte Kommentarfunktion

Für die Kommentarfunktion (auch für ein Kontaktformular) gilt dasselbe und es bleiben auch nur externe Lösungen wie Disqus, Facebook Comments oder IntenseDebate.

Produkte (Auswahl)

Bevor ich meine Seite von WordPress auf Hugo umgestellt habe, habe ich verschiedene SSGs, die alle mit unterschiedlichen Techniken arbeiten, ausprobiert. Im Folgenden eine kurze Zusammenfassung meiner Erfahrungen. Eine Übersicht über die verfügbaren Generatoren gibt es auf dieser Website: https://staticsitegenerators.net/.

Allen SSGs ist gemeinsam, dass es keine graphischen Oberflächen gibt und sie alle von der Kommandozeile aus ausgeführt werden. Sie lassen sich alle sowohl unter Microsoft Windows, Linux als auch Mac OS installieren.

Als Auszeichnungssprache unterstützten alle Markdown (meistens in der erweiterten Version Github-flavored Markdown).

Jekyll und Octopress

Jekyll ist quasi der Urvater der SSGs und Octopress ein Framework, das auf Jekyll aufsetzt. Beide sind in Ruby geschrieben.

Die Installation unter Windows ist ziemlich aufwändig und eher etwas für Softwareentwickler. Unter Linux ist es deutlich einfacher, da Jekyll über die jeweiligen Package Manager installiert werden kann.

Wenn es aber einmal installiert ist, läuft es auch unter Windows problemlos. Es gibt viele vorgefertigte Themes und Plugins, mit der die Funktionalität erweitert werden kann.

Ich konnte mich allerdings mit Octopress nicht wirklich anfreunden (lag vielleicht an Ruby).

Für Entwickler, die ihre Projekte auf GitHub hosten, ist vielleicht interessant, dass Jekyll auf GitHub installiert und man somit seine Seiten direkt auf GitHub generieren kann, wenn man sie auch dort hosten möchte.

Hexo

Hexo ist ein relativ neuer SSG, der in Javascript implementiert ist und auf Node.js läuft. Für Einrichtung und Betrieb sollte man sich daher schon etwas mit Node.js auskennen. Es ist somit auch eher ein System für Bastler.

Der Generator ist schnell und es gibt auch diverse vorgefertigte Themes und Plugins, mit denen er erweitert werden kann.

Ich bin allerdings kein großer Freund der Anwendungsentwicklung mit JavaScript und das war dann auch der Grund, warum ich Hexo nicht verwendet habe.

JBake

JBake ist in Java geschrieben und hatte von allen bis dahin ausprobierten SSGs die einfachste Installation (und die beste Dokumentation). Sofern Java installiert ist, reicht es aus, JBake herunterzuladen und es kann direkt ausgeführt werden.

Besonderheiten von JBake sind die Verwendung von AsciiDoc als weitere Auszeichnungssprache und die Unterstützung mehrerer Template-Engines (Thymeleaf, Groovy, Apache FreeMarker). Die Generierung ist sehr schnell.

JBake war lange Zeit mein Favorit, aber die Weiterentwicklung ist leider eher schleppend.

Hugo

Hugo ist in Go geschrieben und die Installation ist noch einfacher als bei JBake: es reicht aus, eine einzige Datei herunterzuladen und schon ist man startbereit. Dazu ist Hugo auch noch extrem schnell.

Hugo unterstützt auch AsciiDoc (habe ich aber bisher noch nicht getestet).

Für die Implementierung von Themes wird die in Go integrierte Template-Technik verwendet. Diese ist vielleicht etwas gewöhnungsbedürftig, aber auf Grund der engen Anbindung an die Sprache auch sehr performant. Es gibt diverse vorgefertigte Themes, die man frei verwenden und anpassen kann.

Ich habe mich schlussendlich aus verschiedenen Gründen für Hugo entschieden:

  • Geschwindigkeit,
  • aktive Entwicklung,
  • es gibt eine aktive und sehr hilfsbereite Community,
  • ich wollte sowieso Go lernen :-)

Die aktuelle Ausgabe der Zeitschrift c’t (122016) enthält einen Artikel mit einer sehr guten Einführung in Hugo.

In weiteren Artikeln werde ich in nächster Zeit noch genauer beschreiben wie mein aktueller Workflow mit Hugo aussieht und wie z.B. die Suchfunktion auf dieser Seite implementiert wurde.

comments powered by Disqus