JAMstack und mein Blog (Teil 2)

2017-08-24 in Allgemeines tutorial, web, hugo

Ich habe lange Zeit an der Technik meines Blogs gefeilt. Inzwischen ist ein Stand erreicht, mit dem ich sehr zufrieden bin. Für Interessierte hier die Beschreibung der technischen Hintergründe.

Artikel zwei von drei: Generierung statischer Webseiten mit Hugo

Übersicht

Teil 1: Argumente gegen Wordpress
Teil 2: Statische Webseiten mit Hugo
Teil 3: Hosting und Deployment

Warum statische Webseiten?

Wie im letzten Artikel schon kurz erwähnt wurde, haben statische Webseiten einige Vorteile gegenüber Seiten, die dynamisch bei jedem Seitenaufruf generiert werden.

Vorteile:

weniger und einfachere Software auf den Servern
Weniger Software heißt weniger Einrichtungs- und Wartungsaufwand. Das ist eher ein Punkt, der den Provider interessiert aber über den Preis macht sich das auch beim Kunden bemerkbar.
Zusätzlich ergibt sich dadurch auch weniger Angriffsfläche für Hacker und Saboteure. Vergleichen Sie das einfach mit einem Haus - ein Haus das nur eine gut gesicherte Eingangstür und nur sehr schmale Fenster hat, durch die keine Person hindurch paßt ist gegen Einbrüche viel besser gesichert als ein Haus mit einer Eingangstür, einer Kellertür, einer Terassentür und eventuell noch einer Balkontür. Wenn dann noch große Fenster hinzukommen, die wegen der Lüftung angekippt bleiben, sind potenzielle Einbrecher mit Sicherheit mehr an diesem Haus interessiert als an dem vorher geschilderten. Sicherheit und Funktionalität/Bequemlichkeit sind meistens Dinge, die sich entgegenstehen - auch bei Software.
Keine Berechnung auf den Servern nötig
Statische Webseiten liegen auf einem Server einfach im Dateisystem - wenn eine Seite angefordert wird, muss der Server sie nur von der Festplatte lesen und ausliefern.
Bei dynamischen Seiten hingegen (wie bei Wordpress) wird zunächst eine Seite geladen und einem Interpreter übergeben, der die Programmier-Anweisungen darin ausführt. Dabei werden meistens noch weitere Programmteile nachgeladen, es wird unter Umständen eine Datenbankverbindung hergestellt und Abfragen in der Datenbank durchgeführt. Am Ende wird aus all den gesammelten und berechneten Daten eine HTML-Seite generiert, die dann vom Webserver ausgeliefert wird. Diese ganzen Berechnungen können (relativ) sehr viel Zeit kosten und verbrauchen auf dem Server Rechenzeit, Speicher und eventuell auch Plattenplatz. All diese Dinge fallen bei statischen Seiten weg.
Effiziente Cache-Nutzung
Caches (Zwischenspeicher) sorgen in vielen Komponenten der Web-Infrastruktur dafür, dass die Berechnung oder Übertragung von Daten unterbleiben kann. Lassen Sie mich das an einem einfachen Beispiel erläutern:
Nehmen wir an, eine Außenstelle einer Firma benötigt Einsicht in Dokumente aus der Zentrale (und es gibt noch keine EDV-gestützte Bearbeitung). In diesem Fall würde man z.B. per Kurier das Dokument in die Außenstelle bringen, dort die benötigten Arbeiten durchführen und das Dokument dann wieder per Kurier in die Zentrale zurücktransportieren. So weit so gut.
Nun kommt es aber vor, dass das gleiche Dokument innerhalb einer Woche dreimal gebraucht wird. Um sich die dauernden Transporte zu sparen, fertigt die Zentrale eine Kopie eines Dokuments an, sobald dies zum ersten mal in die Außenstelle gebracht werden soll und läßt diese dorthin liefern. Die Außenstelle arbeitet dann mit der Kopie.
Wird das Dokument erneut gebraucht, ruft der Bearbeiter der Außenstelle in der Zentrale an und läßt sich das Datum der letzten Änderung des Dokuments durchgeben. Ist auf seiner Kopie das gleiche Datum vermerkt, kann er diese benutzen. Falls nicht, muss das Dokument in der Zentrale wieder kopiert und diese Kopie zur Außenstelle gebracht werden. Die alte Kopie in der Außenstelle wird dann vernichtet.
Die Außenstelle hat wesentlich weniger Platz als die Zentrale und kann nicht den gesamten Dokumentenbestand als Kopie vorhalten. Deswegen werden Kopien, die lange nicht benutzt wurden und bei denen eine baldige erneute Benutzung unwahrscheinlich ist, vernichtet.
So eine Arbeitsweise ist heute natürlich unwahrscheinlich aber genau auf diese Weise funktioniert ein Cache.
Wie schon erwähnt, können sich Caches an vielen Stellen der Web-Infrastruktur befinden. Am effektivsten ist der Cache in Ihrem Web-Browser - der funktioniert so wie im Beispiel beschrieben und sorgt dafür, dass eine Webseite nicht noch einmal angefordert werden muss, falls sie im Cache schon vorliegt. Aber auch Ihr Provider kann einen transparenten Cache betreiben, ohne dass sie dies bemerken - das ist zum Beispiel bei Mobilfunkbetreibern üblich oder auch bei WLAN-Hotspot-Betreibern. Ebenso kann der Webserver hinter einem Cache-Server betrieben werden - das ist vor allem bei dynamischen Anwendungen üblich.
Und auch innerhalb der Server-Software selbst gibt es unter Umständen Caches, die die Neuberechnung von Seiten oder Seitenelementen reduzieren sollen.
Warum nutzen dann statische Webseiten Caches besser aus?
Eigentlich können dynamische Seiten ja gar nicht gecached werden, oder? Schliesslich handelt es sich ja bei jedem Aufruf um eine neue Seite.
Im Prinzip ist das richtig, allerdings wird oft immer wieder der gleiche Inhalt generiert. Typisch dafür ist ein Blog, der einmal im Monat einen neuen Artikel bekommt - den gesamten Monat über werden die gleichen Seiten generiert. Und hier liegt die Schwierigkeit, die das Caching von dynamischen Seiten so kompliziert macht: ab wann ist eine Seite im Cache zu ersetzen? Da gibt es die verschiedensten Mechanismen, von denen viele nur als Kompromiß zwischen Aktualität und Wirksamkeit das Caches funktionieren. Das kann in der Folge sogar zu defekten Webseiten führen, zum Beispiel wenn ein Link sich schon verändert hat, aber die verlinkende Seite immer noch mit dem alten Inhalt ausgeliefert wird.
Bei statischen Seiten ist das Caching ganz einfach: Das Datum der Änderung wird als Kriterium herangezogen - sobald sich dieses ändert, muss die Seite neu angefordert bzw. ausgeliefert werden - so wie im obigen Beispiel. Da es keine Zweideutigkeit bzgl. dieser Entscheidung gibt, kann man Caches mit 100% Wirksamkeit betreiben ohne dass die Aktualität der Seiten beeinträchtigt wird.
einfacher für CDN
Sogenannte Content Delivery Networks sorgen dafür, dass sich Inhalte dicht beim Kunden befinden. Für die gleiche Webseite werden Inhalte zum Beispiel von einem Server in den USA oder einem in Vietnam oder auch Deutschland ausgeliefert, je nachdem von wo die Seite aufgerufen wird. Viele CDN-Betreiber haben nicht nur einen Standort in einem Land oder Kontinent, sondern u.U. einen in jeder Großstadt. Das sorgt ähnlich wie bei den Caches dafür, dass Übertragungskosten gespart werden und die Kunden eine schnellere Verbindung zu dem für sie zuständigen Server haben.
Dynamische Seiten haben bei CDN die gleichen Nachteile wie bei den Caches - auch hier ist das Ausliefern über die CDN-Server immer ein Kompromiß zwischen Aktualität und Effizienz. Statische Seiten können direkt auf den Endservern des CDN platziert werden. Hier gibt es diesbezüglich keine Probleme.
schnelleres Laden der Seiten
Aus den vier vorher genannten Punkten ergibt sich potenziell, dass die Webseiten schneller geladen werden. Natürlich kann man auch langsam zu ladende statische Seiten generieren aber bei gleicher Technik-Ausstattung, Internetverbindung und gleichem Seiteninhalt sind statische Webseiten schneller.

