Dazu gab es Varianten der beiden Datei-Formate in unterschiedlichen Auflösungen, sodass ein Browser selbst entscheiden konnte, welches Format in welcher Auflösung er je nach Bildschirmgröße herunterlädt und verwendet.

Für jedes in einem Blogbeitrag verwendete Foto gab es einen Mix aus diesen Dateien:

• Das Originalfoto (das jeweils andere Format wurde automatisch generiert)

  • foto1.webp (960 KiB)
  • foto1.jpg ( 1100 KiB)

• Und zusätzlich die Bildvarianten in verschiedenen Auflösungen (1933 KiB):

  • foto1-360px.webp (43 KiB)
  • foto1-360px.jpg (48 KiB)
  • foto1-500px.webp (75 KiB)
  • foto1-500px.jpg (84 KiB)
  • foto1-816px.webp (159 KiB)
  • foto1-816px.jpg (195 KiB)
  • foto1-1632px.webp (617 KiB)
  • foto1-1632px.jpg (712 KiB)

Da JPG bei gleicher Qualität deutlich größer ist als WebP, wurde die Datenmenge für jedes Foto durch die Bildvarianten mehr als verdoppelt.

Wenig Nutzen, viel Speicherplatz und Rechenleistung fürs Rendern

Das war damals von der Idee gut und auch sicher, da es vielleicht noch veraltete Systeme und Browser gibt, die das WebP-Format nicht unterstützen. Aber der Nachteil war, dass dadurch sehr viele Dateien erzeugt wurden, die für die große Mehrheit der Clienten unnötig waren, die aber trotzdem Rechenpower und Speicherplatz beim Generieren benötigen.

Neu – sparsam fürs Rendern und Arbeiten mit dem, was da ist

Nun habe ich die Implementierung geändert:

• Hat das Originalfoto ein anderes Format als WebP, dann wird es nicht mehr in der selben Auflösung im WebP-Format generiert sondern es wird das Original genutzt.
• Das Fallback mit dem JPG-Format gibt es gar nicht mehr. Wer noch so einen alten Browser verwendet, muss damit leider leben.

Es werden jetzt nur noch die zusätzlichen Bildvarianten mit kleineren Auflösungen ausschließlich im WebP-Format generiert:

• foto1-360px.webp
• foto1-500px.webp
• foto1-816px.webp
• foto1-1632px.webp

Das ergibt dann nur noch 894 KiB an zusätzlichen Bilddateien statt bisher 1933 KiB. Bei einem anderen Blogbeitrag mit vielen Fotografien werden nach der Neuerung nur noch 7 MiB an zusätzlichen Dateien erzeugt, zuvor waren es 17 MiB.

Das Verzeichnis resources/_gen des Blogs war vor der Änderung 3300 MiB groß. Nach der Änderung sind es nur noch 1492 MiB.

Das passt so erst einmal. 😊

Render Hook herunterladen

Hier kannst du beide Dateien des Render Hooks herunterladen:

• figure.html
• render-image.html

Das .txt am Ende muss entfernt werden.

Suche beschleunigt

Die schönste Änderung ist die Suche, die jetzt sehr schnell Ergebnisse liefert. Zuvor dauerte die Suche je nach Stärke der Client-CPU von vielen Sekunden bis “Browser will Tab schließen” und die Suchergebnisse ließen auch zu Wünschen übrig.

Jetzt dauert es nur noch eine bis wenige Sekunden.

Ich habe dazu einen eigenen Blogbeitrag geschrieben, siehe hier.

Sortierte Tags und Kategorien

Die Listen der Kategorien und Tags in Blogbeiträgen ist jetzt alphabetisch sortiert. Das hat der Entwickler nach meiner Anfrage in sein Theme implementiert, da es ursprünglich unsortiert war bzw. in der selben Reihenfolge angezeigt wurde, wie es auch im Front Matter eingetragen war.

Alphabetisch sortiert ist jetzt die Voreinstellung. Man kann aber auch auch in der config.toml im Bereich [params] einstellen, sodass nach Häufigkeit sortiert wird:

taxonomySortingMethod = "popularity"

So sieht es jetzt aus (früher war es “unsortiert”):

WebP als Standard

