WebP in AVIF umwandeln

Google PageSpeed Insights und Lighthouse melden seit Jahren „Bilder im nächsten Generationsformat bereitstellen", und in den meisten Fällen bedeutete das bisher: JPG oder PNG raus, WebP rein. Wer diesen Schritt schon gegangen ist, liest inzwischen denselben Hinweis noch einmal, diesmal mit AVIF als Ziel — und viele Agenturen und Website-Betreiber setzen ihn um, ohne vorher nachzumessen, ob die Datei dadurch überhaupt kleiner wird.

Genau das lohnt sich hier, weil die Antwort nicht in eine Richtung fällt. AVIF gewinnt bei flachem, kantenreichem Material klar und verliert bei Fotos bei mittlerer Qualität gelegentlich sogar. Eine ganze Bildbibliothek auf Verdacht umzukodieren kann sie also größer machen statt kleiner.

Diese Website hält drei Testmotive vor und kodiert sie durch dieselbe Pipeline, die auch diese Seite nutzt — die Zahlen stammen also direkt von diesem Umwandler und nicht aus einem fremden Vergleichstest. Bei 480 mal 320 Pixeln und Standardqualität: die flache Grafik 4.428 Byte als WebP, 3.494 als AVIF; die Bildschirmaufnahme 10.830 als WebP, 5.081 als AVIF; das Foto 14.700 als WebP, 17.599 als AVIF.

Das Foto ist der Fall, der zählt, weil ein Bildbudget zum größten Teil aus Fotos besteht. Dort verliert AVIF hier um zwanzig Prozent. Das macht das Format nicht schlecht — bei niedrigerer Qualität und größeren Bildern dreht sich die Reihenfolge häufig um —, aber es macht „AVIF ist dreißig Prozent kleiner als WebP" zu einer Behauptung, die am eigenen Bildbestand geprüft gehört, bevor fünftausend Dateien umgewandelt werden.

Das Muster in diesen Zahlen ist kein Zufall. Die Intra-Vorhersage von AV1 ist ungewöhnlich gut bei großen Flächen fast gleichmäßiger Farbe mit harten Kanten dazwischen, und der Codec hat deutlich mehr Blockaufteilungen und Vorhersagemodi zur Verfügung, um eine Kante exakt zu treffen, als das von VP8 abgeleitete WebP.

Genau das beschreibt Bildschirmfotos, Diagramme, Illustrationen, Produktfotos vor einfarbigem Hintergrund und alles mit Schrift darin — auf einer typischen Website ein großer Anteil der Bilddateien, oft aber ein kleiner Anteil der Bytes. Genau diese Bilder lohnt es zuerst umzuwandeln; fotografische Motive gehören einzeln gemessen.

Die Umwandlung dekodiert das WebP auf Bildpunkte und kodiert diese Bildpunkte als AVIF. War das WebP verlustbehaftet, gehören seine eigenen Artefakte — geglättete Flächen, Klingeln an harten Kanten — schon zum Bild, und der AVIF-Encoder gibt sich Mühe, sie originalgetreu wiederzugeben, und legt noch eine eigene Schicht darüber.

Bei Qualität 82 ist das nicht dramatisch, aber auch nicht kostenlos, und meist vermeidbar. Die ursprüngliche PNG- oder JPG-Datei liegt bei den meisten Projekten noch im Repository, im Designwerkzeug oder in einem Asset-System, und daraus direkt AVIF zu kodieren ergibt ein sauberes und häufig kleineres Ergebnis. Diese Seite ist für den Fall gedacht, dass wirklich nur noch das WebP übrig ist — eine von einem CDN umgewandelte Datei, eine übernommene Website, ein aufgeräumter Ordner.

WebP läuft in jedem aktuellen Browser. AVIF läuft in modernen — ein Unterschied, der praktisch etwas anderes bedeutet: ein älteres Gerät, ein abgeriegelter Firmenrechner oder ein In-App-Browser kann auf der Seite landen und bekommt gar nichts, weil ein nicht dekodierbares Bild kein schlechteres Bild ist, sondern eine leere Fläche.

Die Lösung ist bekannt und günstig: ein picture-Element mit einer AVIF-Quelle und WebP oder JPG als Rückfallebene kostet zwei zusätzliche Zeilen Markup und nimmt das Risiko vollständig heraus. Das bedeutet aber auch, beide Dateien vorzuhalten — wichtig zu wissen, wenn der Anlass der Migration eigentlich Speicherplatz sparen sollte. Für Bilder, die ohne Rückfallmechanismus verschickt werden — als E-Mail-Anhang, an eine Kollegin — bleibt WebP die sicherere Wahl.

