AVIF of WebP: welk beeldformaat kies je in 2026

Als je een webshop, blog of productcatalogus beheert, nemen afbeeldingen vrijwel zeker het grootste deel van het gewicht van een pagina in beslag. Juist zij vertragen het laden, verbruiken de databundel van je bezoekers en verpesten je snelheidsscores in zoekmachines. Het goede nieuws: de afgelopen jaren zijn er formaten opgekomen die beelden vele malen sterker comprimeren dan het vertrouwde JPG, terwijl de afbeelding er precies zo uitziet. Het slechte nieuws: er zijn er meteen meerdere, elk met eigen voordelen en eigen valkuilen, en zomaar kiezen is lastig. In dit artikel leggen we uit waarin AVIF verschilt van WebP, wat JPEG XL ermee te maken heeft, wanneer je welk formaat gebruikt en hoe je alles zo instelt dat het voor werkelijk elke bezoeker snel is.

Stel je twee ogenschijnlijk identieke productfoto's voor. De ene weegt 800 kB, de andere 180 kB. Voor het oog is er geen verschil, maar voor de website is dat verschil enorm. Op een cataloguspagina staan meestal 20 tot 40 afbeeldingen, en als elke afbeelding te zwaar is, dijt de pagina uit tot enkele megabytes. Een bezoeker met een telefoon op een niet al te snelle verbinding sluit de tab gewoon voordat het laden klaar is. Uit statistieken blijkt dat een aanzienlijk deel van de mensen een pagina verlaat die langer dan drie seconden laadt, en meestal zijn juist de zware afbeeldingen de boosdoener.

De laadsnelheid is allang een rankingfactor geworden. Zoekmachines meten hoe snel de belangrijkste content van een pagina zichtbaar wordt, en afbeeldingen staan hierbij op de eerste plaats qua invloed. Hoe lichter de beelden, hoe sneller de pagina verschijnt, hoe groter de kans dat de bezoeker blijft en iets koopt. Dit werkt beide kanten op: een snelle site krijgt meer bezoekers uit de zoekresultaten, en een snelle pagina houdt de mensen die al binnen zijn beter vast. Afbeeldingen zijn in deze vergelijking bijna altijd de zwakste schakel, want tekst en stijlbestanden wegen kilobytes, terwijl één niet-gecomprimeerde foto zomaar een megabyte kan wegen.

Er is ook een puur financiële kant. Elke megabyte die je aan een bezoeker uitlevert, is dataverkeer. Op een grote site met duizenden bezoeken per dag beïnvloedt het beeldgewicht rechtstreeks je hostingkosten en de snelheid van je server. Halveer je de afbeeldingen, dan halveer je de belasting en de kosten, zonder iets aan beeldkwaliteit in te leveren.

Het goede oude JPG heeft zijn dienst bewezen, maar qua compressie-efficiëntie is het hopeloos achterop geraakt. Moderne formaten leveren bij dezelfde visuele kwaliteit bestanden die twee keer zo licht en klein zijn. De enige vraag is welk van de nieuwe formaten je kiest en hoe je de site niet stukmaakt voor wie een oude browser heeft. Laten we het stap voor stap doornemen, zonder overbodige theorie, alleen wat je in de praktijk nodig hebt.

Kleine woordenlijst van formaten, zodat het verderop duidelijk is

Voordat we gaan vergelijken, lopen we de hoofdrolspelers even langs. Het zijn er vijf, en elk heeft zijn eigen rol.

• JPG (ook wel JPEG). Veteraan uit 1992. Compressie met verlies, zonder transparantie en animatie. Opent werkelijk overal, maar is qua efficiëntie hopeloos verouderd.
• PNG. Compressie zonder verlies, ondersteunt transparantie. Onmisbaar voor logo's, iconen en graphics met scherpe lijnen, maar foto's wegen erin heel veel.
• WebP. Formaat van Google, ontstaan in 2010, breed ingeburgerd rond het midden van de jaren 2010. Kan zowel compressie met verlies als zonder verlies, plus transparantie en animatie. De gulden middenweg qua compatibiliteit.
• AVIF. Jong formaat op basis van de videocodec AV1, ontstaan in 2019. Comprimeert sterker dan alle andere bij dezelfde kwaliteit, ondersteunt transparantie, animatie, uitgebreide kleur en HDR. Het grootste nadeel: traag coderen.
• JPEG XL (JXL). Veelbelovende nieuwkomer die bijna alles kan en achterwaarts compatibel is met JPG, maar voorlopig zwak wordt ondersteund door browsers. Daarover verderop apart.

Modern formaat, 30% lichter dan WebP en 2 tot 3 keer lichter dan JPG. Dezelfde kwaliteit.