Da jetzt immer automatisch Bildvarianten auch in JPG erstellt werden, habe ich meine Programme so eingestellt, dass Bilddateien immer im WebP-Format abgespeichert werden. Das betrifft Screenshots, ImagePipe auf Android und mein Script, das automatisch Bilder für den Blog aufbereitet.

Rand um Bilder

Vri hat den Rand um Bilder herum verschönert.

Früher:

Jetzt:

Inhaltsverzeichnis inline

Das Inhaltsverzeichnis befindet sich nicht mehr rechts in der Sidebar sondern immer ganz oben im Blogbeitrag. Es wird ein details-Element verwendet, da aber per Voreinstellung offen ist. Hintergrund ist die Darstellung auf mobilen Geräten, da dort das Inhaltsverzeichnis innerhalb der Sidebar erst ganz am Ende der Seite dargestellt wird. Mit der Änderung hat man auch auf Mobilteräten einfachen Zugriff auf das Inhaltsverzeichnis.

Seit der Umstellung finde ich es auch angenehmer, dass man direkt am Anfang des Blogbeitrags kurz überblicken kann, um was es geht. Selbst auf einem großen Bildschirm auf dem Desktop war das bisher nicht gegeben, weil man eher nicht nach rechts in die Sidebar geschaut hat.

Render Hook für Bilder angepasst

Keine automatische Verlinkung des Originals

Mein Render Hook für Bilder verlinkt nicht mehr automatisch zum Originalbild, falls dieses breiter ist als 1000 Pixel. Das war sowieso nie intuitiv und weit weg von dem, was Markdown normalerweise macht. Man will schließlich selbst entscheiden, ob etwas verlinkt werden soll und wohin.

Für eine einzelne Seite bekommt man das alte Verhalten zurück, indem man im Front Matter imageAutoLink: true einfügt. Das mache ich bei Blogbeiträgen, bei denen ich hoch aufgelöste Bilder eingefügt hatte und von diesem Verhalten ausging. Erst ab heute werde ich solche Bilder manuell verlinken.

Zudem es jetzt auch wieder möglich, mit der Markdown-Syntax ein Bild selbst irgendwohin zu verlinken, optional auch auf das hochaufgelöste Originalbild. Soll so Link auf das Originalbild eingefügt werden, so kann man diese Syntax verwenden:

[![](bild.jpg)](bild.jpg)

Das ist aber nur sinnvoll für Bilder ohne Beschreibungstext drunter, da dieser sonst auch als Link gerendert wird.

So langsam erschließt sich mir, weshalb die Leute von Hugo das so implementiert haben, dass alles, was mehr benötigt, als nur Bilder ganz einfach einzubinden, per figure-Shortcode gemacht wird.

Oder ein Bild mit Verlinkung auf eine URL

[![](bild.jpg)](/lala)

Angabe von Breite und Höhe

Mit dem Render Hook eingebundene erhalten jetzt auch eine passende Breiten- und Höhenangabe im HTML-Code, damit der Text dahinter beim Laden von Bildern mit einer langsamen Internetanbindung nicht mehr nach unten springt, sobald das Bild geladen wurde.

Bei Galerien passiert das aber noch immer, weil dafür ein Shortcode verwendet wird, der von einem größeren Projekt stammt und den ich nicht so einfach mal anpassen möchte.

Neuer figure Shortcode

Ich habe einen neuen Shortcode figure erstellt, der auf dem aktuellen Render Hook basiert (siehe oben).

Dadurch werden, wie auch im Render Hook, nur dann kleine Bildvarianten erstellt, wenn das Originalbild größer als 816 Pixel ist. So gibt es keine vermatschten Bilder mehr, die dadurch entstehen, dass ein kleines Bild vergrößert wird.

Zusätzlich erlaubt der Shortcode die Verwendung von Markdown für den Parameter caption (wie auch beim builtin Shortcode figure), sodass es z. B. möglich wird, einen Link auf eine Lizenz zu setzen, wie das von OpenStreetMap bei Einbindung deren Karten gefordert wird.

Beispiel mit einem Link in der Beschreibung (“caption”):