Natürlich gibt es nicht nur Vorteile statischer Seiten, sonst wären ja dynamische Web-Systeme nie erfunden worden. Hier die (angeblichen)

Nachteile:

keine Interaktivität
Zumindestens war das so, als die dynamischen Websysteme ihren Siegeszug antraten.
Die heutige Web-Welt sieht ganz anders aus. Es gibt eine Unmenge von Daten-Standards, Protokollen und standardisierten (Mini-)Diensten, die Daten entgegennehmen und diese verarbeitet wieder zurückgeben. In Verbindung mit dem heute wirklich mächtigen JavaScript (die in die Web-Browser eingebaute Programmiersprache) kann man problemlos auch mit statischen Webseiten Interaktivität erreichen. Der Nachteil exisitiert also nicht mehr wirklich.
keine dynamische Layout-Anpassung
Die Vielzahl verschiedenster Endgeräte macht es oft notwendig, eine Webseite in verschiedenen Varianten auszuliefern. Bei dynamischen Web-Systemen wurde das lange Zeit innerhalb der Serversoftware entschieden und umgesetzt.
Spätestens seit CSS3 in den Browsern implementiert ist, besteht hierfür keine Notwendigkeit mehr. Es existieren diverse Frameworks für Javascript und CSS3, die die Anpassung eines Layouts selbständig auf dem Endgerät vornehmen. Dieser Nachteil existiert also auch nicht mehr.

