Schlanke, responsive Bilder — mit MozJPEG, WebP, AVIF & SQIP

Seit dem Relaunch unserer Website im März 2020 nutzen wir an vielen Stellen responsive Bilder, um den unterschiedlichen Endgeräten — Smartphones, Tablets, Desktop- und anderen Computern — angepasste Bildabmessungen und spezialisierte Dateiformate auszuliefern. Dass Chrome als erster Browser nun das neue AVIF-Bildformat unterstützt, nehmen wir zum Anlass für einen genaueren Blick unter die Haube.

Bilder sind bekanntlich für einen Großteil des Internet-Traffics verantwortlich — laut HTTP Archive machen sie derzeit etwa 50% der durchschnittlichen Website aus. Traffic kostet Ressourcen, und nicht zuletzt unsere Zeit und Geduld. Es macht deshalb Sinn, sich intensiv mit Bildern auseinanderzusetzen und dafür zu sorgen, dass sie so kompakt und bedarfsgerecht wie möglich übertragen werden.

Mit dem HTML-Element <picture> steht eine vielseitige Technik zur Verfügung, um unterschiedlichsten Szenarien gerecht zu werden. Wir zeigen, wie wir das <picture>-Element auf der Tollwerk-Website einsetzen und damit gleich mehrere Aufgaben lösen. Der Einsatz des <picture>-Elements kann schnell komplex werden — wir beschränken uns hier jedoch bewusst auf die einsteigerfreundlichen Grundlagen.

Zunächst ist zu bemerken, dass im Kern der Bildumsetzung ein konventionelles <img>-Element als Standardbild hinterliegt. Ältere Browser, die das <picture>-Element nicht unterstützen, ignorieren sowohl <picture>, als auch <source> und fallen auf das Standardbild zurück. In dem Fall kann kein Rückschluss auf die Darstellungsgröße gezogen werden und es muss die maximal große Bildvariante an den Browser übertragen werden, um zuverlässig für eine ansehnliche Darstellung zu sorgen. Das Standardbild ist zudem mit einem Alternativtext (alt-Attribut) versehen, so dass Screenreadern und anderen assistiven Technologien ein barrierefreier Umgang mit dem Bild möglich ist.

Für modernere Browser definieren die vier <source>-Elemente unterschiedliche Bildvarianten und knüpfen diese über das media-Attribut an eine Bedingung, die erfüllt sein muss, damit die jeweilige Variante zum Einsatz kommt. Die Schreibweise der Bedingungen entspricht den Media Expressions bei CSS Media Queries: Im Beispiel sind es bestimmte Mindest- und / oder Höchstbreiten, die das Browserfenster einhalten muss. Um zu entscheiden, welche Bildvariante dargestellt werden soll, durchläuft der Browser die <source>-Elemente ihrer Reihenfolge nach und wählt die erste, deren Bedingung erfüllt ist. Das sizes-Attribut der gewählten Variante steuert schließlich die genaue Darstellung: Im Beispiel nimmt das Bild stets 100% der verfügbaren Breite ein (100vw), keinesfalls aber mehr als 1200 Pixel.

Durch Einsatz des <picture>-Elements mit unterschiedlich großen Bildvarianten entscheidet also der Browser, welches das optimale Bild für die aktuelle Darstellung ist, und nur dieses Bild wird vom Server übertragen. Unnötige Übertragung zu großer Datenmengen wird vermieden.

Für die Kopfbilder auf unserer Startseite nutzen wir 4 unterschiedliche Seitenverhältnisse — 2:1, 4:3, 1:1 und 3:4 —, die je nach Fensterbreite zum Einsatz kommen. Auf Smartphone-Bildschirmen in Portrait-Ausrichtung wird ein hochformatiger Bildausschnitt gezeigt, während breite Bildschirme ein Querformat darstellen. Zusätzlich zum Seitenverhältnis unterscheiden sich die Bilder auch im Bildausschnitt.

Zur Ausschnitte nutzen wir den in TYPO3 integrierten Bildeditor und legen in einem annähernd quadratischen, zentral im System hinterlegten Originalbild die vier erforderlichen Ausschnitte fest (sogenannte Crop Variants). TYPO3 nutzt diese Angaben, um daraus automatisch die entsprechenden Einzelbilder zu erzeugen.

Das <picture>-Element hilft uns also weiterhin, indem es uns bedarfsgerechte Bildausschnitte ermöglicht — hier mehr ein inhaltlich-ästhetischer, denn ein technisch-funktionaler Gewinn.

Bei dieser Einsatzvariante stellen wir über die <source>-Elemente unterschiedliche Bildformate desselben Motivs zur Verfügung und zeigen das jeweilige Format über ein zusätzliches type-Attribut an. Die Reihenfolge ist dabei entscheidend: Browser wählen das erste unterstützte Format und laden nur dieses vom Server. Das in der Dateigröße kleinste Format, AVIF, steht deshalb an erster Stelle, gefolgt von WebP und schließlich JPEG als ultimativem Rückfall-Format für Browser, die weder AVIF noch WebP unterstützen. Die so realisierte Formatweiche lässt sich problemlos mit den oben dargestellten Techniken für unterschiedliche Bilddimensionen und -ausschnitte kombinieren.