60-70 voor het web, 80-90 als de foto voor de druk is of erg gedetailleerd.

WebP kwam eerder dan de moderne concurrenten en is intussen praktisch een standaard geworden. Als je één formaat wilt dat simpelweg overal werkt en geen gedoe oplevert, is dit het.

De sterke kanten van WebP

• Bijna volledige browserondersteuning. WebP wordt begrepen door meer dan 97 procent van de browsers wereldwijd. De ondersteuning verscheen in Chrome al in 2010-2014, in Firefox vanaf versie 65 (2019), in Safari vanaf versie 14 op macOS Big Sur (2020), en op de iPhone volwaardig vanaf iOS 14. Dat betekent dat de overgrote meerderheid van je bezoekers de afbeelding ziet zonder enige kunstgreep.
• Merkbare gewichtsbesparing. Vergeleken met JPG van dezelfde kwaliteit is WebP ongeveer 25 tot 35 procent lichter. Voor de meeste sites is dat al een enorme sprong: een pagina die 4 MB woog, gaat richting 2,5 MB.
• Snel coderen. Een afbeelding naar WebP omzetten gaat snel, vele malen sneller dan naar AVIF. Dat is cruciaal wanneer beelden onderweg worden geconverteerd, bijvoorbeeld wanneer een gebruiker een avatar of recensiefoto uploadt en meteen het resultaat verwacht.
• Ondersteuning voor transparantie en animatie. WebP beheerst zowel het alfakanaal (transparante achtergrond) als animatie, en past dus zowel als vervanger van PNG met transparante achtergrond als van zware GIF-animaties. Een geanimeerde WebP is vele malen lichter dan dezelfde clip in GIF.
• Modus zonder verlies. WebP heeft ook een lossless-modus, een directe concurrent van PNG. Die levert bestanden die gemiddeld 20 tot 26 procent lichter zijn dan PNG bij perfect nauwkeurige opslag van pixels, wat uitstekend geschikt is voor schermafbeeldingen en graphics.
• Volwassen ecosysteem. Het formaat bestaat lang genoeg dat alle populaire contentmanagementsystemen, plug-ins en tools ermee overweg kunnen zonder toeren. Je zult zelden tegenkomen dat een dienst het niet begrijpt.

Waar WebP het aflegt

Het belangrijkste bezwaar tegen WebP is dat er een formaat bestaat dat nóg sterker comprimeert. Bij zeer grote hoeveelheden beelden (duizenden producten in een catalogus) verandert elke bespaarde procent gewicht in reële besparing op dataverkeer en in sneller laden. Wanneer het om een paar tientallen afbeeldingen gaat, is het verschil tussen WebP en agressievere compressie nauwelijks merkbaar. Maar als je een grote catalogus of een fotogalerij met honderden opnamen hebt, stapelen die procenten zich op tot tientallen en honderden megabytes, en daar legt WebP het af.

Nog een nuance: WebP met kwaliteitsverlies gaat soms iets minder goed om met zeer vloeiende gradiënten op grote foto's dan het allernieuwste formaat. In de praktijk merk je dit zelden en alleen bij sterke compressie, maar het is goed om te weten als je met artistieke opnamen werkt. WebP heeft ook een technische beperking qua afmeting: maximaal 16383 bij 16383 pixels, wat vrijwel altijd genoeg is, maar reusachtige panorama's passen er niet in.

Het is nuttig te begrijpen waar die besparing vandaan komt. WebP gebruikt slimmere algoritmes om naburige pixels te voorspellen dan het oude JPG en pakt herhalende delen van de afbeelding efficiënter in. Grofweg gezegd raadt het formaat beter wat het volgende stukje beeld zal zijn en bewaart het alleen het verschil, in plaats van alles achter elkaar. Voor de gebruiker betekent dat één ding: dezelfde visuele scherpte bij minder gewicht, zonder enige instelling aan zijn kant.

Waar WebP in de praktijk bijzonder van pas komt

Er zijn een paar typische scenario's waarin de overstap op WebP het snelste en meest merkbare effect geeft, en dat vrijwel zonder risico om iets stuk te maken.

• Blog en informatieve artikelen. Hier zijn de beelden vooral illustratief, ze zijn niet talrijk, en maximale compatibiliteit is belangrijker dan de laatste procent compressie. WebP dekt de taak volledig.
• Previews en miniaturen in de catalogus. Kleine afbeeldingen in een lijst, waarbij het vooral belangrijk is dat ze meteen en bij iedereen gelijk verschijnen. WebP codeert snel en laadt snel.
• Sites op kant-en-klare platformen. Als je een standaard contentmanagementsysteem hebt, wordt het omzetten van beelden naar WebP meestal met één kant-en-klare oplossing gedaan, die automatisch WebP uitlevert aan wie het ondersteunt en gewoon JPG aan de rest. Dat is de eenvoudigste weg naar snelheidswinst helemaal zonder handwerk.
• Vervanging van zware GIF's. Geanimeerde banners en korte loops in GIF wegen monsterlijk veel. Dezelfde clip in geanimeerde WebP is enkele malen lichter en ziet er hetzelfde of beter uit.