Auch wenn die Nachteile nicht mehr in der Form existieren, so ist dennoch zu bemerken, dass sich durch große CSS- und Javascript-Bibliotheken natürlich auch die Ladezeiten erhöhen. Und einfach ist das ganze auch nicht :)

Generatoren für statische Webseiten

Hier einige Beispiele für Generatoren von statischen Webseiten:

OpenText Web Site Management (ehemals RedDot CMS)
iWeb (Apple)
PineGrow CMS
Mobirise

und die mehr textorientierten “Generatoren”:

Hugo

Wie schon erwähnt habe ich mich für Hugo entschieden. Mit webgen hatte ich schon Erfahrungen gemacht und dort war die zugrunde liegende Sprache Ruby. Auch der am häufigsten genutzte Generator Jekyll ist in Ruby implementiert und man benötigt für seine Installation eine lauffähige Ruby-Installation. Da ich keine Lust hatte, erneut Ruby auf meinem Mac zu installieren und mich überhaupt mit einer Ruby-Installation zu beschäftigen habe ich einen Generator gewählt, der keine großen Voraussetzungen benötigt.

Mit Javascript-Frameworks wie node.js kannte ich mich nicht aus, die Generatoren, die das benutzen fielen also auch aus der Wahl. Blieben welche, die leicht zu installieren waren oder auf einer mir bekannten Programmiersprache bzw. einer die schon auf dem Mac vorhanden ist aufsetzen. Die Portabilität war ebenso wichtig - meine Webseite will ich auch auf einem Windows-System oder unter Linux pflegen können.

Den Ausschlag gab für mich letztendlich die Hugo-Webseite, die vorhandene Dokumentation, die schon vorhandenen Website-Templates und die Einfachheit der Installation. Hugo ist in der Programmiersprache Go verfasst, wovon man aber nichts mitbekommt, weil hugo als eine ausführbare Datei ausgeliefert wird. Da hat jemand wirklich über Nutzerfreundlichkeit nachgedacht, Respekt! Die Datei wird in ein Verzeichnis kopiert, das im Suchpfad liegt oder einfach irgendwo abgelegt, wo sie leicht aufrufbar ist (der Aufruf erfolgt von der Kommandozeile). Hugo ist im Prinzip auf allen gängigen Betriebssystemen verfügbar (Windows, Linux, Mac, BSD).

