Warum eine statische Website?

Als ersten Beitrag im neuen Blog bietet es sich an, über den Blog selbst zu schreiben - oder genauer, über die Technik hinter der neuen Website von Isatis Web & Media.

Viele Websites verwenden sogenannte Content Management Systeme oder CMS, um den Inhalt zu verwalten. Diese Website geht einen anderen Weg und verwendet einen sogenannten Static Site Generator oder SSG, nämlich Jekyll. Was das bedeutet, und warum wir uns in diesem Fall für einen SSG und gegen ein CMS entschieden haben, soll dieser Blogbeitrag erklären.

Dazu ist es hilfreich, zunächst einen Blick in die Geschichte zu werfen. In den Anfängen des Word Wide Webs oder WWW hat sich ein relativ simples Grundprinzip etabliert: Eine Website ist als eine Datei oder mehrere Dateien auf der Festplatte eines Webservers gespeichert. Um eine Website anzuzeigen, muss ein Webbrowser diese Dateien herunterladen und auswerten. Der Inhalt und die Gestaltung der Website werden dabei mit Technologien wie HTML, CSS, JavaScript und anderen beschrieben. Das bedeutet, dass die Dateien für eine Website in der Regel einmal erstellt und dann immer wieder von Webbrowsern abgerufen wurden. Websites, die mit diesem Prinzip arbeiten, nennt man auch statische Websites.

Später kamen sogenannte dynamische Websites auf. Hier kam eine weitere Schicht dazu: Die Dateien für die Website wurden nicht mehr einmal produziert, um dann viele Male abgerufen zu werden. Stattdessen wurden Technologien entwickelt, um den passenden Code in HTML, CSS, JavaScript und so fort bei jedem Aufruf neu zu erzeugen, wenn gewünscht auch individuell angepasst. (Das ist etwas verkürzt dargestellt, weil es zum Beispiel Caching-Methoden außer acht lässt, aber es soll auch nur die grundsätzliche Idee illustrieren.)

Zu den Systemen, mit denen man solche dynamischen Websites bauen kann, gehören auch die bereits erwähnten CMS. Ein CMS nimmt eine Anfrage eines Webbrowsers entgegen, stellt die benötigten Daten zusammen (beispielsweise aus einer Datenbank), erzeugt den passenden Code in HTML, CSS, JavaScript und so fort, und schickt das Ergebnis zurück an den Browser. Hinter vielen heutigen Websites stecken CMS wie, um zwei der bekanntesten zu nennen, WordPress oder Drupal.

Ein SSG auf der anderen Seite ist eine Software, mit der man eine statische Website bauen kann. Die erzeugten Dateien platziert man dann, ganz klassisch, auf einem Webserver.

Aber warum haben wir für diese Website ein SSG und kein CMS gewählt? Kurz gesagt, weil wir die Möglichkeiten eines CMS hier nicht benötigen, und darum die damit verbundenen Nachteile nicht in Kauf nehmen müssen. Denn ein CMS hat auch seine Schattenseiten: Um die benötigten Daten in HTML, CSS, JavaScript und so weiter dynamisch zu erzeugen, muss eine passende Technologie wie PHP auf dem Webserver verfügbar sein. Das dynamische Erzeugen verbraucht Ressourcen. Und jede installierte Software kann potentiell Sicherheitslücken haben, die man stopfen muss.

Wer schon mal in die Log-Dateien eines Webservers geschaut hat, wird dort mit einiger Wahrscheinlichkeit Zugriffsversuche auf Dateipfade gesehen haben, die typisch für CMS wie WordPress sind - egal, ob auf dem jeweiligen Server je ein CMS installiert war oder nicht. Das hat einen simplen Hintergrund: Automatisierte Scanner versuchen auf jedem Webserver, den sie finden können, bekannte Schwachstellen in WordPress und so fort auszunutzen. Vielleicht treffen sie ja auf eine nicht ganz aktuelle Installation, die die böswilligen Akteure hinter den Scannern ausnutzen können. Entsprechend ist es gerade bei weit verbreiteten Systemen wie WordPress essentiell, neu veröffentlichte Version sehr zeitnah einzuspielen.

Zusammengefasst: CMS können sehr sinnvoll sein, sie können aber auch für unnötigen Ballast oder sogar potentielle Sicherheitsprobleme sorgen - je nach dem konkreten Anwendungsfall.

Bei dieser Website haben wir kein Problem damit, Inhalte in einer Auszeichnungssprache wie Markdown zu schreiben. Wir brauchen also keine graphischen Editoren oder Site Builder, wie sie viele CMS anbieten. Auch interaktive oder dynamische Inhalte werden auf dieser kleinen Website kaum verwendet - und wo sie sinnvoll sind, können wir sie auf andere Weise umsetzen als mit einem CMS. Die Entscheidung für einen SSG lag also nahe, und die persönliche Präferenz für die Programmiersprache Ruby gab den Ausschlag für das in Ruby programmierte Jekyll.

Wie wir dann konkret diese Website mit Jekyll umgesetzt haben, soll Thema des nächsten Blogbeitrags sein.