Voor veel site-eigenaren is alleen al de overstap op WebP genoeg om het onderwerp beeldoptimalisatie voor de komende jaren af te sluiten. Dat wil niet zeggen dat AVIF overbodig is, WebP levert simpelweg tachtig procent van het resultaat voor twintig procent van de moeite, en het is verstandig daarmee te beginnen.

De conclusie over WebP is simpel: het is een veilige standaardkeuze. Als je je niet in de fijne kneepjes en het instellen van fallbacks wilt verdiepen, zet dan alles om naar WebP en je hebt al het grootste deel van het voordeel van moderne formaten te pakken. Een fout maken is hier vrijwel onmogelijk, en voor een enorm aantal sites is WebP alleen al meer dan voldoende om het laden radicaal te versnellen.

AVIF is een nieuwer formaat, gebouwd op de technologie van moderne videocompressie: het gebruikt de intra-frame-compressie uit de codec AV1, dezelfde waarop moderne streamingdiensten draaien. Zijn belangrijkste troef is agressieve compressie, en daarin is het koploper.

Waarin AVIF beter is

• De sterkste compressie. Bij gelijke visuele kwaliteit zijn AVIF-bestanden 20 tot 30 procent lichter dan WebP en ongeveer 50 procent lichter dan JPG. Dat wil zeggen dat AVIF twee keer zo licht kan zijn als de vertrouwde JPG-afbeelding, en het oog merkt het verschil niet.
• Houdt complexe beelden goed vast. Op foto's met vloeiende gradiënten (lucht, huid, wazige achtergrond) laat AVIF vrijwel geen van die lelijke artefacten en blokjes achter waar JPG last van heeft bij sterke compressie. In plaats van vierkante blokkerigheid geeft het een zachte vervaging, die het oog veel makkelijker verdraagt.
• Transparantie en animatie. AVIF ondersteunt het alfakanaal (transparante achtergrond) en animatie, net als WebP, dus je kunt er zowel PNG als GIF mee vervangen.
• Brede kleur en HDR. Dit heeft WebP helemaal niet. AVIF beheerst 10- en 12-bits kleurdiepte, uitgebreide kleurruimtes en HDR. Voor een schoenencatalogus is dat onbelangrijk, maar voor een fotogalerij, een portfolio van een fotograaf of een reissite zien levendige, verzadigde opnamen er op moderne schermen merkbaar rijker uit.
• Goede prestaties bij lage bitrates. Bij zeer sterke compressie valt AVIF het mooist uiteen: zelfs wanneer het gewicht tot het uiterste is teruggebracht, blijft de afbeelding acceptabel, terwijl JPG in dezelfde situatie in een mozaïek verandert.

De valkuilen van AVIF

• Traag coderen. Dit is het grootste nadeel. Een afbeelding naar AVIF omzetten is 5 tot 10 keer trager dan naar WebP, en op de maximale kwaliteitsinstellingen nog meer. Waarom dat juist voor UGC (content die gebruikers zelf maken) belangrijk is: wanneer iemand op dit moment een recensiefoto of avatar uploadt en wacht, verpesten extra seconden codeertijd de hele ervaring. Voor statische site-afbeeldingen is dat geen probleem, je converteert één keer en vergeet het, maar voor verwerking in realtime is de vertraging voelbaar.
• Ondersteuning iets lager, maar al uitstekend. Tegen 2026 begrijpt zo'n 95 procent en meer van de browsers AVIF. Chrome ondersteunt het vanaf versie 85 (2020), Firefox vanaf versie 93 (2021), Safari vanaf versie 16 op iOS 16 en macOS Ventura (2022). Dat is een heel goed cijfer, maar toch een paar procent lager dan bij WebP. Er is dus een reserveoptie nodig voor wie het formaat niet kan openen.
• Oude software opent het niet. Veel desktopprogramma's, mailclients, berichten-apps en foto-editors kunnen AVIF nog altijd niet openen. Als een bezoeker zo'n afbeelding naar zijn computer downloadt, opent die misschien niet in zijn vertrouwde viewer. Daarom is AVIF prima voor weergave op de site, maar als bestand om te downloaden of door te sturen is het voorlopig discutabel.
• Iets zwaardere eisen bij het bekijken. Het uitpakken van AVIF belast de processor van het apparaat iets zwaarder dan WebP. Op moderne telefoons en computers merk je dat niet, maar op heel oude en zwakke apparaten kan het in theorie de weergave iets vertragen. Tegenover de gewichtswinst is dat een kleinigheid, maar het is eerlijk het te vermelden.

