Static Site Generatoren – kompiliertes HTML für schnelle Seiten

Der Traum von der schnellen Website steht am Beginn von jedem Projekt. Leider kommt dann die Realität: wir brauchen noch ein Plugin! Und noch ein weiteres! Am Ende ist das Projekt größer und größer geworden und nur mit noch größerem Aufwand lässt sich Geschwindigkeit erreichen.

Static Site Generatoren setzen hier an. Bei einer regulären Website gibt es eine Datenbank, in der die Inhalte liegen. Dazu eine Sprache wie PHP oder Ruby, die diese Inhalte verarbeitet. Der Client startet den Prozess mit einem Request an den Server. Dieser sucht dann die Inhalte aus der Datenbank. Anschließend werden diese serverseitig weiterverarbeitet und an den Client ausgeliefert.

Nur passiert dieses jedes Mal, sobald eine Anfrage an den Server gesendet wird. Auch wenn sich absolut nichts an den Inhalten geändert hat. Und in vielen Fällen ist das ziemlich unnötig. Denn oft ändern sich die Inhalte nicht. Etwa bei einem klassischen Blog. Ist der Artikel einmal veröffentlicht, kann er für jeden Seitenaufruf genau so ausgeliefert werden.

Und daher stellt sich die Frage: muss wirklich jedes Mal beim Aufruf der Seite derselbe Vorgang ausgeführt werden?

Daher verzichten statische Seiten auf das dynamische Parsen bei jedem Request an den Webserver. Die serverseitig Verarbeitung entfällt. Die Seite wird im Vorfeld lokal geparst, auf den Server geladen, und liegt als komplett auslieferungsbereites Dokument aus dem Server. Damit fällt ein Bottleneck weg.

Wann brauche ich wirklich dynamische Inhalte?

Die Frage ist wirklich berechtigt. Bei einem klassischen Blog gibt es nämlich sehr wenige Inhalte, die wirklich dynamisch erzeugt werden müssen. Wenn ich einen neuen Beitrag poste, dann ändert sich etwas im Listing der Artikel. Ansonsten aber nicht.

Und das ist anders als bei einem Online-Shop, bei dem es sehr stark um Filterung von Inhalten geht mit Kategorielistings, Filtern und Suchen. In Shops werden Inhalte bei jedem Aufruf zusammengesetzt. Spätestens für die Warenkorb-Funktion müssen Produkte im Client und auf dem Server gespeichert werden. Das ist von den Anforderungen her das genau Gegenteil von dem, was statische Seitengeneratoren liefern. Ebenso sind komplexe Suchanfragen besser bei einer klassischen Datenbank aufgehoben.

Entering Jekyll

Ich selbst nutze für einige Projekte den Statischen Generator Jekyll. Jekyll ist in Ruby geschrieben. Als Template-Engine kommt Liquid zum Einsatz, welche auch in Shopify genutzt wird. Per Default ist das  Minima Theme von Jekyll  aktiviert, dessen Dateien ich mit einem einfachen Copy&Paste in mein Child-Theme überschreiben kann. Das Theme verwendet Sass als CSS-Präprozessor.

Layout und Inhalt sind getrennt: Posts werden in einem eigenen Verzeichnis abgelegt: Jeder Post ist eine Textdatei, die mit Datumsstempel versehen wird. Ich habe selbst dazu ein Shell-Skript angelegt, mit dem ich eine automatisierte Vorlage erzeugen kann.

Wichtig an der Stelle ist, dass die Auszeichnungssprache nicht HTML sondern Markup ist. Jeder, der Github nutzt, kennt Markup aus den readme.md Dateien. Entwickler sind hier im Vorteil, aber an sich ist die Sprache wie HTML leicht erlernbar. Es gibt ein paar Konventionen um Hervorherbungen, Überschriften und Code darzustellen.

Das Kommando “jekyll serve” startet einen lokalen Server für die Entwicklung. Mit „jekyll build“ werden dagegen die Seiten kompiliert und in einem Verzeichnis abgelegt. ich Diese können so auf dem Server deployed werden. Und mehr gibt es hier eigentlich nicht.

