ICO in AVIF umwandeln

Wer eine Website nach dem Umweltzeichen Blauer Engel für ressourcenschonende Softwareprodukte ausrichtet, kennt das Grundprinzip: möglichst wenig übertragene Daten pro Seitenaufruf. Für Fotos ist das ein starkes Argument für AVIF. Für Icons ist es das Gegenteil, und diese Seite ist der Ort, an dem man das vor der Umstellung einer ganzen Bildpipeline nachprüfen sollte, statt es anzunehmen.

Der Grund liegt nicht an einer schlechten Implementierung, sondern an der Natur beider Dinge. AVIF ist gut in etwas, das ein Icon gar nicht hat, und diese Seite zeigt, was das in konkreten Byte-Zahlen bedeutet.

AVIF ist kein Bildformat, das zufällig gut komprimiert — es ist der Intra-Frame-Pfad des Videocodecs AV1 mit einem Container drumherum. Alles, worin es stark ist, folgt daraus. AV1 wurde darauf ausgelegt, den Inhalt eines Bildblocks aus seinen Nachbarn vorherzusagen und das Restsignal zu verwerfen, das ein bewegtes Auge ohnehin nicht bemerkt — eine ausgesprochen wirksame Strategie bei Fotos und bei Filmkorn.

Ein Icon hat von beidem nichts. Es besteht aus wenigen flächigen Bereichen mit harten Kanten und ein paar Dutzend geglätteten Pixeln entlang jeder Kante. Es gibt keine Textur zu modellieren, keinen Verlauf vorherzusagen und kaum ein Restsignal zu verwerfen — die Maschinerie, die AVIF bei einem Foto gewinnen lässt, hat hier fast nichts zu tun, während ihr fester Overhead bleibt.

An einer Testdatei mit 8.471 Byte und vier enthaltenen Größen, umgewandelt bei der Standardqualität 82: 1.737 Byte als PNG, 1.894 als GIF, 3.054 als WebP, 3.624 als AVIF und 4.005 als JPEG. Die Reihenfolge ist fast genau umgekehrt zu der, die derselbe Test an einem Foto ergeben würde.

Das ist kein kleiner Unterschied. Das AVIF ist mehr als doppelt so groß wie das PNG, und es ist die verlustbehaftete Variante. Bei zweihundert Icons in einem Verzeichnis fügt eine Umstellung auf AVIF der Website rund 380 Kilobyte hinzu, statt etwas einzusparen. Die Icons aus einer AVIF-Migration herauszunehmen und als PNG zu belassen, ist hier die konsequente Entscheidung — auch im Sinne des Grundgedankens hinter dem Umweltzeichen.

Transparenz überlebt: An der Testdatei liest der Eckpixel des entstehenden AVIF 0,0,0,0. Das ist bei einem effizienten Format nicht selbstverständlich — der GIF-Pfad dieser Website macht aus derselben Ecke undurchsichtiges Schwarz —, muss das Ergebnis also AVIF sein und ist die Markierung ein Freisteller, funktioniert wenigstens dieser Teil.

Erreicht wird das, indem der Alphakanal als zweite Ebene neben der Farbe kodiert wird, faktisch ein zweites kleines Bild im selben Behälter. Bei einem Foto geht dieser Overhead in der Datenmenge unter. Bei einem 256-Pixel-Icon, dessen ganze Datei wenige Kilobyte umfasst, ist er ein sichtbarer Anteil der Gesamtgröße und Teil der Erklärung für die obige Zahl.

Der AVIF-Encoder ist das größte WebAssembly-Modul, das diese Website ausliefert, und das langsamste in der Ausführung, weil das Kodieren eines Standbild-AVIF eine AV1-Intraframe-Suche bedeutet. Bei einer Datei ist das eine kurze Pause. Bei zweihundert Icons in einem Durchgang ist es eine spürbare Wartezeit — und es ist der eigene Prozessor, der sie leistet, nicht ein fremder Server.