Om het aanschouwelijker te maken, stellen we ons een typische productkaart voor met één foto van 1200 bij 1200 pixels. In JPG van nette kwaliteit weegt die ongeveer 350 kB. Dezelfde opname in WebP: ongeveer 230 kB. En in AVIF: ongeveer 140 kB. Dat wil zeggen dat AVIF hier twee-en-een-half keer lichter is dan JPG en anderhalf keer lichter dan WebP. Vermenigvuldig dat met honderden producten en de omvang van de besparing wordt duidelijk.

Hoe je afbeeldingen naar AVIF en WebP converteert

Er zijn meerdere manieren, en de keuze hangt af van hoeveel afbeeldingen je hebt en hoezeer je het proces wilt automatiseren.

1. Online converter voor eenmalige taken. De eenvoudigste weg wanneer je een paar beelden moet omzetten: je uploadt de afbeelding, krijgt AVIF of WebP, downloadt hem en zet hem op de site. Ideaal voor de afbeelding boven de vouw, banners en een tiental sleutelfoto's. Onze conversietool doet dit direct in de browser, zonder iets te installeren.
2. Batchverwerking van een map. Als je honderden afbeeldingen hebt, is het zinvol ze in één keer te verwerken. Veel converters kunnen een hele map aannemen en een kant-en-klare set bestanden in het nieuwe formaat met dezelfde namen teruggeven.
3. Automatisering aan de kant van de site. Voor grote catalogi is het verstandig zo in te stellen dat de site zelf AVIF en WebP maakt bij het uploaden van elke nieuwe afbeelding en de juiste variant uitlevert per browsertype. Dan kun je handmatige conversie helemaal vergeten.

Waar je bij het converteren op moet letten: stel de kwaliteit ergens in het midden-hoge bereik in, draai de compressie niet tot het maximum voor een paar kilobytes extra (dat geeft brij), en bewaar het origineel altijd in JPG of PNG als fallback. Ook de afmeting van de afbeelding in pixels is belangrijk: het heeft geen zin een foto van 4000 pixels breed te bewaren als hij op de pagina op 800 wordt getoond. Verklein eerst tot de benodigde afmeting en converteer daarna, zo is de winst maximaal.

Kort gezegd: AVIF is gemaakt voor gevallen waarin minimaal gewicht het belangrijkst is en je bereid bent tijd te steken in een eenmalige conversie. Het is het ideale formaat voor statische beelden die je één keer uploadt en aan duizenden bezoekers toont. Eén keer een paar seconden aan conversie besteed, en de snelheidswinst krijg je bij elke weergave van de pagina, en dat miljoenen keren.

Om niet te verdwalen in specificaties, houd je een praktische regel aan. Die dekt vrijwel alle reële situaties.

Spiekbriefje: formaat per contenttype

Als je in een paar seconden moet beslissen, oriënteer je dan op het type afbeelding.

• Productfoto's in de catalogus: AVIF met een fallback op WebP. Veel afbeeldingen, laden vaak, maximale besparing.
• Grote banners en covers: AVIF. Dit zijn de zwaarste elementen, en ze profiteren het sterkst van agressieve compressie.
• Iconen, logo's, eenvoudige graphics: SVG indien mogelijk, anders PNG of WebP zonder verlies.
• Illustraties in artikelen: WebP, bij grote hoeveelheden AVIF. Compatibiliteit is hier waardevoller dan extreme compressie.
• Foto's die gebruikers uploaden (UGC): WebP, omdat directe verwerking belangrijk is.
• Afbeeldingen in e-mails: alleen JPG of PNG, e-mail begrijpt de nieuwe formaten niet.
• Previews voor sociale media (og:image): JPG of PNG, anders wordt de preview mogelijk niet opgebouwd.
• Animatie: geanimeerde WebP of AVIF in plaats van GIF, besparing van meerdere keren.

Kies AVIF wanneer

• De beelden statisch zijn en zelden veranderen: productfoto's in de catalogus, illustraties in artikelen, banners, afbeeldingen in de header en footer.
• Er veel afbeeldingen zijn en elke bespaarde kilobyte vermenigvuldigd wordt met duizenden weergaven.
• Je de beelden vooraf voorbereidt (één keer geconverteerd bij het uploaden naar de site) en niet onderweg.
• Je levendige, verzadigde foto's met brede kleur of HDR nodig hebt, bijvoorbeeld in een portfolio of fotogalerij.
• Het hoofddoel is maximale snelheid en minimaal dataverkeer eruit persen.

