WebP naar AVIF omzetten

Deze site houdt drie voorbeeldscènes bij en codeert ze door dezelfde pijplijn die deze pagina gebruikt. Bij 480 bij 320 en de standaardkwaliteit: de vlakke graphic is 4428 bytes als WebP en 3494 als AVIF; de schermafbeelding-achtige scène is 10.830 als WebP en 5081 als AVIF; en de foto is 14.700 als WebP en 17.599 als AVIF.

De foto is degene die telt, want een foto is waar de meeste beeldbudgetten uit bestaan. AVIF verloor daar met twintig procent. Dat maakt het formaat niet slecht — bij lagere kwaliteit en op grotere afbeeldingen keert de volgorde vaak om — maar het maakt «AVIF is dertig procent kleiner dan WebP» wel een claim om op je eigen materiaal te testen.

Het patroon in die cijfers is niet willekeurig. AV1’s intra-voorspelling is ongewoon goed in grote gebieden bijna-constante kleur gescheiden door harde grenzen, en het heeft meer blokverdeling en voorspelmodi om een rand exact goed te krijgen dan WebP’s VP8-afgeleide codering.

Dat beschrijft interfaceschermafbeeldingen, diagrammen, grafieken, illustraties, productfoto’s op effen achtergrond, en alles met tekst erin — bij een typische site een groot deel van het aantal afbeeldingen ook al is het een klein deel van de bytes. Zet die het eerst om.

De omzetting decodeert de WebP naar pixels en codeert die pixels als AVIF. Was de WebP lossy, dan zijn zijn eigen artefacten — glad gestreken vlakke gebieden, ringing langs harde randen — nu deel van het beeld, en de AVIF-encoder besteedt bits aan het getrouw beschrijven ervan.

Bij kwaliteit 82 is dat niet dramatisch en ook niet gratis, en meestal vermijdbaar. De meeste sites hebben nog de originele PNG of JPG in het archief, en AVIF daaruit coderen levert een schoner en vaak kleiner bestand op dan vanaf de WebP. Bestaat het origineel nog, gebruik het dan.

WebP wordt door elke huidige browser ondersteund. AVIF wordt door moderne browsers ondersteund, wat iets anders is: een ouder apparaat, een afgesloten bedrijfsmachine of een ongewone client kan op de pagina landen en helemaal niets krijgen, want een afbeelding die niet gedecodeerd kan worden, is geen verminderde afbeelding, het is een leeg vak.

De oplossing is bekend en goedkoop. Een picture-element met een AVIF-bron en een WebP- of JPG-terugvaloptie kost twee extra regels markup en verwijdert het risico volledig. Dat betekent wel dat je beide bestanden bewaart.

AV1 koopt zijn compressie met analyse, en de encoder hier is libavif gecompileerd naar WebAssembly. WebP naar AVIF omzetten is merkbaar trager dan elk ander paar in deze familie — het decoderen is snel en het coderen niet, en bij een grote afbeelding gaat het om seconden in plaats van milliseconden.

De kosten vallen op de juiste plek: eenmalig, op je eigen machine, op het moment dat jij kiest, in plaats van bij elke bezoeker. Maar het verandert hoe je een migratie uitvoert. Een map van enkele honderden assets is een taak om te starten en te laten lopen, niet om te bekijken.

Transparantie overleeft netjes: beide formaten dragen een volledig 8-bit alfakanaal, en AVIF is er efficiënt mee, dus uitgesneden productfoto’s en logo’s behoren tot de assets waar het het betrouwbaarst wint.

Wat niet gebeurt, is winst in diepte of kleurbereik. AVIF kan twaalf bit per kanaal en breed kleurbereik opslaan; deze pijplijn decodeert alles naar 8-bit RGB, en de WebP was al 8-bit, dus is er niets te promoveren.

De instelling loopt van 1 tot 100 en begint op 82, en hetzelfde getal betekent niet hetzelfde voor twee verschillende codecs. Omdat de bron al een lossy WebP is, is er een echt argument om iets hoger in te stellen dan bij een origineel.

De praktische methode: zet drie representatieve afbeeldingen om op 78, 82 en 88 en vergelijk zowel de bytes als het uiterlijk op het formaat waarop de pagina ze echt toont. Dat kost tien minuten en beslecht de vraag voor de hele bibliotheek veel beter dan een vuistregel.

Zijn de assets al WebP en haalt de pagina zijn prestatiebudget, dan is niets doen het eerlijke advies. De stap van JPG of PNG naar WebP leverde de grote besparing op; de stap van WebP naar AVIF is een tweede-orde winst die soms negatief is.

De gevallen die het duidelijk rechtvaardigen: grote vlakke afbeeldingen, beeldzware pagina’s waar de totale besparing meetbaar is, en sites met veel schermafbeeldingen of diagrammen. Is het doel simpelweg bredere compatibiliteit in plaats van minder bytes, dan zijn WebP naar PNG of WebP naar JPG de juiste pagina’s.

Beide codecs draaien als WebAssembly in het tabblad en worden alleen opgehaald als een bestand van dat type wordt neergezet, dus een batch van honderd afbeeldingen haalt de encoder één keer op. Niets van de bestanden gaat over het netwerk.

De gratis limiet is 100 MB per bestand, ruim boven elk webasset. Sleep een map naar binnen en elk bestand wordt na elkaar omgezet met eigen voortgang, en de resultaten komen terug als ZIP. Een geanimeerde WebP in de map wordt geweigerd in plaats van stilzwijgend platgeslagen.