{{< figure src="2022-05-03-inline-inhaltsverzeichnis.webp" link=""
alt="" title="Ein Titel" width="350"
caption="Eine Caption mit URL wegen Copyright by [Natenom](/)" >}}

Ergebnis:

Ich werde die anderen Parameter, die im builtin-Shortcode figure von Hugo möglich sind, in Zukunft auch noch implementieren, wenn ich sie benötige.

Die Rückmeldungen

Die Rückmeldungen sind im Einzelnen aufgelistet…

Mehr Monitor

• Wenn jemand einen 4k Monitor hat, dann freut er sich über Bilder, die höher aufgelöst sind als nur 816 Pixel in der Breite.

Meine Lösung: Wenn das Originalbild breiter ist als 1632 Pixel, dann wird zusätzlich noch ein hoch aufgelöstes Bild erzeugt mit 1632 Pixel Breite. In meinem Blog trifft das z. B. auf einzelne Fotos oder Panoramabilder zu, die mindestens 2000 Pixel breit sind.

WebP und JPG

• Hugo kann man anweisen, die Varianten des Originalbilds immer als WebP zu erzeugen, auch wenn das Original ein anderes Format hat.
• Safari auf Mac OS kann noch nicht mit WebP umgehen. Korrektur: Nur Safari auf alten Mac OS Systemen kann kein WebP. Es hängt wohl vom Betriebssystem ab und das aktuelle Mac OS kann WebP.

Lösung: Für alle Bilder werden jetzt kleine Bildvarianten in den Formaten JPG und WebP erzeugt. Beide Dateiformate werden zur Verfügung gestellt. WebP ist der Standard und JPG das Fallback (z. B. für Safari und Mac OS).

4k “simulieren”

Im Browser auf 200 % zoomen, dann bekommt man auch die große Bildvariante geliefert, wenn sie vorhanden ist, siehe nächster Abschnitt.

Wie der neue Render Hook arbeitet

Und aus all den Vorschlägen und viel Arbeit ist nun das neue Render Hook entstanden, das wie folgt arbeitet (und damit etwas anders als bisher):

• Ist das Originalbild eine .webp-Datei, dann wird dieses konvertiert und eine .jpg-Datei erzeugt, sodass beide Formate vorliegen.
• Ist das Originalbild eine .jpg-Datei, dann wird dieses konvertiert und eine .webp-Datei erzeugt, sodass beide Formate vorliegen.
• Ist das Originalbild eine andere von Hugo unterstützte Datei, dann wird diese konvertiert und sowohl eine .webp- als auch in eine .jpg-Datei erzeugt, sodass beide Formate vorliegen.
• Ist das Originalbild 816 Pixel breit oder breiter, dann wird ein srcset erzeugt für die Breiten 360, 500, 816 und optional bei Bildern über 1632 Pixeln noch zusätzlich 1632 Pixel Breite.
• Ist das Originalbild kleiner als 816 Pixel, dann wird nur das Originalbild ohne srcset in der Seite eingebunden und es findet keine Verlinkung statt und es werden keine kleinen Bildvarianten erzeugt.
• Ist das Originalbild breiter als 1000 Pixel, dann wird um die einbegundene verkleinerte Variante herum ein Link auf das Originalbild gesetzt.
• In allen Fällen wird das Bild per picture-Element eingebunden. Dieses enthält immer als Voreinstellung per source-Element (Dokumentation) alle Bildgrößen im .webp-Format und als Fallback im img-Element alle Bildgrößen im .jpg-Format.
• Liegt das Bild nicht im Page Bundle, dann wird es ohne irgendwelche Zusätze per img-Element eingebunden.
• Bilder werden immer per Lazy loading eingebunden.

Vorteile der neuen Variante des Render Hooks

Ich kann für die Originalbilder alle Formate verwenden, die Hugo konvertieren kann. Das sind bmp, gif, jpeg, jpg, png, tif, tiff, webp. Alle kleinen Bildvarianten werden jedoch im JPG- und WebP-Format zur Verfügung gestellt.

Beispiele

So sieht es z. B. aus, wenn das Originalbild eine circa 5000 Pixel breites WebP-Datei ist (Pfade und Dateinamen auf das Wesentliche gekürzt):

