Ladezeiten#

Schauen wir uns mal an, wie meine Seite mit Jekyll gegenüber Hugo lädt. Hierfür öffne ich die Entwickleroptionen (F12) in meinem Browser, wähle das Network-Tab an und klicke dort auf All. Anschließend lade ich die Seite neu.

Dabei entsteht die folgende Auflistung:

Image: A snapshot of my browser window with the blog's landing page opened. Developer options are activated, and the lower part of the image shows a table with the individual page content files, their size, and contribution to the load time. For hugo, it transfers a total of 189kB in 175ms.
Im Bild unten: Ladezeit meiner Landing Page mit Hugo

Zu erwähnen ist, dass ich hier eigentlich gar nicht Jekyll mit Hugo vergleiche, sondern lediglich deren Ausgabe und daher die gewählten Themes maßgeblich für Größe und Ladezeit verantwortlich sind. Also vergleiche ich praktisch das minimalmistakes theme in Jekyll mit dem terminal theme in Hugo. Hugo ist in diesem Falle etwa 10% schneller als Jekyll.

Image: A snapshot of my browser window with the blog's landing page opened. Developer options are activated, and the lower part of the image shows a table with the individual page content files, their size, and contribution to the load time. For jekyll, it transfers a total of 328kB in 306ms.
Im Bild unten: Ladezeit meiner Landing Page mit Jekyll

Größe#

Image: A cake diagram as the output of firefox's performance analysis tool in developer options. Analyzing the hugo's terminal theme on a typical blog post of mine, images make up for three quarters of total transferred size. The last quarter is largely taken by css, and just 12kB html at a total size of 165kB.

Ein anderes Diagramm erhalte ich, wenn ich ganz unten links auf die Stoppuhr klicke und damit eine performance analysis ausführe. Die Kuchendiagramme zeigen für meine Implementierung in Jekyll den größten Anteil in Bildern, gefolgt von CSS und JS. In Hugo geht JS gegen null, und auch der Anteil von CSS ist geschrumpft.

Die folgende Tabelle zeigt ein paar meiner Seiten im direkten Vergleich. Allerdings ist die Übersicht mit Vorsicht zu genießen: Die Werte ändern sich schon mal, wenn ich neu lade (auch mit ausgeschaltetem Cache). Gerade bei eingebundenen Inhalten Dritter wie meinen Videos kommen hier teils stark unterschiedliche Werte heraus. Insgesamt habe ich mit Hugo und Terminal deutliche Optimierungen vorliegen.

Itemminimal-mistakesterminal-schallbertJekyllHugo
transferred[kB]Diff [%]time[ms]Diff [%]
Landing163.4798.68-3930300
Post28611767-38340270-20
List page1507140-9030300
  • Manuell implementiert in Hugo hatte ich das bedingte Laden von Katex nur auf Seiten, wo mathematische Ausdrücke auftauchen (das spart oftmals 90kB min.css).
  • Mit Hugo habe ich kleinere CSS-Dateien. Es wird nur geladen, was ich auch wirklich verwende. Es gibt kaum noch Code, der nicht angefahren wird.
  • Automatisch in Hugo sind Medien-Vorschaudateien von den hochauflösenden Dateien abgeleitet und per Bildprozessor auf die Darstellungsverhältnisse im gebauten Zustand platzoptimiert. Diese Optimierung spart bei vielen, klein dargestellten Bildern eine Menge Bandbreite.
  • Das Terminal-Theme zeigt anders als minimalmistakes keine Kärtchen für “weitere Posts” an. Dies spart die Übertragung von vier Vorschaubildern.
  • In Hugo habe ich fast gar keine Javascript-Inhalte mehr - eines der Ziele, das ich mir gesteckt hatte.

Auslieferung/Continuous Deployment#

Für Jekyll gestaltete sich Bauen und Ausliefern in Gitea etwas hakelig: erst mit einem Jekyll-Dockerimage war ich in der Lage, ruby richtig aufzusetzen. Damit und weil ich meinen Actions nicht erlaube zu cachen dauert das Bauen ziemlich lang: Erst den aktuellen Docker-Container ziehen, ruby und jekyll updaten, gems installieren, die Quelldateien auschecken, anschließend bauen und ausliefern - hier vergehen selbst unter optimalen Bedingungen mehr als 90 Sekunden, bis ein neuer Artikel live ist.

Image: Gitea dashboard in the Actions tab. We see three successful workflow runs with a hugo full build & deploy of my site, taking 122sec, 138sec, and 160sec.

Für Hugo geht der ganze Prozess dank schnellerer Bauzeiten und vorgefertigter Container (siehe dazu mein Artikel zum Thema Continuous Deployment Pipeline mit Hugo in Docker) viel schneller vonstatten.

Image: Gitea dashboard in the Actions tab. We see three successful workflow runs with a hugo full build & deploy of my site, taking 12sec, 9sec, and 21sec.

Selbst im ungünstigsten Fall (siehe Build unten), z.B. nach einem Neustart des Runners nach Update und einer Änderung im Docker-Repository für meinen Hugo Container, bleibe ich weit unter 30 Sekunden.

Komplexität#

Ganz klar: Hugo ist hier im Vergleich zu Jekyll unschlagbar.

Da Themes in Hugo steckbare Module sind, benötigen sie keinen Abhängigkeitsbaum in Form von Gems wie bei Jekyll zum Nachladen und installieren. Entsprechend kann hier viel weniger kaputt gehen. Für mich lokal verringert sich die Bauzeit für einen “full build” (zweisprachig) um 75% und auch das automatische Bauen bei Veränderung meiner Markdown-Dateien ist sowohl 5x schneller als auch aussagekräftiger: Wenn ich in Jekyll nämlich “incremental build” einschalte, dann gibt es keine aktualisieren Paginator-Seiten mehr - sprich Listenansichten und Übersichtsseiten werden nicht mit gebaut.

Auf der anderen Seite kann ich in Jekyll sehr flexibel und feingranular selbst eingreifen, eigene Gems entwerfen und recht einfach besondere Gimmicks für meine Seite herstellen wie ein mitscrollendes Inhaltsverzeichnis. Jenes vermisse ich in Hugo etwas.

Fazit: Für die tagtägliche Benutzbarkeit gefällt mir Hugo ganz klar besser als Jekyll. - schallbert, Sep-2026