Im Zuge meiner Blogpost-Exzesse zum 39C3 habe ich zwischendurch auch zum ersten AVIF für Bilder verwendet. Dazu musste ich die Blogsoftware leicht anpassen (um automatisch die Bildgröße zu ermitteln), aber das ist nicht weiter wichtig.
Ich habe dabei ein bisschen herumexperimentiert, AVIF-Dateien mit Webp verglichen und so, und wollte noch etwas dazu schreiben. Da kommt es mir gerade recht, dass ein anderer enthusiastischer Bildformateamateur einen Blogpost über AVIF im Vergleich mit anderen Formaten geschrieben hat.
AVIF im Vergleich zu JPEG und Webp
In dem anderen Post war der Ansatz: ein unkomprimiertes Bild nehmen, es mit 10% Qualität als JPEG abspeichern, und dann mit anderen Bildformaten versuchen, eine vergleichbare Dateigröße zu erreichen. JPEG schneidet hier am schlechtesten ab, mit stark sichtbaren Artefakten (bei 10% kein Wunder). Webp sieht deutlich besser aus, zeigt aber gerade an Kanten unschöne Artefakte. AVIF sieht am besten aus, wenn man genau hinschaut, sieht man aber auch ein paar Artefakte. Der Autor hat auch noch andere Formate verglichen, aber die können bei mir im Browser nicht angezeigt werden, deswegen ignoriere ich sie erst einmal. Wichtig ist: Avif ist bei gleicher Größe deutlich besser als Webp.
Interessanterweise entspricht das nicht ganz meinen eigenen Erfahrungen. Ich bin aber auch weniger systematisch herangegangen. Ich habe Webp-Bilder und AVIF-Bilder mit 75% bzw. 50% Qualität (die Standardeinstellungen) erstellt. Die AVIF-Bilder waren i.d.R. ein kleines bisschen kleiner und ein kleines bisschen besser, wobei letzteres nur nach Augenschein war. Vielleicht lag es an der Art der Bildinhalte. Vielleicht an etwas anderem. Allgemein ist mir aufgefallen, dass bei AVIF die Artefakte eher wie ein Gaußfilter aussehen während Webp, ähnlich wie bei JPEG. Ich bin aber bei Weitem kein Experte in Bildkompression, insbesondere nicht bei Webp und AVIF.
Was verlustfreie Kompression anging, war AVIF deutlich hinter Webp hinterher. Zumindest dafür werde ich also in Zukunft auch Webp nehmen, bei verlustbehafteter Kompression werde ich noch herumprobieren
JPEG-XL
Ein weiteres Bildformat, das leider von aktuellen Browsern nicht gut unterstützt wird, ist JPEG-XL. Das Format hat eine bewegte Geschichte hinter sich. 2022 hat Google angekündigt, es nicht mehr unterstützen zu wollen (Maintenance-Kosten, und Bildformate parsen ist auch immer eine Stelle, an der leicht Sicherheitslücken passieren) und hat die experimentelle Unterstützung eingestellt. Mozilla ist mit Firefox nachgezogen, denn wenn Chrome ein Format nicht unterstützt, macht sich kaum ein Website-Betreiber die Mühe, das Format bereitzustellen.
Es gab dann in den entsprechenden Communities Proteste, es wurde ein Rust-basierter Decoder angekündigt, um die Sicherheitsrisiken kleinzuhalten und erst vor ein paar Tagen wurde in Chromium wieder der JPEG-XL-Suppoert hinzugefügt.
Ich bin mal gespannt auf dieses Format. Ich habe einige gute Dinge darüber gehört, aber mich noch nicht näher damit auseinandergesetzt. Ich werde vermutlich mal ein bisschen herumprobieren.
Content Negotiation
Was mir bei dem Thema auch wieder eingefallen ist: Ich habe einen ganzen Haufen alter Bilder auf diesem Blog. Viele PNG-Bilder, die als Webp noch deutlich kleiner sein könnten. Hier stehe ich jetzt vor einem kleinen Dilemma: Ich würde sie gerne ersetzen, aber die Dateiendung der Bilder ist Teil der URL. Wenn ich die nicht ändere, führt es bei Benutzern zu Verwirrung, die sich die Dateien vielleicht herunterladen. Wenn ich die ändere, habe ich kaputte URLs und Cool URIs don't change.
Der Fehler war natürlich, die Dateiendung überhaupt zum Teil der URL werden zu lassen. Sonst könnte ich jetzt im Hintergrund ohne Probleme das Dateiformat austauschen. Glücklicherweise gibt es in HTTP ja schon seit Ewigkeiten Content Negotiation: mittels des Accept-Headers kann man bei einer Anfrage angeben, welche Formate man unterstützt. Der Server liefert dann nur ein unterstütztes Format zurück. Das bräuchte ich auch für meinen Server.
So könnte ich zum Beispiel das alte und das neue Bild nebeneinander auf die Platte legen, mit unterschiedlichen Dateiendungen. Der Server sieht sie beide, und wenn die Datei ohne Endung angefordert wird, liefert der Server die kleinste Datei zurück, die unterstützt wird. In meinen Blogposts müsste ich dann die Pfade anpassen, aber das könnte ich vermutlich auch automatisch machen. Wenn eine Datei mit Endung angefordert wird, könnte er ja die konkrete Datei ausliefern. So gehen auch existierende Deeplinks nicht kaputt.
Damit kann ich auch das Problem mit unterstützten Bildformaten umgehen, indem ich zwei oder mehr verschiedene Formate ablege. Wenn jemand dann z.B. noch kein JPEG-XL unterstützt, wird halt Webp ausgeliefert oder so.
Die ganze Sache hat nur ein Problem: Ich habe noch nicht herausgefunden, wie ich das mit nginx mache, ohne mich komplett zu verrenken. Aber irgendwann…
PS: AVIF in og:images
Ich habe ja schon erwähnt, dass ich AVIF für einige Bilder während des 39C3 verwendet habe. Die habe ich dann auch in die og:image-Tags eingefügt. Die Unterstützung dafür lässt aber noch zu Wünschen übrig. Aber das ist vermutlich auch nur eine Frage der Zeit.