<figure class="image-caption">
    <a href="lala.webp">
        <picture>
            <source type="image/webp"
                srcset="360x.webp 360w,500x.webp 500w,816x.webp 816w, 1632x.webp 1632w"
                sizes="(max-width: 424px) 360px, (max-width: 596px) 500px, (min-width: 565px) 816px,(min-width: 1200px) 1632px"
            />
            <img alt="lala"
                    srcset="360x.jpg 360w, 500x.jpg 500w, 816x.jpg 816w, 1632x.jpg 1632w,"
                    sizes="(max-width: 424px) 360px, (max-width: 596px) 500px, (min-width: 565px) 816px,(min-width: 1200px) 1632px"
                    src="1632x.jpg" title="lala" loading="lazy" />
        </picture>
    </a>
    <figcaption>lala</figcaption>
</figure>

Und so sieht es aus, wenn die Datei schmaler als 816 Pixel ist:

<figure class="image-caption">
    <picture><source type="image/webp" srcset="330x.webp" />
    <img alt="lala" src="lala.jpg" title="lala" loading="lazy" /></picture>
    <figcaption>lala</figcaption>
</figure>

Unschöne Platzverschwendung

Entweder liegt es an meiner Unfähigkeit oder an Hugo, dass Bildvarianten, die gar nicht verwendet werden und in irgendwelchen If-Bedingungen im Render Hook stehen und gar nicht erfüllt werden, trotzdem jedes Mal erzeugt werden. Stört mich nicht sehr, da sie niemals ausgeliefert werden, aber sie sind da und belegen Speicherplatz. Vielleicht kann ich das in Zukunft noch lösen.

Laut Dokumentation sollte meinem Verständnis nach das Bild erst dann generiert werden, wenn einer dieser “Befehle” auf das Bild ausgeführt wird: Permalink, RelPermalink, Width, Height.

Im Render Hook reicht aber schon so eine Zeile aus, um das Bild zu generieren:

{{- $img_webp := $img.Resize "600x webp" -}}

Wer darüber etwas weiß, darf sich gerne melden. 🙂

Verbesserungen?

Vielleicht wäre es sinnvoller, immer auf die konvertierte jpg-Datei zu verlinken. Oder auf die webp-Datei? Kann man das irgendwie so in HTML einbinden, dass sich der Browser je nach Fähigkeit selbst aussuche, welchen Link zu welchem Ziel er wählt?

Nützliches zum Picture-Tag

• Antwort auf die Frage, ob man ein picture-Element in ein figure-Element stecken darf, siehe hier. Spoiler: Definitiv. Und hier zur weiteren Lektüre dazu.

Shortcode und Hook zum Herunterladen

• figure.html
• render-image.html

Das .txt am Ende muss entfernt werden.

Bilder in Hugo

Es gibt verschiedene Möglichkeiten zur Einbindung von Bildern in Hugo.

• Standard-Markdown-Syntax
• Render Hook
• Theme-Erweiterungen
• Shortcode

Standard-Markdown-Syntax – Tut, kann aber nix

Die Standard-Markdown-Syntax, die Hugo von sich aus unterstützt, funktioniert zwar, kann dafür aber nichts:

![Alt Text](/pfad/zu-datei.jpg)

Das bedeutet konkret:

• Keine Möglichkeit zur Angabe, wie groß das Bild dargestellt wird, es wird immer maximal groß angezeigt.
• Es werden keine kleineren Bildvarianten erstellt. Ist ein Bild z. B. 10 MiB groß, 2000 Pixel breit und beträgt der zur Verfügung stehende Platz im Blog nur 800 Pixel in der Breite, so wird trotzdem das Originalbild mit 2000 Pixeln eingebunden, nur eben verkleinert und man muss 10 MiB herunterladen.

Render Hook

Für einen Render Hook erstellt man die Datei layouts/_default/_markup/render-image.html.

Hier kann man Programmcode hinterlegen, der ausgeführt wird, sobald die Standard-Markdown-Syntax für die Einbindung von Bildern gerendert wird.

Dies hat den Vorteil, dass man im Gegensatz zu einem Shortcode beim Standard-Markdown bleiben oder diesen auch erweitern kann.

Theme-Erweiterungen