Themen

Hugo bietet schon eine Menge fertiger Website-Themen an. Hier ist für viele Geschmäcker und Anwendungsfälle etwas dabei. Da ich meinen Blog mit Hugo realisieren wollte, kam mir natürlich entgegen, dass viele der Themen für Blogs entworfen wurden.

Bei Hugo sind Inhalte und Design getrennt - die Inhalte werden als Textdateien in der Markup-Sprache MarkDown bereitgestellt. Das Design und die Funktionalität sind im Thema hinterlegt.
Auch wenn das erst einmal danach klingt, dass man mal eben einfach ein Thema wechseln kann, ist dies jedoch nicht ganz so einfach. Wie ich gerade erwähnte implementieren die Themen auch Funktionalität und die Einstellungen dafür sind bei jedem Thema potenziell anders. Beim Wechsel eines Themas hat man also schon einige Arbeit zu leisten - seine Inhalte verliert man natürlich nicht.

Wenn die Inhalte sich an Eigenschaften eines Themas orientieren - bei mir trifft das z.B. auf die eingebundenen Bilder zu - ist ein Wechsel natürlich noch schwieriger.
Man sollte also das Thema mit Bedacht wählen, bevor man allzuviel Arbeit in Inhalte gesteckt hat.

Abänderung von Themen

Will man wenig Ärger und Aufwand haben, nimmt man ein Thema so wie es ist und nutzt maximal die vorgegebenen Konfigurationsmöglichkeiten.
Man hat jedoch die Möglichkeit, jeden Aspekt eines Themas mit eigener Funktionalität zu ersetzen - Hugo schaut zuerst, ob man eigene Templates hat und wenn nicht verwendet es die des Themas. Durch Kopieren und Ändern von Teilen des Themas kann man dieses also noch weiter anpassen. Dabei sollte man sparsam vorgehen - es kann jederzeit Änderungen im Thema geben, die man gebrauchen kann - oder die zum Beispiel durch eine neue Hugo-Version notwendig werden. In einem solchen Fall muss man seine Änderungen unter Umständen anpassen oder erneut von Null an durchführen. Am besten ist es, ein einmal gewähltes Thema einfach für immer beizubehalten.

Installation von Hugo und eines Themas

Die Installation von hugo ist denkbar einfach- man kopiert einfach die ausführbare Datei hugo irgendwo hin, wo sie gut aufrufbar ist.

Auf der Kommandozeile gibt man folgendes ein, um eine neue Webseite zu erzeugen:

hugo new site www.meineseite.de

Hugo erzeugt daraufhin das Verzeichnis www.meineseite.de mit folgendem Inhalt:

archetypes/ config.toml content/ data/ layouts/ static/ themes/

config.toml ist die Konfigurationsdatei für die neue Webseite. Unter content werden die Inhalte der Webseite abgelegt. static dient für Inhalte, die sich nicht ändern, z.B. Bilder. Unter themes wird das Thema abgelegt, das man benutzen möchte.

Bei den Themen ist in der Regel eine Beschreibung zu finden, wie man es installiert. In der Regel muss es nur heruntergeladen und im themes-Verzeichnis ausgepackt werden. Der Download verweist meistens auf ein git-Repository auf github.com - dort kann man das Thema dann über den grünen Button mit der Aufschrift Clone or download herunterladen. Bei der Auswahl dann einfach Download ZIP anklicken.

Das Auspacken des Themas kann über den Windows-Explorer oder den Finder (Mac) gemacht werden oder man benutzt die Kommandozeile. Hier das Beispiel für das von mir genutzte Thema:

cd www.meineseite.de/themes/
unzip /Downloads/hugo-theme-bootstrap4-blog-master.zip

Anschließend kopiert man sich die Konfigurationsdatei der im Thema enthaltenen Beispiel-Webseite über seine eigene Konfigurationsdatei und passt sie an:

