AVIF vs WebP — het kleinste bestand is niet altijd het juiste

Ik heb ooit een gênante avond verspild aan het A/B-vergelijken van dezelfde hero-afbeelding als WebP en AVIF, heen en weer schakelend tussen twee browsertabs, op zoek naar een verschil dat mijn ogen daadwerkelijk konden zien. De AVIF was 31% kleiner. Ik kon ze niet uit elkaar houden. Ik zat daar met het gevoel dat ik gratis geld had gevonden — en toen draaide ik de batch op een map met 200 afbeeldingen en herinnerde ik me het addertje.

AVIF is meestal het kleinere bestand. Dat klopt en is het weten waard. Maar „kleiner" is slechts één kolom in het spreadsheet, en in de andere kolommen zit de eigenlijke beslissing.

Waar AVIF wint

AVIF is gebouwd op de AV1-videocodec en het is een echt nieuwer, slimmer ontwerp dan WebP. Op fotografische inhoud komt het doorgaans 15–30% kleiner uit dan een WebP bij gelijke visuele kwaliteit. Het gaat om met vloeiende verlopen — luchten, huid, zachte schaduwen — zonder de blokkerige artefacten die oudere codecs eroverheen smeren. Het ondersteunt HDR en een breed kleurbereik, wat WebP niet doet. Het houdt een volledig alfakanaal, net als WebP.

Wat ruwe cijfers uit die map die ik noemde, allemaal bij een kwaliteitsinstelling waar ik geen verschil kon ontdekken:

Kijk nog eens naar die laatste regel. Op platte, simpele graphics komt AVIF soms groter uit. Zijn slimheid is afgesteld op fotografische complexiteit, en in een tweekleurige illustratie heeft het niets om op te kauwen. WebP, of zelfs PNG, kan daar winnen.

Waar AVIF je iets kost

De winst in grootte is niet gratis. Twee echte kosten:

Encodeertijd. AVIF is dramatisch trager om te comprimeren. Op dezelfde afbeelding kan een AVIF-encode meerdere keren langer duren dan een WebP — soms het verschil tussen „direct" en „wacht een paar seconden per bestand." Voor één hero-afbeelding maakt het niet uit. Voor een batch van 200 voel je elke seconde. WebP encodeert zo snel dat het praktisch gratis is.

Decoderen en ondersteuning. Elke browser die mensen daadwerkelijk gebruiken decodeert AVIF inmiddels — Chrome sinds 2020, Firefox niet lang daarna, Safari vanaf versie 16 eind 2022. In 2026 dekt dat het overgrote deel van het echte verkeer. Maar „ondersteund" en „universeel" zijn niet hetzelfde woord. WebP heeft een paar jaar meer verzadiging achter zich, en het decodeert sneller op goedkope telefoons, waar AV1-decodering merkbaar batterij en CPU kan kosten. Sommige e-mailclients en oudere ingebouwde webviews raken AVIF nog steeds helemaal niet aan.

De 20%-vraag

Dus de echte beslissing komt hierop neer: doet die extra ~20% ertoe voor deze afbeelding, op deze plek?

Voor een grote hero-afbeelding op een landingspagina — het ene zware bestand dat elke bezoeker downloadt — ja. 100 KB afknippen van het ding dat je eerste weergave ophoudt, is een tragere encode waard die je maar één keer betaalt. Dat is het duidelijkste geval voor AVIF dat ik ken.

Voor een rooster met thumbnails, de inline-schermafbeeldingen van een blog, of alles wat als WebP al onder de ~50 KB zit, is het antwoord meestal nee. Twintig procent van een klein getal is een kleiner getal. Je hebt encodeertijd en een sliver compatibiliteit ingeruild om bytes te besparen waar niemand op zat te wachten. WebP is daar de rustigere standaard.

Wanneer ik AVIF laat zitten

Gaat een bestand ergens buiten een moderne browser heen — een e-mailnieuwsbrief, een oud CMS, het systeem van een partner dat ik niet in de hand heb — dan gok ik niet op AVIF. Ik gebruik WebP, of gewoon JPG als ik nul risico wil. Het kleinste bestand dat niet weergegeven wordt, is niets waard.

En ik encodeer geen platte graphics, logo's of lijntekeningen naar AVIF. Daar is de codec niet voor, en ik heb het vaak genoeg zien verliezen van WebP op dat soort bestanden om ermee te stoppen.

Hoe ik echt beslis

Mijn eerlijke werkwijze: ik zet het zware fotografische materiaal om naar AVIF en houd het lichte, simpele en breed verspreide spul als WebP. Er is niet één formaat dat over alles heerst. Het is per afbeelding kiezen.

Wil je de vergelijking zelf proberen, dan draaien beide hier in je browser — WebP naar AVIF om bestaande WebP-bestanden verder uit te knijpen, en PNG naar AVIF om direct vanaf een master te gaan. Er wordt niets geüpload; de encode gebeurt op je machine, wat ook meteen de reden is dat je AVIF's traagheid aan den lijve voelt. Dat is geen bug. Dat is de codec die meer werk verzet voor een kleiner bestand, recht voor je neus.

Haal je eigen hero-afbeelding door beide. Kun je het verschil niet zien en is de AVIF merkbaar kleiner, dan heb je je antwoord. Ga er alleen niet van uit dat het antwoord hetzelfde is voor de volgende 200 bestanden.