Kies WebP wanneer

• Gebruikers de content maken: avatars, foto's in recensies, beelden die nu meteen worden geüpload en direct verwerkt moeten worden.
• Eenvoud en voorspelbaarheid voor je belangrijk zijn, zonder gedoe met fallbacks.
• Je maximaal brede compatibiliteit met een minimum aan moeite nodig hebt.
• Er niet zoveel afbeeldingen zijn dat het verschil in compressie doorslaggevend wordt.

Kies PNG wanneer

• Het gaat om een logo, icoon, schermafbeelding of graphic met scherpe lijnen en effen kleurvlakken.
• Je perfect schone transparantie nodig hebt zonder ook maar het minste artefact langs de randen.
• De afbeelding later nog bewerkt wordt en het belangrijk is de pixels precies te bewaren.

Wanneer je JPG houdt

JPG is qua compressie verouderd, maar het opent werkelijk overal, zelfs in de oudste programma's en apparaten. Het is zinvol JPG alleen te houden als allerlaatste reserveoptie voor uitzonderlijke gevallen of wanneer je een afbeelding moet aanleveren aan een systeem dat niets nieuws begrijpt (bijvoorbeeld bij het uploaden van productfoto's naar sommige marktplaatsen die alleen klassieke formaten accepteren). Voor de site zelf kies je JPG als hoofdformaat in 2026 niet meer.

En hoe zit het met JPEG XL?

JPEG XL (JXL) is een nieuw formaat waarop velen hun hoop hebben gevestigd, en niet zonder reden. Technisch is het indrukwekkend: het comprimeert ongeveer op het niveau van AVIF of iets beter bij foto's, codeert sneller dan AVIF, beheerst transparantie, animatie, brede kleur en HDR, progressief laden (de afbeelding komt geleidelijk op, niet van boven naar beneden) en, wat bijzonder waardevol is, kan een bestaande JPG zonder verlies opnieuw comprimeren, ongeveer 20 procent lichter, met behoud van de mogelijkheid naar het origineel terug te keren. Klinkt als het ideale formaat.

Er is één probleem, maar dat is doorslaggevend: de browserondersteuning. Anno 2026 begrijpt Safari JPEG XL standaard (vanaf versie 17), maar Chrome heeft de ondersteuning verwijderd en Firefox schakelt die alleen achter een vlag in. Dat betekent dat je JXL voorlopig niet zonder een betrouwbare fallback aan de grote massa bezoekers kunt uitleveren, en in de praktijk weegt het sop de kool vaak niet waard. Conclusie: houd JPEG XL op de radar als zeer veelbelovend formaat, maar voor een werksite in 2026 is de inzet op AVIF plus WebP betrouwbaarder. Zodra Chrome de ondersteuning terugbrengt, kan het beeld veranderen, en dan is het de moeite waard de strategie te herzien.

Discutabele situaties

Soms past de taak niet precies binnen de regel. Hier de vaak voorkomende tweesprongen en hoe je ze oplost.

• De catalogus is groot, maar de foto's worden door verkopers zelf geüpload. Hier is een hybride verstandig: bij het uploaden elk formaat accepteren, onderweg snel een WebP maken voor directe weergave, en 's nachts met een achtergrondproces het opgehoopte omzetten naar AVIF. Zo wacht de gebruiker niet en krijgen bezoekers uiteindelijk de lichtste variant.
• Logo's, iconen, eenvoudige graphics met scherpe lijnen. Voor zulke beelden met weinig kleuren is het formaat voor vectorgraphics (SVG) of PNG vaak nog steeds prima geschikt, en van de rasterformaten WebP in de modus zonder verlies. De winst van AVIF op eenvoudige graphics is kleiner dan op foto's.
• Afbeeldingen voor e-mailmailings. Mailprogramma's ondersteunen de nieuwe formaten slecht: reken in e-mails niet op AVIF of WebP. Houd het klassieke JPG of PNG aan. Dit is het geval waarin compatibiliteit belangrijker is dan gewicht.
• Afbeeldingen voor sociale media en linkpreviews. De robots van sociale netwerken die previews bouwen bij het delen, begrijpen vaak alleen JPG en PNG. Houd de afbeelding voor og:image in het klassieke formaat, anders verschijnt de preview mogelijk niet.

Mythes waardoor mensen de overstap uitstellen

Rond de nieuwe formaten hebben zich een paar misvattingen opgehoopt die mensen ervan weerhouden een eenvoudige en voordelige stap te zetten. Laten we de meest voorkomende doornemen.

