Sie sind wie die Schallplatte: Statische Websites sind zurück. Knapp 60 Prozent aller Websites sind statisch [1], also nicht dynamisch generiert oder durch ein CMS betrieben – und es werden wieder mehr. Einsatzgebiete gibt es viele: Klick-Dummys und Templates, statische Blogs oder E-Books, Dokumentationen oder Styleguides. Immerhin haben statische Sites einen deutlichen Performance-Vorteil gegenüber schwerfälligen CM-Systemen.

Zwar gab es schon immer HTML-Editoren, mit denen Webdesigner mehr oder weniger komfortabel statische Websites lokal auf ihrem Rechner erstellen und verwalten konnten, aber wirklich befriedigend war das nie. Doch die heutigen Generatoren statischer Websites kann man nicht mit WYSIWYG-Programmen wie Dreamweaver vergleichen. Sie produzieren am Ende zwar im Grunde auch statisches HTML, greifen aber auf Technologien dynamische Programmierung zurück. Die meisten dieser Static-Site-Generatoren bringen eine umfassende Dateiverarbeitung mit, mit der sich Dateien (CSS/JS) beispielsweise zusammenfassen, verarbeiten und minifizieren lassen. Oftmals ist Sass oder Less als CSS- bzw. JavaScript-Präprozessor mit an Bord.

Nahezu alle Systeme unterstützen Markdown als simple Auszeichnungssprache, sodass Webdesigner ihre Inhalte wirklich sehr schnell semantisch auszeichnen können, ohne wirklich Code schreiben zu müssen. Für dynamische Inhalte – ob nun seitenspezifisch oder global – kommt sehr oft YAML Front Matter zum Einsatz.

Der Vorteil eines Static-Site-Generators liegt auf der Hand: Webworker können die Dynamik einer Skript-Sprache nutzen, um sich wiederholende Elemente nicht jedes Mal neu schreiben zu müssen oder Markup mit dynamischen Daten zu vermischen. So muss ein Webdesign einen Navigationspunkt zum Beispiel nur einmal ändern, er wird automatisch auf allen anderen Seiten aktualisiert. Das spart viel Arbeit und vermeidet Fehler. Dafür sind auch keine serverseitigen Skriptsprachen(-kenntnisse) notwendig. Im Grunde reichen HTML-, CSS- und JavaScript-Kenntnisse aus, um statische Sites mit diesen Tools zu erstellen.

Weil die Systeme keine Datenbank benötigen, ist ein günstigeres und einfacheres Hosting möglich – die statischen Dateien werden so ausgeliefert, wie sie auf dem Server liegen, lassen sich direkt auf ein CDN publizieren oder via Cloud verteilen. Keine Datenbankabfrage, kein dynamisches Rendering – nur reiner Text und Bilder, die der Server gut komprimieren und schnell ausliefern kann: Das steigert die Performance.

Bei statischen Inhalten haben Hacker zudem weniger Angriffsmöglichkeiten, da es hier keine Formulare gibt, die sich als Spamschleuder nutzen ließen, und auch keine Datenbank, die Nutzerdaten preisgeben könnte. Sicherheits-Updates muss man dann auch nicht unbedingt zeitnah einspielen, wie das bei einem Open-Source-CMS der Fall ist.

Wollen Webdesigner die Static-Site-Generatoren zudem nutzten, um statische Templates oder Mockups zu erstellen, haben sie den Vorteil, dass sie die Ausgangs-Templates gut weiterverarbeiten können: Idealerweise lassen sich die Template-Schnipsel auch in dynamischen Anwendungen verbauen.

Das statische Konzept passt nicht zu jeder Website. Ein Defizit statischer Websites sind User-generierte Inhalte, da hierfür meist eine serverseitige Programmiersprache nötig ist. Aber auch dafür gibt es mittlerweile Lösungen.

Für Kommentare hat sich etwa seit Jahren der Service Disqus [2] etabliert. Er stellt nicht nur eine Kommentarfunktion für Blogs
bereit, sondern kann gleichzeitig auch verwandte Inhalte automatisch
darstellen. Somit können Betreiber ihre Website gleichzeitig
monetarisieren.