Das lohnt sich gegen das Ergebnis in Byte aufzuwiegen, nicht getrennt davon. Echte Kodierzeit aufzuwenden, bei jedem Build, um am Ende jedes Icon doppelt so groß zu machen, ist in beide Richtungen ein schlechter Tausch.

Ein ICO enthält dasselbe Symbol in mehreren Größen, ein AVIF genau ein Bild — irgendetwas muss also wählen. Das übernimmt der Icon-Dekoder des Browsers, und er nimmt den größten Eintrag, geprüft mit einer Datei, die 16-, 32-, 48- und 256-Pixel-Zeichnungen in vier unterschiedlichen Farben enthielt und deren Verzeichnis in drei verschiedenen Reihenfolgen geschrieben wurde.

Die Obergrenze liegt bei 256 Pixeln, vorgegeben vom ICO-Format, nicht von AVIF, das bis 65.536 reicht. Die Eingabe für den Encoder ist also immer ein kleines Bild — genau die Bedingung, unter der jedes effiziente Format im Vergleich zu PNG am schlechtesten abschneidet.

AVIF kann zwölf Bit pro Kanal und einen erweiterten Farbraum speichern — ein echter Vorteil gegenüber WebP und JPEG bei Fotografie und HDR-Material. Eine Icon-Datei speichert acht Bit pro Kanal in einem Standardfarbraum und hat das immer getan.

Diese Fähigkeit ist also vorhanden und ungenutzt. Direkte Kosten entstehen dadurch nicht, aber es fasst das ganze Paar zutreffend zusammen: fast alles, worin AVIF besser ist, hat ein Icon gar nicht. Die eine Eigenschaft, die hier zählt — Alpha —, hatte PNG bereits.

Jeder aktuelle Browser dekodiert AVIF, seit mehreren Jahren. Für die meisten Websites reicht das, um es direkt auszuliefern. Es ist neuer als WebP, der Anteil an Besuchern ohne Unterstützung ist also größer, und die übliche Antwort ist ein picture-Element mit Rückfalloption statt eines direkten Ersatzes.

Für ein Icon bedeutet das: Statt einer Datei liefert man jetzt zwei aus, und die Rückfalloption ist das PNG, das ohnehin schon kleiner war. Der zusätzliche Aufwand ist real, die Ersparnis dabei negativ.

Eine pauschale Regel ist verlockend, weil sie zukünftigen Builds eine Entscheidung abnimmt, und pauschale Regeln zu Bildformaten liegen meistens richtig. Hier ist das der Fall, in dem sie es nicht tut. Die Regel nach Inhalt statt nach Verzeichnis aufteilen: Fotos und Screenshots zu AVIF, flache Grafik und Icons zu PNG — und die Begründung direkt neben der Regel notieren, damit sie nicht als Versehen „korrigiert" wird.

Kann eine Pipeline zwei Regeln tatsächlich nicht abbilden — manche CDN-Transformationen können das nicht —, ist die Umwandlung der Icons ein vertretbarer Preis für Einheitlichkeit. Nur sollte man wissen, dass es einer ist, und ungefähr wie hoch: ein paar Kilobyte pro Icon, in die falsche Richtung.

Den Ordner ablegen. Jede Datei wird einzeln dekodiert und kodiert, das Ergebnis kommt als ZIP zurück, mit einer Qualitätsstufe für den ganzen Stapel. Rechne mit spürbar mehr Zeit als beim gleichen Stapel zu PNG oder WebP, aus dem oben genannten Grund.

Die Abmessungen werden nicht einheitlich sein, sofern es der Quellbestand nicht war. Icon-Sammlungen mischen häufig Dateien mit einem 256-Pixel-Eintrag und Dateien, die bei 32 Pixeln enden — und weil der feste Overhead des Encoders bei kleineren Bildern stärker ins Gewicht fällt, schneiden die 32-Pixel-Mitglieder des Sets im Vergleich am schlechtesten ab.