• Mythe: nieuwe formaten zijn slechter qua kwaliteit. Integendeel. Bij gelijk gewicht zien AVIF en WebP er beter uit dan JPG, en bij gelijke kwaliteit wegen ze minder. Een afbeelding lijkt alleen slechter als je de compressie tot het uiterste opdraait, maar dat is een probleem van de instellingen, niet van het formaat.
• Mythe: het is ingewikkeld om in te voeren. Op het minimale niveau is het één online converter en een bestand vervangen. De volledige opzet met picture is iets ingewikkelder, maar wordt volgens een sjabloon gedaan dat we hierboven hebben gegeven, en daarna gewoon gekopieerd.
• Mythe: de helft van de bezoekers ziet geen afbeeldingen. Dat klopt alleen als je een nieuw formaat zonder fallback uitlevert. Met een picture-keten ziet gegarandeerd honderd procent van de bezoekers de afbeelding, alleen krijgt de een een lichte AVIF en de ander een reserve-JPG.
• Mythe: zoekmachines houden niet van nieuwe formaten. Precies andersom, de snelheidscontroletools raden zelf aan over te stappen op moderne formaten, en een snelle site rankt beter.
• Mythe: nu er AVIF is, is WebP niet meer nodig. Wel degelijk, juist als fallback op AVIF én als snel formaat voor gebruikersuploads. Ze werken als een duo.

De meest elegante oplossing is niet één formaat kiezen, maar aan elke browser het beste van de voor hem beschikbare formaten uitleveren. De browser kiest zelf het eerste formaat dat hij begrijpt en slaat de rest over. Dat doe je met de tag picture.

Hoe de picture-tag is opgebouwd

Binnen picture som je de varianten op van het meest efficiënte naar het meest compatibele. De browser leest ze van boven naar beneden en neemt de eerste die past.

• Als eerste komt AVIF, de lichtste variant. Als de browser die begrijpt, laadt hij precies deze.
• Als tweede komt WebP, voor het geval AVIF niet wordt ondersteund.
• Helemaal aan het einde de gewone tag img met JPG of PNG, dat is de verzekering voor heel oude browsers.

Het schema ziet er zo uit:

• <picture>
• <source srcset="foto.avif" type="image/avif">
• <source srcset="foto.webp" type="image/webp">
• <img src="foto.jpg" alt="Beschrijving" width="800" height="600" loading="lazy" decoding="async">
• </picture>

Belangrijk detail: de attributen alt, width, height, loading en de rest hang je juist aan de tag img binnen picture, en niet aan source. De source-tags zijn alleen verantwoordelijk voor de bestandskeuze, al het andere wordt van de uiteindelijke img gehaald.

Wat er echt gebeurt op een cataloguspagina

Om te zorgen dat het voordeel niet abstract blijft, rekenen we het door op een levend voorbeeld. Stel dat een catalgoguspagina 30 productfoto's van 1200 pixels toont plus een banner boven de vouw.

• Was, alles in JPG: 30 foto's van 350 kB plus een banner van 500 kB, dat is ongeveer 11 MB alleen aan afbeeldingen. Op een mobiele verbinding opent zo'n pagina martelend langzaam, en een aanzienlijk deel van de bezoekers vertrekt eerder.
• Werd, alles in AVIF met WebP-fallback: 30 foto's van 140 kB plus een banner van 200 kB, dat is ongeveer 4,4 MB. Het gewicht daalde met meer dan de helft, en dat zonder ook maar het minste verlies aan beeldkwaliteit voor het oog.

Ruim zes bespaarde megabytes op één pagina, dat is niet alleen snel laden voor de bezoeker, maar ook minder dataverkeer aan de serverkant en een betere score in de snelheidscontroletools. Als je duizenden weergaven per dag hebt, wordt de dataverkeerbesparing per maand in tientallen en honderden gigabytes gemeten.

Stappenplan voor de invoering

1. Bereid de versies van de afbeeldingen voor. Maak van elke afbeelding twee kopieën: AVIF en WebP. Bewaar de originele JPG of PNG als laatste fallback.
2. Zet width en height op de tag img. Dat reserveert plaats voor de afbeelding en voorkomt dat de pagina schokt tijdens het laden, wat tegelijk de stabiliteitsscore van de opmaak (de CLS-metriek) verbetert.
3. Voeg loading lazy toe aan afbeeldingen onder de vouw. Die laden pas wanneer de bezoeker er naartoe scrollt, en de eerste schermvulling opent nog sneller.
4. Zet géén lazy op de hoofdafbeelding boven de vouw. Integendeel, geef die juist fetchpriority high, zodat de browser hem als eerste laadt en hij zo vroeg mogelijk verschijnt.
5. Controleer in verschillende browsers. Verzeker je ervan dat de afbeelding overal wordt getoond, en dat moderne browsers daadwerkelijk de lichte AVIF ophalen. Dat controleer je eenvoudig op het tabblad Network in de ontwikkelaarstools: kijk welk bestand precies is geladen.