cd ..
cp themes/hugo-theme-bootstrap4-blog-master/exampleSite/config.toml .

Struktur der Inhalte

Bei mir geht es im Wesentlichen um die Blog-Einträge - diese liegen nach Jahr und Monat sortiert unterhalb des “content/post”-Verzeichnisses. Diese Sortierung ist nicht zwingend - Hugo schreibt hier keinerlei Form vor. Ich finde bei einem Blog die Sortierung nach Jahr und Monat sinnvoll.

Hier die Struktur meines content/post-Verzeichnisses (Auszug):

cd content/post
ls -F
2014/ 2015/ 2016/ 2017/
ls -F 2017
01/ 02/ 03/ 05/ 06/ 07/ 08/
ls -F 2017/08
jamstack-und-mein-blog-teil1.md photoshoot-svenja_und_michelle.md
jamstack-und-mein-blog-teil2.md picked.md

Die eigentlichen Artikel sind reine Textdateien. Sie bestehen aus einem Kopf mit sogenannten Meta-Informationen und dem eigentlichen Inhalt.

Der Kopf heißt bei Hugo frontmatter.

Hier ein Beispiel:


+++
title = "JAMstack und mein Blog (Teil 2)"
date = "2017-08-24T10:45:49+01:00"
description = "Ich erkläre die Technik, die hinter meinem Blog steht."

categories = [ "Allgemeines", ]
tags = [ "technik", "web", "hugo", "git", ]

url = "/2017/08/jamstack-und-mein-blog-teil2/"
+++

Der Inhalt, der auf diesen Kopf folgt, ist absolut einfach aufgebaut:


{{<responsive_image1 alt="JamStack" file="/img/2017/08/JamStack-1"
    type="jpg" height="200">}}

Ich habe lange Zeit an der Technik meines Blogs gefeilt. Inzwischen
ist ein Stand erreicht, mit dem ich sehr zufrieden bin. Für Interessierte
hier die Beschreibung der technischen Hintergründe.