Ein Kontakt-Formular ist ebenfalls ein klassisches Beispiel für eine Anforderung, an der der Einsatz statischer Systeme scheitert. Doch auch dafür gibt es eine Lösung: Mit dem Tool Formspree [3] können Webdesigner Formulare in statische Websites einbinden. Es schickt die Nachricht dann über einen externen Service ab. Das kommt sicherlich nicht für jeden Fall in Frage, da das Versenden über fremde Server für viele ein datenschutzrechtlicher Stolperstein ist. Webworker sollten genau prüfen, ob dies ein Problem für den Kunden darstellt.

Die Lösung Snipcart [4] integriert Kaufprozesse in statische Websites und kümmert sich um den Rest: Jedes Element (optimalerweise ein Button) lässt sich dann zu einem Kauf-Button umwandeln. Selbst eine Warenkorbfunktion für mehrere Produkte bietet Snipcart. Auf Github kann man seine (Jekyll-)Seite kostenlos hosten. Mit jedem
Deployment wird die Seite aktualisiert. Weitere (kostenlosen)
Hosting-Möglichkeiten bieten Surge.sh [5] oder Netlify [6]. Netlify hat zudem im Blog viele Tipps für die Integration verschiedener Static-Site-Generatoren-Tools.

Wollen Kunden ihre Website selbst verwalten, fällt die Entscheidung
schnell für ein klassisches CMS aus. Dabei aktualisieren viele Kunden
ihre Website nur selten. Ein CMS ist in einem solchen Fall oftmals überdimensioniert. Deshalb
gibt es hierfür bereits eine Lösung: Die SaaS-Lösung
Contentful [7] bietet keine eigene CMS-Oberfläche, sondern eine API, mit der Kunden Inhalte auf statischen Seiten editieren können.

Sind die Vor- und Nachteilen abgewogen und ist die Entscheidung für eine statische Website gefallen, so fragt sich, welcher Static-Site-Generator der richtige ist. Hier ein Überblick der wichtigsten Tools:

Unter den Static-Site-Generatoren taucht schnell das Tool Middleman [8] auf. Es basiert auf Ruby und unterstützt demzufolge die Ruby-Template-Sprachen ERB, HAML, Slim und andere. Es unterstützt aber auch Markdown (Kramdown) oder Jade. Die Techniken, die hier zum Erstellen der statischen Sites zum Einsatz kommen, lassen sich auch sehr gut in Ruby/Rails-Projekten weiterverarbeiten.

Wer Middleman installiert, erhält gleichzeitig auch Sass (Middleman nutzt jetzt auch das schnellere „Sassc“ – libsass für Ruby) und CoffeeScript. Ähnlich wie bei dem Web-App-Tool Yeoman gibt es mittlerweile viele Projekt-Vorlagen [9], mit denen man unterschiedliche neue Projekte starten kann.

Außerdem gibt es für Middleman viele Plugins, um das System an die individuellen Anforderungen anzupassen. In seiner Dokumentation nutzt Middleman ERB-Template-Beispiele. ERB ist für den Einstieg in die Ruby-Template-Engines gut geeignet, da diese nicht so abstrakt ist wie etwa HAML. Middleman bringt einige Template-Helper sowie ein ausgeklügeltes Asset-Management der Rails-Asset-Pipeline mit. Damit sind Angaben von Dependencies möglich sowie Asset-Caching oder Packaging – also alles, was man für ein statisches Template oder eine statische Website braucht.

Jekyll [10] findet derzeit oft als statischer Blog-Ersatz seinen Einsatz und basiert ebenfalls auf Ruby. Mit dem Generator lassen sich Inhalte in Markdown-Dialekten oder HTML in verschiedenen Layouts publizieren. Daneben bietet Jekyll vor allem Feature aus der Blog-Welt: Kategorien, Tags, Posts und dazu passende Paginatoren. Und das mit Erfolg: 2012 sammelte das Kampagnenteam von Obama rund 250 Millionen US-Dollar Spenden über eine statische Jekyll-Seite ein. 2013 wechselte die Site healthcare.gov von einem CMS zu einem statischen Jekyll-Ansatz.

Für Entwickler eignet sich Jekyll besonders als Ersatz für WordPress: Jekyll publiziert problemlos auf GitHub-Pages – kein Wunder, da Jekyll aus der Feder des GitHub-CEOs Tom Preston-Werner stammt. Wer Jekyll Now [11] auf Github forkt, hat innerhalb von wenigen Sekunden eine lauffähige Jekyll-Seite auf seinem Github-Repository. Wer jedoch mehr als die übliche Dokumentation- oder Blog-Funktionalität braucht, stößt schnell an die Grenzen von Jekyll. Zwar gibt es zahlreiche Plugins [12] – an die Möglichkeiten, die etwa Assemble (mit Handlebars Helpers) oder Jade bieten, kommt Jekyll nicht heran.