Das hier im Blog verwendete Theme ‘Bootstrap’ stellt einige Möglichkeiten zum Einbinden von Bildern bereit. So kann man z. B. Bilder verkleinert anzeigen lassen und dafür wird auch wirklich eine kleinere Variante des Originalbildes erzeugt (wenn das Bild Teil des Page Bundles ist).

Es kann eine erweitere Standard-Markdown-Syntax verwendet werden, wie z. B.

![Alt Text](pfad/zu-datei.jpg?height=200px)

Letztlich wird das üer einen Render Hook ermöglicht, siehe oben.

Shortcode

Es gibt im Netz verschiedene Lösungen in Form von Shortcodes, die z. B. automatisch kleinere Varianten der Bilder erstellen und diese einbinden statt des Originals und es auch ermöglichen, einen Link auf das Originalbild zu setzen, einen Text unter dem Bild anzuzeigen und mehr.

Solch einen Shortcode hatte ich bis vor kurzem auch verwendet. Jedoch muss man für Shortcodes eine andere Syntax verwenden, z. B. für den Shortcode bildeinbinden:

{{​< bildeinbinden src="" link="" alt="" title="" width="" >​}}

So nah am Standard, wie möglich

Ich bevorzuge die Verwendung von gegebenen Standards statt einer eigenen Lösung. Denn so werden Probleme beim Wechsel eines Themes oder auch beim Export minimiert.

So verwende ich lieber die Standard-Markdown-Syntax für das Einbinden von Bildern in Hugo statt eines eigenen Shortcodes, dessen Parameter man sich mehr oder weniger merken muss. Zudem ist es für neue Menschen leichter.

Deshalb habe ich mich hier im Blog für einen Render Hook entschieden, um Bilder einzubinden.

Der eigene Render Hook

Als Ausgangspunkt habe ich diese Version hier verwendet und für meine Anforderungen angepasst.

Die Syntax ist die selbe wie in Hugo:

![Alt-Text](bild-200px.jpg "Titel")

z. B.

![Ein Demobild mit Radfahrenden, um zu verdeutlichen, wie ein Bild mit dem eigenen Render Hook eingebunden wird. ](bild-200px.jpg "Radfahrende in Pforzheim")

Im Ergebnis das 200 Pixel breite Bild, das nicht automatisch verlinkt wird, weil es zu klein ist:

Und hier ein Beispiel eines Bildes, das 2000 Pixel breit ist und deshalb automatisch zum Originalbild verlinkt, während automatisch eine erzeugte kleinere Variante (800 Pixel breit) des Originalbildes hier eingebunden wird.

Aus:

![Fahrrad auf einem Feldweg und mit einem 'Vorsicht Kinder' Schild auf dem Gepäckträger](bild-gross.jpg "Das Schild habe ich zuvor am Straßenrand gefunden.")

Wird:

Man kann jedoch sowohl den Alt-Text als auch den Titel weglassen.

Quelltext

Hier der fertige Render Hook layouts/_default/_markup/render-image.html:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

{{ $autolinking := .Page.Param "imageAutoLink" | default true }}
{{- $img := .Page.Resources.GetMatch .Destination -}}
{{- if and (not $img) .Page.File -}}
{{ $path := path.Join .Page.File.Dir .Destination }}
{{- $img = resources.Get $path -}}
{{- end -}}
{{- with $img -}}
{{- $large := $img.Resize "816x" -}}
{{- $medium := $img.Resize "500x" -}}
{{- $small := $img.Resize "360x" -}}
<figure class="image-caption">
{{ if gt $img.Width 816 }}
	{{ if and (gt $img.Width 1000) (eq $autolinking true ) }}<a href="{{- $img.RelPermalink -}}">{{ end }}
    <img alt="{{ $.Text }}" srcset="
        {{ $small.RelPermalink }} 360w,
        {{ $medium.RelPermalink }} 500w,
        {{ $large.RelPermalink }} 816w" sizes="(max-width: 424px) 360px,(max-width: 596px) 500px,(min-width: 565px) 816px" src="{{ $small.RelPermalink }}" title="{{ $.Title }}" loading="lazy" />
    {{ if and (gt $img.Width 1000) (eq $autolinking true ) }}</a>{{ end }}
{{ else }}
    <img alt="{{ $.Text }}" src="{{ $img.RelPermalink }}" loading="lazy" title="{{ $.Title }}" />
{{ end }}
    <figcaption>{{ with $.Title | safeHTML }}{{ . }}{{ end }}</figcaption>