Invloed op PageSpeed, Core Web Vitals en SEO

Het omzetten van afbeeldingen naar moderne formaten raakt rechtstreeks de zwaarstwegende snelheidsmetrieken waar de zoekmachine rekening mee houdt.

• LCP (weergave van het grootste element). Meestal is het grootste element op het scherm juist de afbeelding boven de vouw. Als die geen 350 kB in JPG weegt maar 140 kB in AVIF, laadt hij merkbaar sneller en verbetert de LCP. Dit is de belangrijkste van de Core Web Vitals, en afbeeldingen beïnvloeden hem het sterkst.
• CLS (verschuivingen in de opmaak). De formaatwijziging zelf beïnvloedt CLS niet, maar bij het invoeren van picture zet je verplicht width en height, en dat neemt het springen van de pagina bij het laden weg. Dubbel voordeel van één handeling.
• Totaalgewicht van de pagina en de PageSpeed-score. De snelheidscontroletools klagen rechtstreeks over zware afbeeldingen en stellen voor over te stappen op moderne formaten. Doe je dat, dan sluit je een van de vaakst voorkomende punten in hun aanbevelingen af, en de totaalscore stijgt.
• Gedragsfactoren en SEO. Een snelle pagina verliest minder bezoekers, heeft een lager bouncepercentage en een grotere kijkdiepte. De zoekmachine ziet dat en tilt zo'n site omhoog. Dat wil zeggen dat het voordeel van lichte beelden niet alleen technisch is, het vertaalt zich in posities en in verkopen.

Veelgemaakte fouten bij de invoering

• De fallback vergeten. Als je alleen AVIF uitlevert zonder reserveopties, laden de beelden bij een klein percentage bezoekers simpelweg niet. Laat altijd minstens WebP of JPG aan het einde van de keten staan.
• Het attribuut type op de verkeerde bron gezet. De browser gaat juist af op de waarde van type bij de tag source. Als je de types door elkaar haalt, kiest hij mogelijk het verkeerde formaat of slaat hij het passende over. Controleer opnieuw dat image/avif bij het AVIF-bestand staat en image/webp bij het WebP-bestand.
• De AVIF-versie te sterk gecomprimeerd. Je hoeft niet tot verlies van kwaliteit naar minimaal gewicht te jagen. AVIF heeft een kwaliteitsinstelling, en te agressieve waarden geven brij en verlies van details. Zoek de balans: meestal geeft kwaliteit in het midden-hoge bereik een uitstekend beeld bij nog altijd laag gewicht.
• De afmetingen in de opmaak niet bijgewerkt. Als de ene versie van de afbeelding andere verhoudingen heeft dan de andere, springt de pagina. Alle versies van eenzelfde afbeelding moeten dezelfde breedte en hoogte hebben.
• AVIF in de download gezet. Denk eraan dat oude software het niet opent. Als je een knop hebt om de afbeelding te downloaden, lever daarmee het vertrouwde JPG of PNG uit en gebruik AVIF alleen voor weergave op de pagina.

