Über statische Seitengeneratoren

Wenn ein Nutzer auf eine Website geht und der angefragte Server nichts weiter tun muss als eine schon vorhandene HTML-Seite zurückgeben, dann ist das ein schneller Vorgang. Ein sehr schneller. Ein so schneller, dass kein – ja wirklich: kein – CM-System da mit halten kann. Überhaupt: Kein System, dass auf serverseitige Programmierung (die Weiterverarbeitung einer Anfrage und das rendern von HTML kosten Zeit) und schlimmstenfalls sogar auf eine Datenbank (kostet noch mehr Zeit) zurückgreifen muss, kann da mithalten.

Und dennoch geht der Trend dahin, dass man auch die simpelsten Websites mit einem CM-System – sehr häufg mit Wordpress – umsetzt. Gerade bei einem gleichzeitig steigenden Bewusstsein für SEO erstaunt dies: Ist doch für die Suchmaschinen die Ladezeit der Website durchaus ein Kriterium für das Ranking. Dies gilt im Übrigen auch für den SEA-Bereich, wo bspw. das AdWords-System für die Berechnung des Qualitätsfaktors ebenfalls die Ladezeiten der Zielseite einer Anzeige berücksichtigt.

Fertige CM-Systeme bringen dazu einiges an Overhead mit sich, der gerade für kleine Seiten und Blogs eine "Belastung" darstellen kann. Dieser Overhead betrifft in der Regel vor allem bestimmte Voraussetzungen die bezüglich des Hostings erfüllt sein müssen: Speicherplatz, vorhandene Datenbank(en), eine bestimmte Version der Programmiersprache, die das CMS verwendet, etc. pp. Dagegen bietet jedes Hosting-Paket die Möglichkeit HTML auszuliefern – ist das doch der "Kern des Geschäfts".

Was dann? Statische Seitengeneratoren!

Eine Antwort auf all diese Probleme kann die Verwendung eines statischen Seitengenerators darstellen. Dabei handelt es sich um Systeme, die meist wie folgt funktionieren: Der Anwender installiert den Generator auf seinen Heimrechner und legt anschließend Dateien ab, die in einer markup language formatiert werden. Dabei kann es sich zum Beispiel um Markdown oder reStructuredText handeln. Das markup ist dabei in der Regel weit weniger komplex als das Schreiben von HTML-Dateien und auch von "Laien" oder weniger technik-affinen Menschen schnell zu erlernen.

Die Daten, d. h. der vom Nutzer verfasste Text, werden von dem installierten System automatisch in eine Vorlage (Template) eingefügt. Das Ergebnis ist eine einfache und statische HTML-Seite. Die Vorlage, das hinterlegte Design… alles lässt sich beliebig anpassen, was in der Regel aber Kenntnisse in HTML und CSS, bei tiefergreifenden Änderungen der dem System zu Grunde liegenden Programmiersprache erfordert. Dies ist andererseits bei einem System wie Wordpress ebenso der Fall: Möchte man ein eigenes Theme haben, muss man sich ebenfalls mit PHP, HTML und CSS herumschlagen.

Das Template bzw. das dahinter liegende System kann dabei durchaus komplexere Aufgaben erfüllen: Artikel lassen sich tags und Kategorien zuordnen, die in automatisch angelegten Übersichtseiten durchsuchbar sind. Eine Navigation erfasst statische Seiten; bei einem Blog kann eine Übersichtsseite mit allen Artikeln und einer kurzen Beschreibung angelegt werden.

Das wichtige ist: Alles, was so ein statischer Seitengenerator tut, hat zum Ergebnis HTML. Die fertige Website mit allen Unterseiten, dem zugehörigen CSS und JavaScript wird in einen Ausgabe-Ordner geschrieben, der sich am Ende auf den Server hochladen lässt und weder eine Datenbank noch weitere Programmierung benötigt. Diese Seiten können später direkt vom Server ausgeliefert werden.

Einige Beispiele und Systeme

Ein Beispiel für eine durch ein solches System generierte Website ist – große Überraschung – dieser Blog; er wurde mit Pelican erstellt, das wiederum auf Python als Programmiersprache zurückgreift. Das bekannteste System zum erstellen von statischen Websits im Bereich Blog dürfte Octopress aus der Ruby-Welt sein. Octopress baut auf dem Seitengenerator Jekyll auf, mit dem die GitHub-Seiten erstellt und gepflegt werden.

Systeme gibt es inzwischen wie Sand am Meer: eine Google-Suche fördert schnell eine Vielzahl zu Tage. Die Unterscheide liegen meist in der verwendeten Markup-Sprache, der Anpassbarkeit und der zu Grunde liegenden Programmiersprache.

Das Schreiben von Blog-Beiträgen oder einzelnen Seiten in Markdown ist (wie oben bereits erwähnt) eigentlich keine große Sache; das Starten des Kompilierungsvorgangs und eines Vorschau-Servers geschieht in der Regel aber über die Kommandozeile (und in der Regel ist dafür tatsächlich nur ein kurzer Befehl nötig), was statische Seitengeneratoren in den Ruf bringt nur etwas für Experten und Programmierer zu sein. Octopress selbst bezeichnet sich als "Blogging framework for hackers".

Das tut der Verbreitung dieser Systeme nicht gerade gut.

Fazit und Einsatzbereiche

Statische Seitengeneratoren sind:

Dagegen bieten dynamische Seiten (bspw. CM-Systeme):

Was heißt das für den Einsatz?

Statische Systeme eignen sich für kleine Websites oder Blogs; eine Möglichkeit zu kommentieren kann nachträglich über Dienste wie disqus leicht ergänzt werden. Es eignet sich außerdem für alle Arten von Seiten, bei denen keine Interaktion des Nutzers mit der Seite nötig ist und bei der die einzelnen Seiten häufig ähnlich strukturiert sind.

Es eignet sich nicht für Seiten, bei denen Interaktion notwendig ist, d. h. ein Soziales Netzwerk oder ein Shop-System würde schwierig bis unmöglich umzusetzen.

Obwohl gerade Shops ein Ansatz für eine interessante Idee sind: In Shops sind Produkt- und Übersichtsseiten immer verhältnismäßig statisch und schematisch aufgebaut und ließen sich prima über einen Generator erzeugen; problematisch wird es erst, wenn es zum Bestellprozess kommt, der wiederum höchst interaktiv ist und ein Backend (Programmierung und DB) erfordert.

Aber: Der Nutzer hält sich in der Regel mindestens 80% der Zeit auf Übersichten und Detail-Seiten auf – wenn diese bzgl. der Ladegeschwindigkeit optimiert würden, wäre das ein großer Gewinn für die Suchmaschinenfreundlichkeit und (noch wichtiger) für die Usability. Von Systemen, die auf eine Kombination aus beiden Welten bauen, habe ich aber bisher noch nicht gehört…