</figure>
{{- else -}}
<img src="{{ .Destination | safeURL }}" alt="{{ $.Text }}" title="{{ $.Title }}" loading="lazy" />{{- end -}}
<!-- adapted from https://github.com/bep/portable-hugo-links/blob/master/layouts/_default/_markup/render-image.html -->

Wie der neue Render Hook funktioniert

Und so funktioniert der neu erstellte Render Hook render-image.html:

• Bild ist breiter als 816 Pixel¹:
  • Es werden automatisch kleinere Bildvarianten erstellt und via srcset eingebunden.
• Bild ist schmaler als 816 Pixel:
  • Es werden keine kleineren/größeren Bildvarianten erstellt und auf ein srcset wird verzichtet, es wird nur das Originalbild eingebunden. (Man könnte noch implementieren, dass in letzterem Fall nur die Bildvarianten erstellt werden, die kleiner als 816 Pixel sind. Aber das spare ich mir, da das nur selten vorkommt und das meistens Dateien mit sehr geringen Dateigrößen sind.)
  • Hierdurch wird ein sehr kleines Bild wirklich nur so groß angezeigt, wie es auch ist, nicht vergrößert und matschig.
• Bild ist breiter als 1000 Pixel:
  • Es wird automatisch ein Link auf das Originalbild gesetzt. Das Verlinken kann man unterbinden mit imageAutoLink: false im Front Matter eines Blogbeitrags.
• Der angegebene Titel wird unter dem Bild angezeigt.
• Der angegebene Alt-Text in eckigen Klammern wird in das alt-Attribut eingefügt.
• Die Bilder werden per Lazy loading eingebunden, sodass der Browser sie erst herunterlädt, wenn sie in der Nähe des Sichtbereits im Browser sind. Das spart Ressourcen, falls man nur einen Teil eines Beitrags liest.
• Es werden kleine Bildvarianten mit 500 und 360 Pixeln Breite erstellt. Diese sind für die kleineren Ansichten im Blog notwendig, z. B. auf Mobilgeräten.

Ideen für später

• Es wäre schön, wenn die Beschreibung aus den Exif-Tags verwendet werden könnte, sofern man keine eigene Beschreibung in Markdown einträgt. Ein Beispiel einer Umsetzung gibt es hier.
• Angabe von selbst festgelegter Breite für das Einbinden eines Bildes, wie z. B. hier beschrieben oder auch im hier im Blog verwendeten Theme.

Uffbasse (Aufpassen) – Besser kein srcset bei kleinen Bildern

Man kann Hugo anweisen, kleinere Bildvarianten des Originalbildes zu erstellen, die man dann statt des Originalbildes verwenden kann. Alternativ kann man daraus ein srcset erstellen, sodass der Browser automatisch die passende Größe aussuchen und herunterladen kann.

Jedoch ist dieser Mechanismus der Erstellung von Bildvarianten in Hugo ziemlich “dumm”. Wenn z. B. das Bild nur 200 Pixel breit ist, werden angeforderte größere Bildvarianten trotzdem erstellt und das resultiert dann in einem total zermatschten größeren Bild.

In diesem Screenshot wird das deutlich sichtbar. Das Originalbild (200 Pixel breit) und darunter das Bild, das von Hugo auf Anfrage in 800 Pixel Breite erzeugt wurde, obwohl das Originalbild kleiner ist:

Jedoch kann man in Hugo per .Width die Breite eines Bildes abfragen und nur dann weitere Bildvarianten erstellen lassen, wenn eine Mindestbreite gegeben ist und bei zu kleinen Bildern auf srcset verzichten.

Passt

Ich bin mit der neuen Lösung erst einmal zufrieden. Ich kann die Standard-Markdown-Syntax verwenden, es wird automatisch ein srcset eingefügt und große Bilder werden automatisch zum Originalbild verlinkt. Und zusätzlich werde ich auch noch daran erinnert, einen passenden Alt-Text zu schreiben.