AV1 erkauft seine Kompression mit Rechenaufwand, und der Encoder hier ist libavif, kompiliert zu WebAssembly. Eine WebP-zu-AVIF-Umwandlung dauert deutlich länger als jede andere Paarung in dieser Familie — das Dekodieren geht schnell, das Kodieren nicht, und bei einem großen Bild sind es Sekunden statt Millisekunden.

Der Aufwand landet an der richtigen Stelle: einmal, auf der eigenen Maschine, zum selbst gewählten Zeitpunkt, statt bei jeder Besucherin erneut. Das verändert aber, wie eine Migration abläuft. Ein Ordner mit mehreren hundert Bildern ist eher ein Vorgang zum Starten und Liegenlassen als zum Zusehen, und auf dem Smartphone ist das keine gute Idee.

Transparenz übersteht den Wechsel sauber: Beide Formate führen einen vollen 8-Bit-Alphakanal, und AVIF geht damit effizient um, weshalb freigestellte Produktbilder und Logos zu den Bildern zählen, bei denen AVIF am zuverlässigsten gewinnt. Weiche Kanten bleiben weich, es entsteht kein Rand.

Was nicht passiert, ist ein Gewinn an Farbtiefe oder Farbraum. AVIF kann zwölf Bit je Kanal und einen erweiterten Farbraum speichern; diese Pipeline dekodiert aber alles auf 8-Bit-RGB, und das WebP war ohnehin schon 8-Bit — es gibt also nichts, was sich hier nachträglich anheben ließe. Wer eine Bibliothek in Richtung HDR bewegen will, braucht dafür die ursprünglichen Aufnahmen und eine Software, die Profile versteht.

Die Einstellung reicht von 1 bis 100 und startet bei 82, und dieselbe Zahl bedeutet bei zwei verschiedenen Codecs nicht dasselbe. Weil die Quelle bereits ein verlustbehaftetes WebP ist, spricht einiges dafür, etwas höher zu gehen als bei einer echten Originaldatei — der Encoder versucht, ein Bild nachzubilden, das schon Struktur enthält, die er selbst nicht hineingelegt hat.

Praktisch bewährt sich, drei repräsentative Bilder bei 78, 82 und 88 umzuwandeln und sowohl die Bytezahl als auch das Erscheinungsbild in der tatsächlichen Anzeigegröße zu vergleichen. Das dauert zehn Minuten und klärt die Frage für die ganze Bibliothek zuverlässiger als jede Faustregel. Bei Bildern mit Schrift lohnt sich eher die höhere Stufe.

Sind die Bilder bereits WebP und die Seite erfüllt ihr Ladezeitbudget, ist die ehrliche Empfehlung: nichts tun. Der Wechsel von JPG oder PNG zu WebP war der Schritt mit dem großen Gewinn; der Wechsel von WebP zu AVIF ist ein Gewinn zweiter Ordnung, der manchmal negativ ausfällt, Kodierzeit kostet und eine Rückfalllösung nach sich zieht.

Klar lohnt er sich bei großen flachen Bildern, bei bildlastigen Seiten mit messbarer Gesamtersparnis und bei Websites mit vielen Bildschirmfotos oder Diagrammen. Nicht lohnt er sich bei kleinen Icons, bei Bildern, die schon wenige Kilobyte groß sind, und bei fotografischen Motiven, bei denen eine Messung zeigt, dass AVIF größer wird.

Beide Codecs laufen als WebAssembly im Tab und werden erst geladen, wenn tatsächlich eine passende Datei abgelegt wird — ein Stapel von hundert Bildern lädt den Encoder also nur einmal. Keine der Dateien geht dabei über das Netz, was bei Bildern zählt, die einer Kundin gehören oder von einer noch nicht veröffentlichten Website stammen.

Die kostenlose Grenze liegt bei 100 MB je Datei, weit über jedem Webbild. Ein Ordner voller Dateien läuft nacheinander mit eigener Fortschrittsanzeige, am Ende steht ein ZIP bereit. Eine animierte WebP-Datei im selben Ordner wird abgelehnt statt stillschweigend auf ein Einzelbild reduziert — der Dekoder hier liest nur Standbilder —, sodass ein gemischter Ordner ein paar Fehlermeldungen liefert und den Rest fertigstellt.