Als je geen zin hebt om met dubbele conversie van elke afbeelding aan de slag te gaan, begin dan klein: zet de zwaarste beelden (productfoto's, grote banners, de afbeelding boven de vouw) om naar AVIF met een WebP-reserve, en laat de rest in WebP. Zelfs een gedeeltelijke invoering geeft een merkbare snelheidswinst, en je ziet meteen het verschil in de prestatiescores. En als je aan het proces gewend bent, breid je het geleidelijk uit over de hele site.

Veelgestelde vragen

Is AVIF altijd lichter dan WebP?

Bijna altijd bij foto's, meestal 20 tot 30 procent. Maar op zeer eenvoudige graphics met een paar kleuren of op piepkleine iconen kan het verschil vrijwel verdwijnen, en soms wint WebP zonder verlies zelfs. De regel is deze: neem voor foto's AVIF, controleer voor eenvoudige graphics beide varianten en neem de lichtste.

Verlies ik kwaliteit als ik overstap op AVIF of WebP?

Nee, als je de compressie niet tot het uiterste opdrijft. Bij normale kwaliteitsinstellingen geven de moderne formaten een beeld dat visueel niet van het origineel te onderscheiden is, maar vele malen lichter. Kwaliteit gaat alleen verloren als je de compressie tot het maximum opdraait voor minimaal gewicht, en dat moet je niet doen.

Moet ik de oude JPG's na conversie verwijderen?

Nee, integendeel, laat ze als laatste fallback in de picture-keten staan. Ze wegen vrijwel niets op de schijf en verzekeren je voor het geval van een heel oude browser of een extern systeem dat alleen de klassieke formaten begrijpt.

Ondersteunt AVIF een transparante achtergrond?

Ja, AVIF heeft een volwaardig alfakanaal, net als PNG en WebP. Je kunt er dus zware PNG's met transparantie mee vervangen en een bestand krijgen dat vele malen lichter is bij dezelfde schone transparantie.

Wat kies je voor foto's die gebruikers uploaden?

WebP. AVIF codeert 5 tot 10 keer trager, en de gebruiker moet wachten. Snel WebP toont het resultaat meteen, en als je toch maximale compressie wilt, zet dan de opgehoopte foto's later om naar AVIF, met een achtergrondproces 's nachts.

Is het nu al de moeite waard om over te stappen op JPEG XL?

Voorlopig niet. Het formaat is technisch uitstekend, maar Chrome ondersteunt het niet, en dat is een te groot aandeel bezoekers. Voor een werksite in 2026 is de combinatie AVIF plus WebP betrouwbaarder. Op JPEG XL kom je terug wanneer de ondersteuning in browsers is gegroeid.

Beïnvloedt het beeldformaat de posities in de zoekresultaten?

Indirect, maar merkbaar. Het formaat op zich is geen rankingfactor, maar het verbetert de laadsnelheid en de Core Web Vitals, en die worden wel meegewogen. Bovendien houdt een snelle site bezoekers beter vast, en de gedragssignalen werken ook in jouw voordeel.

Laten we alles wat gezegd is samenvatten in een snel geheugensteuntje, zodat je binnen een minuut kunt beslissen.

• Eén formaat nodig en geen gedoe? Neem WebP. Ondersteuning van 97 procent en meer, codeert snel, een fout maken is onmogelijk.
• Wil je maximale snelheid eruit persen? Neem AVIF voor statische beelden: bestanden zijn 20 tot 30 procent lichter dan WebP en ongeveer twee keer lichter dan JPG.
• Foto's die gebruikers in realtime uploaden? WebP, omdat AVIF 5 tot 10 keer trager codeert.
• Logo, icoon, schermafbeelding? PNG of SVG, of WebP zonder verlies.
• E-mail, sociale media, linkpreview? Klassiek JPG of PNG, de nieuwe formaten worden daar niet ondersteund.
• Wil je het perfect? De picture-tag met de keten AVIF, dan WebP, dan JPG aan het einde als verzekering.
• JPEG XL? Veelbelovend, maar te vroeg: Chrome ondersteunt het nog niet.

Nog een nuttige gewoonte: meet na de invoering van een nieuw formaat het resultaat. Open de snelheidscontroletool van de pagina vóór en na de wijzigingen, vergelijk het paginagewicht en de prestatiescore, en bekijk meteen de LCP-metriek. Zo zie je het concrete cijfer van de winst en begrijp je of het de moeite waard is verder te gaan en de overige beelden om te zetten. Optimalisatie zonder metingen verandert in gokwerk, met metingen wordt het een begrijpelijk, beheersbaar proces.

De hoofdgedachte: AVIF en WebP zijn geen concurrenten in een strijd op leven en dood, maar partners. AVIF geeft de beste compressie, WebP geeft de beste compatibiliteit en codeersnelheid, en de klassieke JPG en PNG blijven een verzekering en een brug naar oude systemen. De combinatie ervan dekt alle gevallen.

Het lastigste in dit verhaal is niet uitzoeken welk formaat beter is, maar de afbeeldingen daadwerkelijk converteren. Om die stap te vereenvoudigen, hebben we een gratis online tool voor fotoconversie naar AVIF. Je uploadt een afbeelding en krijgt een lichte versie in het moderne formaat, klaar voor publicatie op de site.

Belangrijk punt over privacy: alle verwerking gebeurt direct in je browser, op je eigen apparaat. Foto's en documenten worden nergens geüpload en gaan niet naar de cloud, ze verlaten je computer niet. Dat is bijzonder waardevol als je met productfoto's, persoonlijke opnamen of iets vertrouwelijks werkt.

Probeer een paar van de zwaarste afbeeldingen van je site om te zetten naar AVIF en vergelijk het gewicht ervoor en erna. Waarschijnlijk zullen de cijfers je aangenaam verrassen, en je bezoekers zullen je dankbaar zijn voor het snelle laden. Begin met de zwaarste afbeelding op de startpagina, verander die in een paar klikken in een lichte AVIF en meet meteen de snelheid ervoor en erna, daarna gaat het proces vanzelf.