Der Browser kümmert sich dann selbständig darum, dass ein derart markiertes Bild erst dann vom Server geladen wird, wenn es bereits im sichtbaren Bildschirmbereich liegt oder sich diesem dicht genug nähert. Auch auf diese Weise wird die initiale Datenübertragung auf ein Minimum beschränkt.

Möchte man denselben Effekt auch in Browsern realisieren, die natives Lazy Loading noch nicht unterstützen, muss man sich einer Technik bedienen, die auf JavaScript angewiesen ist. Dabei übernimmt ein Script die Überwachung des sichtbaren Bereichs und das automatische Nachladen von Bildern im Hintergrund, sobald diese kurz vor der Anzeige stehen. Damit die Bilder nicht schon vorzeitig vom Browser geladen werden, wird das src-Attribut des Bildes initial maskiert (zum Beispiel in data-src geändert) und erst bei Bedarf von JavaScript umgeschrieben:

Wir verzichten an dieser Stelle auf eine detaillierte Erläuterung des JavaScripts, das für unsere Webseite unter der Haube aktiv ist. Nur so viel: Wir nutzen die etablierte lazysizes-Bibliothek, die das Überwachen des Bildschirmbereichs und das Umschreiben des data-src-Attributs zu src übernimmt. Zuvor entscheidet ein von uns selbst entwickeltes Script, ob der Browser bereits natives Lazy Loading unterstützt. In dem Fall kann das data-src-Attribut umgehend umgeschrieben werden und die lazysizes-Bibliothek wird nicht benötigt. Im Quelltext nutzen wir daher die Kombination beider Welten:

Doch was passiert, wenn JavaScript einmal nicht zur Verfügung steht? Im Sinne des Progressive Enhancements haben wir für diesen Fall Vorkehrungen getroffen (stark verkürzt dargestellt):

Im Auslieferungszustand trägt das <html>-Element unserer Webseite die CSS-Klasse no-js, die in Kombination mit einer einfachen CSS-Regel dafür sorgt, dass alle Bilder, die mit loading="lazy" data-src="..." gekennzeichnet sind, generell ausgeblendet werden. Das CSS ist bewusst inline in den Kopfbereich der Seite integriert, um nicht eine zusätzliche Abhängigkeit zu einem externen CSS einzuführen. Jedes nachzuladende Bild wird im Quelltext durch eine normal zu ladende Variante ergänzt, die in einen <noscript>-Bereich eingeschlossen ist und demnach nur dann greift, wenn JavaScript nicht zur Verfügung steht. Nutzende ohne JavaScript laden also das reguläre Bild und bekommen von der nachzuladenden Variante nichts zu sehen. Steht im Browser jedoch JavaScript zur Verfügung, so wird als eine der ersten Maßnahmen die CSS-Klasse no-js zu has-js geändert. Das Inline-CSS greift nicht mehr, das nachzuladende Bild wird dargestellt und die JavaScript-freie Rückfall-Variante wird nicht genutzt.

Wer genau Acht gegeben hat, der hat in unserem letzten Beispiel ein Detail entdeckt, das im Allgemeinen nicht zulässig ist: Unserem nachzuladenden Bild fehlt das mandatorische src-Attribut! Wir schließen diese Lücke, indem wir eine letzte Verfeinerung integrieren und unserem Bild eine — in der Dateigröße sehr kleine — Vorschauvariante spendieren. Nutzende bekommen diese nur zu Gesicht, solange das nachzuladende Bild noch nicht vollständig übertragen wurde. Dazu wäre es möglich, eine sehr niedrig aufgelöste Version des Bildes zu nutzen:

Jedoch würden wir damit den Zweck der ganzen Übung verfehlen, denn dann würde ja doch sofort eine Datei vom Server abgerufen werden müssen. Um diesen expliziten Ladevorgang zu vermeiden, ist es möglich, das Vorschaubild mit Hilfe eines sogenannten Data-URL direkt in den HTML-Quelltext einzulagern:

Das Vorschaubild steht damit unmittelbar zusammen mit dem HTML-Dokument zur Verfügung und muss nicht mit einem zusätzlichen Request vom Server übertragen werden. Statt eines volumenmäßig vergleichsweise großen JPEGs nutzen wir für das Vorschaubild eine Technik, die erstmals 2017 von Tobias Baldauf unter der Bezeichnung SQIP vorgestellt wurde: Wir erzeugen von unserem Originalbild eine sehr abstrakte Version als vektorbasierte SVG-Grafik, die mit Weichzeichnungsfiltern so stark verfremdet wird, dass sie nur einen äußerst groben Eindruck vom Originalbild wiedergibt. Das Ergebnis ist in der Dateigröße so klein und kann zusammen mit dem HTML so effizient komprimiert werden, dass eine Übertragung als Inline-Bild realistisch ist.