Assemble [13] startete als Static-Site-Generator für Grunt, hat aber im letzten Jahr einen kompletten Neubau hinter sich und steht nun als Stand-Alone- sowie NodeJS-basiertes System bereit. So kann es jetzt mit Grunt, Gulp oder anderen Build-Tools zusammenarbeiten, sowie gleichzeitig direkt auf dem Server laufen.

Assemble nutzt Handlebars [14] als Template-Engine und unterstützt zudem viele Template-Helper [15]. Zudem können jetzt auch Lo-Dash oder andere Template-Engines zum Einsatz kommen. Assemble erkennt die Engine automatisch und kompiliert alles zusammen zu statischen Seiten.

Im Vergleich zu Middleman hat Assemble keinen CSS-Präprozessor im Paket. Der Generator konzentriert sich auf die Template- und Inhalt-Verarbeitung. Assemble eignet sich etwa, wenn Handlebars für clientseitiges Rendern mit JavaScript zum Einsatz kommt.

Die statischen Inhalte, die Assemble produziert, lassen sich leicht weiterverarbeiten. Für die dynamischen Teile der Website können Webworker die Ausgangspartials verwenden, um mit einer Datenquelle direkt im Browser die Templates zu verarbeiten.

Ein Aufsteiger im Markt der Static-Site-Generatoren ist Hugo [16]. Er basiert auf der Programmiersprache Go und zeichnet sich nicht nur durch seine enorme Geschwindigkeit beim Erzeugen statischer Inhalte aus, sondern auch durch die problemlose Installation auf sämtlichen Betriebssystemen. Zudem hat Hugo keinerlei Abhängigkeiten wie viele andere Systeme. Wer also sehr viel Content hat, der ist mit Hugo gut bedient.

Hugo hat zwar einige Eigenarten, arbeitet aber grundsätzlich wie andere Systeme auch: Man kann nicht nur YAML [17] oder JSON zur Konfiguration verwenden – der Generator unterstützt auch das neue Format TOML [18]. TOML ist im Grunde wie YAML eine Konfigurationssprache, aber in vielen Teilen JSON ähnlicher und etwas mächtiger.

Natürlich gibt es auch für Hugo schon diverse Themes, die Webdesigner für ihre Seite oder ihren Blog nutzten können. Auf themes.gohugo.io [19] steht ein großen Katalog zur Verfügung.

Metalsmith [20] basiert auf Node und verfolgt einen komplett anderen Ansatz. Hier benötigen Webdesigner für jede Aufgabe ein kleines Node-Plugin – Metalsmith stellt also nur die Architektur bereit. So ist das Tool also nicht unbedingt ein klassischer Static-Site-Generator, obwohl es oft dafür zum Einsatz kommt. Für eine kleine statische Website benötigt man „metalsmith“ selbst, sowie die Node-Module „handlebars“, „metalsmith-layouts“, „metalsmith-markdown“ und „metalsmith-permalinks“.

Metalsmith kann durch das Zusammenstellen von verschiedenen Plugins auch ein E-Book-Generator oder ein Tool für technische Dokumentation sein. Das hat natürlich Vorteile: Man braucht nur die wirklich notwendigen Abhängigkeiten und keine Vielzahl an unnötigen Modulen.

Statische Websites sind nicht ohne Grund wieder angesagt: Sie bieten etliche Vorteile. Im Netz finden Webdesigner lange Listen von Static-Site-Generatoren [21]
[22]. Und so scheitert der Einsatz eines solchen Generatoren nicht an der Auswahl: Es gibt für alle Ansprüche und Vorhaben entsprechende Tools.

Es mag eine Vielzahl an Websites geben, die für statische Konzepte ungeeignet sind. Das heißt aber noch lange nicht, dass Webdesigner immer sofort zu WordPress und Co greifen sollten, wenn sie einen Auftrag annehmen. Oftmals ist eine statische Site – insbesondere für kleinere Projekte – vollkommen ausreichend. Webdesigner sollten angesichts der heutigen umfangreichen Möglichkeiten also zweimal überlegen, ob es tatsächlich ein Content-Management-System sein muss.