Die Vorteile von Jekyll

  •  Versionierung und Deployment – ein Traum! Die Gretchenfrage bei Projekten mit Datenbank entfällt: wie hältst du es mit der Datenbank und Git? Datenbanken können nicht per Git versioniert werden. Bei Statischen Site-Generatoren kann einfach das komplette Projekt versioniert und deployed werden. Wer Sourcecode und Inhalte trennen will, kann Git Submodule nutzen. Aber an sich: hier ist im Gegensatz zu WordPress ganz einfach die Einrichtung einer CI/CD Pipeline möglich.
  • Gelöschte Daten sind wieder herstellbar. Es gibt kein löschen aus der Datenbank und wenn das versehentlich passiert ist der Artikel weg. Damit entfallen auch Backup-Strategien. Aller Code befindet sich in Git. Gut, der Git Server sollte sicher sein.
  • Geschwindigkeit. Vieles, was das Ausliefern von Seiten langsam macht, entfällt. Die Anforderungen an den Server schrumpfen auf “sehr niedrig”. Um PHP-Versionen auf dem Server muss man sich keine Gedanken mehr machen.
  • Keine Anforderungen an den Server. Meine Site kann in einem AWS S3 Bucket gehostet werden.

Die Nachteile von Jekyll

  • “Ich hätte gerne ein Kontaktformular auf der Site”. Was bei einer dynamischen Site kein Problem ist, ist eines für statische Sites. Es gibt Lösungen von Drittanbietern. Oder man schreibt selbst etwas. Spätestens beim Captcha fällt auf: das geht nicht so einfach. Weiterführende Infos dazu finden sich hier: https://blog.webjeda.com/jekyll-contact-form/
  • Ich kann Jekyll zwar durch Plugins “Archiv-Seiten” beibringen. Aber bei WordPress kann ich jeder Seite von Tags oder Kategorien noch einen Beschreibungstext zufügen. Für Suchmaschinenoptimierung ist das wichtig.
  • Es gibt keinen Backend-Editor. Etwa wenn ich Artikel mit Tags versehe. Habe ich den Tag schonmal verwendet? Gibt es den URL Slug bereits? Habe ich damals “Java“ oder „JAVA“ geschrieben? Das herauszufinden ist mit Markdown nicht ohne weiteres möglich. In WordPress oder anderen Systemen bekomme ich per AJAX direkt einen Vorschlag angezeigt.Beim Taggen von Artikeln ist das lästig, aber harmlos. Wenn es um Suchmaschinenoptimierung geht, möchte ein Admin aber wissen, wie die Inhalte struktuiert sind. Etwa anhand der Vorgaben die SEO-Plugins wie Yoast im WordPress-Backend liefern.
  • Ich kann mich auch nicht mal eben Online von unterwegs einloggen um noch Inhalte zu ändern. Dazu muss ich erst das Git-Archiv herunterladen, Änderungen erstellen und die Site deployen.
  • Die Site kann nur von erfahrenen Usern (und potentiell Programmierern) geupdatet werden. Ich muss ein Terminal bedienen können und wissen, was ich dort tue.

Die Vorteile von WordPress

  • Einfaches CMS Backend. Admins können leicht verständlich Artikel schreiben und veröffentlichen und Inhalte verwalten.
  • Plugins. Mit Plugins lässt sich das System beliebig erweitern.

Die Nachteile von WordPress

  • Plugins. Habe ich nicht gerade Plugins als Vorteil aufgeführt? Ja. Das stimmt. Nur leider ist auch das Gegenteil wahr: Plugins sind eine der größten Schwächen von WordPress. Die modulare Erweiterung sieht erstmal gut aus. Nur macht jedes weitere Plugin WordPress langsamer und fehleranfälliger. Und dann ist WordPress nicht mehr einfach zu bedienen – im Gegenteil. Es ist wie ein Haus, an dem sich 20 verschiedene Architekten austoben durften.
  • Versionierung: diese ist ein ziemlicher Alptraum. In WordPress wird die Datenbank voll gepackt mit Versionen des Artikels. Genau so gruselig geht es im Backend weiter: dort ist nicht wirklich nachvollziehbar, welche Versionen eines Textes verglichen werden können. War es ein Autosave? Wer hat zuvor gespeichert?
  • Sicherheit: WordPress bietet durch die weite Verbreitung Hackern ein riesiges Einfallstor. Gerade durch Plugins, die teils millionenfach installiert weltweit sind.

Fazit

Statische Sitegeneratoren sind eine feine Sache. Mit ihnen lassen sich einfach statische HTML Dokumente erzeugen. „Back to the roots“ sozusagen zu den Zeiten, als das Web noch aus html Dokumenten bestand, die man auf Server hochgeladen hat.

Es gibt inzwischen sehr viele davon und der aktuelle Überblick findet sich unter  https://www.staticgen.com/

Kurzer Hinweis noch: der Entwurf des Artikels lag etwas herum. Aus heutiger Sicht würde ich nicht mehr Jekyll nutzen, sondern Hugo. Da es auf Go basiert und dadurch deutlich schneller beim Kompilieren und einfacher selbst erweiterbar. Und mir liegt Go näher als Ruby.

Veröffentlicht in CMS

Schreibe einen Kommentar

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

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.