Das hier dargestellte Vorschaubild ist gerade einmal 1,37 kB groß (unkomprimiert) und stimmt dennoch überzeugend auf das eigentliche Originalbild ein:

Zur Vereinfachung haben wir die Techniken zum Laden bei Bedarf mit einem einzelnen Bild statt einem komplexen <picture>-Element erläutert. Dass Lazy Loading aber auch mit den Methoden für unterschiedliche Bilddimensionen, -ausschnitte und -formate kombiniert werden kann, zeigt das unten stehende, abschließende Beispiel.

Ganz offensichtlich wäre es nicht zumutbar, die Pflege eines solchen Monsters manuell betreiben und redaktionell bewältigen zu wollen. Deshalb haben wir unserem TYPO3 beigebracht, <picture>-Elemente wie das dargestellte vollautomatisch und mit vertretbarem, redaktionellen Zutun zu generieren. Soviel vorweg: Unsere dafür zuständige TYPO3-Extension tw_base ist bislang nur sehr mäßig dokumentiert, aber immerhin Open Source und für alle Interessierten herunterzuladen. Welche Werkzeuge die Extension zur Erzeugung responsiver Bilder mit sich bringt, beschreiben die folgenden Abschnitte.

Die Argumente steuern unter anderem, welches Originalbild für die Erzeugung herangezogen wird und welche allgemeinen HTML-Attribute auf dem Bild platziert werden sollen. Es werden im System konfigurierte Breakpoints und die dazugehörigen srcset- und sizes -Parameter übergeben. Es wird bestimmt, ob Lazy Loading genutzt oder bestimmte Dateiformate ausgespart werden sollen. Es müssen nicht alle Argumente angegeben werden — auch einfachere Anwendungsfälle sind denkbar. Das Ergebnis des ViewHelper-Aufrufs ist die Ausgabe eines <picture>-Elements. Während der Aufbereitung werden die beteiligten Bildressourcen berechnet und im Dateisystem des Servers gespeichert.

Welche Bildformate am resultierenden <picture>-Element beteiligt sind, hängt maßgeblich davon ab, welche der folgenden Konverter und Kompressoren auf dem Server zur Verfügung stehen. Der ViewHelper nutzt deren Kommandozeilen-Schnittstellen, um die jeweiligen Formate zu erzeugen. Keine dieser Anwendungen zählt zur Standardinstallation eines einfachen Webservers — sie müssen vorab auf Betriebssystemebene installiert werden (je nach Serverumgebung stehen hierfür womöglich fertige Pakete zur Installation bereit).

Der ViewHelper optimiert die behandelten JPEGs in place — er tauscht also die Originalbilder gegen die optimierten Versionen aus. Mehrfaches Optimieren hat beim MozJPEG-Encoder keinen negativen Effekt, da er weder Qualität noch Kompatibilität der Bilder beeinflusst, sondern lediglich ihre interne Struktur optimiert.

Der quality-Parameter liegt zwischen 0 und 100 und entscheidet über den Kompressionsgrad (100 bedeutet verlustfrei). Wir können den Kompressionsgrad von TYPO3 aus einstellen und erzielen mit 80 derzeit zufriedenstellende Ergebnisse.

minundmax` beschreiben ein Qualitätsfenster, innerhalb dessen sich der Kompressionsgrad bewegen soll. Beide Werte liegen zwischen 0 (verlustfrei) und 63 — wir arbeiten aktuell mit 35 und 50. Insbesondere die Minimalkompression entscheidet über die Dateigröße und Qualität der resultierenden AVIF-Dateien.

Mit dem workers-Argument lässt sich die Anzahl von Teilprozessen festlegen, die der Encoder intern nutzt. Durch Erhöhung dieses Werts kann der Kodierungsvorgang auf mehrere Rechnerkerne verteilt und die benötigte Zeit damit spürbar verkürzt werden. Der Wert ist also hardwareabhängig zu wählen. In jedem Fall sollte man je nach Bilddimensionen mit mehreren Sekunden bis Minuten für die Konvertierung eines qualitativ hochwertigen Bilds rechnen.

Wer sich tiefergehend mit dem neuen AVIF-Format beschäftigen möchte, dem sei der ebenfalls soeben erschienene, englischsprachige Artikel unseres Freundes Matthias Ott empfohlen, oder die äußerst umfassenden Analysen von Jake Archibald.

Anschließend nutzen wir das Node-basierte SVGO, um die errechnete SVG-Vorschau in ihrer Dateigröße und Komplexität zu optimieren:

In einem letzten Arbeitsgang integriert unser PrimitiveLqipService schließlich einen <feGaussianBlur>-Filter in die SVG-Datei, so dass die abstrakten Polygone stark weichgezeichnet dargestellt werden. Die resultierende SVG-Datei wird in unseren HTML-Quelltext integriert und übernimmt die Aufgabe der Lazy-Loading-Vorschau.