Artikel zwei von drei:  Generierung statischer Webseiten mit
   [Hugo](https://gohugo.io/)

<!--more-->

Übersicht
---------

* Teil 1: [Argumente gegen Wordpress](/2017/08/jamstack-und-mein-blog-teil1/)
* Teil 2: Statische Webseiten mit Hugo
* Teil 3: Hosting und Deployment

Interessant hieran ist die Zeile --more--, die wie ein HTML-Kommentar aufgebaut ist. Diese ist ein Trenner, mit dem man Hugo anzeigen kann, wo im Text die Vorschau (für die Artikelübersicht) abgebrochen wird. Man kann das auch Hugo selbst überlassen, ich ziehe es jedoch vor diesen Punkt selbst zu bestimmen.

Der Rest des Textes ist normale Markdown-Syntax, bis auf das responsive_image1. Das ist ein sogenannter Shortcode - eine sehr angenehme Sache, die Hugo anbietet.

Shortcodes

Die in Hugo eingebauten Shortcodes vereinfachen Dinge wie das Einbinden von Videos, das Zeigen von Quelltexten oder auch das Einblenden von Formularen.

Das Schöne ist: man kann seine eigenen Shortcodes definieren. Das oben gezeigte responsive_image1 habe ich mir selbst geschrieben und das generiert mit den obigen Parametern folgendes HTML:


<img src="../../../img/2017/08/JamStack-1-730.jpg" width="730" height="200"
  srcset="../../../img/2017/08/JamStack-1-730.jpg 730w, ../../../img/2017/08/JamStack-1-610.jpg 610w, ../../../img/2017/08/JamStack-1-450.jpg 450w, ../../../img/2017/08/JamStack-1-330.jpg 330w, ../../../img/2017/08/JamStack-1-298.jpg 298w"
  sizes="(min-width: 1201px) 730px, (min-width: 993px) 610px,
         (min-width: 769px) 450px, (min-width: 577px) 330px, 298px"
  heights="(min-width: 1201px) 200px, (min-width: 993px) 167px,
           (min-width: 769px) 123px, (min-width: 577px) 90px, 81px"
  alt="JamStack">

Über einen einzigen Shortcode kann ich also alle meine Bilder in einer Form ausliefern, die dem Browser die selbständige Auswahl der richtigen Bildgröße erlaubt.

Von den eingebauten Shortcodes habe ich bis jetzt nur den Youtube-Shortcode benutzt. Die Verwendung ist einfach:

{{< youtube l-_NYHkKdwQ >}}

Live-View

Hugo hat auch einen eingebauten Webserver, über den man sich seine Webseite lokal jederzeit ansehen kann und die vor allem auch bei jeder Änderung automatisch aktualisiert wird!

Einfach das Kommando hugo server eingeben und über den URL http://localhost:1313/ kann man seine Webseite betrachten. Vor Eingabe des Kommandos muss man in das Verzeichnis der Webseite wechseln, in unserem obigen Beispiel also in das Verzeichnis www.meineseite.de.

Achtung: Der Server-Modus erkennt nicht alle Fehler, die bei der Generierung passieren können.
Um Fehler zu erkennen, sollte man ab und zu eine “richtige” Generierung anstoßen. Dazu muss man nur das Kommando hugo ohne irgendwelche Parameter eingeben. Hugo gibt bei der Generierung eventuell Fehlermeldungen aus und bricht bei schweren Fehlern sogar die Generierung ganz ab. Wenn alles gut geht, findet man die generierte Webseite im Unterverzeichnis public.

Hier eine funktionierende Generierung:

                   |  DE   
+------------------+------+
  Pages            |  157  
  Paginator pages  |   52  
  Non-page files   |    0  
  Static files     | 3203  
  Processed images |    0  
  Aliases          |   40  
  Sitemaps         |    1  
  Cleaned          |    0  

Total in 4209 ms

Hier kann man sehen, dass Hugo schnell ist - es werden 157 Seiten in weniger als fünf Sekunden generiert, wobei über dreitausend Dateien angelegt werden.

Mein gewähltes Thema

Ich habe für mich das Hugo-Thema “Hugo Bootstrap v4 Blog” gewählt. Hier die Gründe:

Sauberer Code mit wenig Schnickschnack
Wie im ersten Artikel beschrieben hatte mein alter Blog eine Menge Zeug im HTML-Code, das zwar für ein schickes Aussehen sorgte aber die Ladezeiten enorm erhöhte. Mit dem bootstrap-v4-Thema existiert dieses Problem nicht. Der HTML-Code ist einfach und es werden nur ganz wenige externe Ressourcen nachgeladen. Das kommt der Ladegeschwindigkeit und der Benutzbarkeit auf Mobilgeräten zugute.
Selbst der benutzte Font wird nicht geladen, sondern die systemeigenen Fonts des Browsers benutzt.
Basiert auf Bootstrap
Bootstrap ist ein Framework, das den Aufbau von Webseiten unterstützt, die flexibel ihre Darstellung ändern. Der Schwerpunkt liegt dabei auf der Unterstützung mobiler Geräte. Das Hugo-Thema ist eigentlich ein Bootstrap-Thema, das für Hugo umgesetzt wurde.
Mit Bootstrap als Basis ist mein Blog gut gerüstet für das mobile Zeitalter.
Klares Design
Ich mag einfache Dinge - das Design dieses Themas ist einfach und klar.
Simple Navigation
Die Navigation dieses Blogs ist einfach, aber ausreichend. Keine komplizierten Menüs, in denen sich die Nutzer verlieren.

Zusammenfassung und Ausblick

Hugo ist ein mächtiger und schneller Webseiten-Generator, der durch die vielen vorhandenen Themen und die einfache Installation auch für Nicht-Programmierer geeignet ist.

Ich hoffe, ich konnte Ihnen Hugo schmackhaft machen.

Im nächsten Artikel wird es um die Verwaltung der Konfiguration und der Inhalte, Zusammenarbeit mit mehreren Autoren und um das (kostenlose) Hosting gehen.

Schauen Sie wieder rein!

Noch keine Kommentare - wollen Sie den ersten schreiben?