Manche Websites sind – nach der ersten Euphorie – ausgesprochen statisch. Nichts passiert mehr, und die “Aktuellen Ankündigungen” von 2005 interessieren heute niemanden mehr. Doch das ist heute nicht gemeint. Es geht um statische Website-Generatoren, genau genommen um einen solchen: Jekyll.
Der Auslöser liegt schon ein wenig zurück. Anfang März entschloss ich mich, die Website edv3.de nicht mehr weiterzuführen. Zwar halte ich die Grundidee, IT-relevante Themen kontrovers darzustellen, nach wie vor für gut, aber mangels weiterer Autoren befanden sich nur ein paar Artikel von mir auf der Seite. Und mangels Artikeln fanden sich auch nur wenige Leser. Das war den ganzen Aufwand nicht wert.
Nun besteht die Seite aber immer noch aus einer WordPress-Installation. Und wenn man die nicht dauernd aktualisiert, wird sie irgendwann sicher gehackt. Also musste eine Alternative her. Die Idee, einen statischen Websitegenerator zu verwenden, hatte ich schon länger. Viele Angebote im Netz basieren jedoch darauf, die Seite beim diesem einen Anbieter zu hosten und natürlich dafür Geld zu bezahlen. Da ich aber bereits eine Domain mit Speicherplatz gemietet habe, wäre das ziemlich sinnlos. Also suchte ich nach einer Möglichkeit, die statische Seite auf meinem Bürorechner selbst zu generieren, um sie dann per FTP einfach hochzuladen.
Statisch oder dynamisch?
Klären wir zunächst die Frage, was eigentlich eine statischen Website ist, und wieso man diesen Begriff überhaupt braucht. Früher, also in den Anfängen des World Wide Web, waren alle Seiten statisch. Wobei auch der Begriff “Seite” eigentlich ein falsch eingedeutschter Begriff ist. Im englischen heißt es “web site”, und eine “site” ist eben keine Seite, sondern müsste eher als “Stelle”, “Ort” oder “Platz” übersetzt werden. Aber da die Aussprache von “site” eben so schön wie das deutsche Wort “Seite” klingt, war es eben passiert. Seitdem sagen die Deutschen “Webseite” dazu, auch wenn sie “web site” meinen.
Aber zurück zum Thema: Früher waren alle Websites statisch. Man verwendete HTML, tja, und das war’s dann auch schon. Nicht gerade bequem, aber machbar, und in den Anfängen auch noch hinreichend einfach. Später kam dann CSS hinzu, was die Bequemlichkeit für den Webdesigner erhöhte (Design und Inhalte getrennt verwalten), aber es gab wieder etwas neues zu lernen. Die schon damals existierende Browservielfalt machte es nicht gerade einfach, und das war es letztlich, was mich davon abgehalten hat, “Webdesign” zu machen.
Mit JavaScript wurde es dann noch etwas komplizierter, vor allem fingen die Seiten dann an zu flackern. Das sorgte einerseits für mehr Aufmerksamkeit beim Besucher, andererseits aber auch für viel Frust. Trotzdem, dieses JavaScript lief und läuft im Browser, auf dem Webserver war nichts dynamisches.
Dann kamen die Content-Management-Systeme (CMS), und plötzlich war alles anders. Jedesmal wenn ein Besucher die Website aufruft, wird auf dem Server ein Script ausgeführt. Dieses liest Dateien und Datenbankinhalte ein und erzeugt daraus dynamisch das HTML, CSS und vielleicht auch den JavaScript-Code. Das Ergebnis dieser Generierung wird dann wie früher auch an den Browser des Anwenders geschickt, der damit das gleiche macht, was er damit schon immer gemacht hat: Er erzeugt die sichtbare Darstellung der abstrakten Beschreibung für den Anwender, was “rendering” genannt wird. Für den Blogger beinhaltet ein CMS diverse Vorteile. Er kann schnell das Design wechseln und kümmert sich primär um die Artikel, muss aber nicht darauf achten, das Seitenlayout nicht zu zerschießen.
Bei aller Flexibilität und Bequemlichkeit sollte aber auch nicht vergessen werden, dass jeder Seitenaufruf ein wenig Aktivität auf dem Server erfordert. Das bedeutet Arbeit für den Prozessor, und dafür braucht er Strom. Würde die Seite (oder die “Site”) komplett aus rein statischen HTML-Dateien bestehen, wäre diese Arbeit für den Webserver erheblich einfacher, was sich sicher auch auf den Stromverbrauch auswirkt.
Jekyll
Jekyll ist ein sogenannter statischer Websitegenerator. Ein solcher tut im Grunde nichts anderes als ein CMS auch, nur eben generiert er die Dateien für den Webserver immer nur dann, wenn sich am Inhalt etwas ändert, und nicht jedes mal, wenn ein User die Seiten sehen will. Das erleichtert dem Webserver die Arbeit, weil das reine Ausliefern vorbereiteter HTML-, CSS- und JS-Dateien wesentlich einfacher und daher schneller geht als die Datenbank zu durchsuchen, um die notwendigen Inhalte für die Seite zu finden, diese unter Berücksichtigung des gewählten Layouts vorzubereiten und dann erst auszuliefern.
Die Umstellung einer kompletten CMS-Website auf eine statische Version beinhaltet die Notwendigkeit, die bestehenden Inhalte zu migrieren. Denn es ist wohl damit zu rechnen, dass das Format der Datenspeicherung von z.B. Jekyll anders aussieht als das von WordPress. Für diesen Schritt gibt es auf der Jekyll-Projektseite diverse Lösungen. Auf diese will ich jedoch im Moment nicht weiter eingehen, denn in meiner konkreten Situation brauche ich das nicht. Da ich edv3.de ohnehin bereits bis auf einen einzigen kurzen Artikel bereinigt habe, übernehme ich dessen Text einfach manuell in das neue Format.
Da inzwischen allerdings sogar dieser eine einzige kurze Artikel eliminiert und durch eine winzige statische HTML-Seite ohne CSS ersetzt wurde, brauche ich mich um Jekyll zunächst nicht zu kümmern. Vielleicht komme ich daher später nochmal auf das Thema zurück. Vielleicht war der Artikel aber trotzdem interessant für euch.
Neueste Kommentare