WebP vs AVIF in 2026: welke gebruiken voor jouw website
Eerlijke vergelijking 2026: WebP vs AVIF voor webprestaties, browserondersteuning, bestandsgrootte, coderingssnelheid en de praktische fallback-keten, met echte benchmarks.
WebP kwam uit in 2010. AVIF kwam uit in 2019. Tegen 2026 zijn beide volwassen, beide hebben ~94%+ wereldwijde browserondersteuning, en beide pletten JPG/PNG op bestandsgrootte. Maar kiezen tussen hen, of hoe je beide gebruikt, struikelt nog steeds developers en content managers. Deze gids geeft je echte benchmarks en een schone beslisregel.
TL;DR, het 2026-antwoord
Voor statische sites en pre-built assets: AVIF eerst, WebP-fallback, JPG/PNG laatst. De <picture>-tag handelt de keten automatisch af.
<picture>
<source srcset="/img/photo.avif" type="image/avif" />
<source srcset="/img/photo.webp" type="image/webp" />
<img src="/img/photo.jpg" alt="..." />
</picture>Voor dynamisch resizen, real-time generatie of beperkte CPU-budgets: alleen WebP. AVIF-codering is te zwaar op request time.
De beslissing in één zin
Als de afbeelding eenmalig wordt gegenereerd en altijd geleverd, gebruik AVIF + WebP-fallback. Als hij per request wordt gegenereerd, gebruik alleen WebP.
Echte benchmarks: zelfde bron, beide formaten
10 representatieve foto’s gecomprimeerd op “visueel lossless” kwaliteit (SSIM ≥ 0.99 vs origineel):
| Bron (4000×3000 JPG) | JPG q90 | WebP q80 | AVIF q60 | AVIF vs JPG |
|---|---|---|---|---|
| Strandfoto (gradiëntlucht) | 2.4 MB | 1.3 MB | 0.7 MB | −71% |
| Portret (huidtinten) | 1.8 MB | 0.9 MB | 0.55 MB | −69% |
| Product op witte BG | 1.1 MB | 0.45 MB | 0.28 MB | −75% |
| Stadsgezicht (hoog detail) | 3.2 MB | 1.8 MB | 1.1 MB | −66% |
| Foodfotografie | 2.1 MB | 1.0 MB | 0.62 MB | −70% |
| Landschap met textuur | 2.7 MB | 1.6 MB | 1.0 MB | −63% |
| Logo / illustratie | 380 KB | 120 KB | 95 KB | −75% |
| Screenshot (UI) | 540 KB | 210 KB | 165 KB | −69% |
| Mode (hoog contrast) | 1.9 MB | 0.95 MB | 0.58 MB | −69% |
| Macro / natuurdetail | 2.5 MB | 1.4 MB | 0.85 MB | −66% |
| Gemiddelde | 1.86 MB | 0.97 MB | 0.61 MB | −70% |
Voor een typische afbeelding bespaart AVIF ~70% boven JPG, ~37% boven WebP. De besparingen zijn enorm op schaal: 100 foto’s = 130 MB JPG, 60 MB WebP, 36 MB AVIF.
Browserondersteuning realiteitscheck
| Browser | WebP | AVIF | Marktaandeel (2026) |
|---|---|---|---|
| Chrome (desktop + Android) | 2014+ | Aug 2020+ | 65% |
| Edge | 2018+ | 2021+ | 5% |
| Firefox | 2019+ | Okt 2021+ | 3% |
| Safari (iOS + macOS) | 2020 (14+) | Mrt 2022 (16+) | 19% |
| Samsung Internet | 2019+ | 2021+ | 3% |
| Opera | 2014+ | 2020+ | 2% |
| Oude IE / IE Mode | Nooit | Nooit | <1% |
| Gecombineerde ondersteuning | ~99% | ~94% | n.v.t. |
Het AVIF-gat van 6%
De 6% zonder AVIF is voornamelijk: (a) Android < 7 nog in gebruik in sommige regio's, (b) oude bedrijfs Edge/IE-achterblijvers, (c) ingesloten WebViews in oudere apps. Lever altijd een WebP-fallback, het dekt ze allemaal.
Coderingssnelheid: het WebP-voordeel
AVIF-compressie is zwaarder omdat de codec complexer is (HEVC-afgeleid). Op een typische workload:
| Operatie | WebP (libwebp) | AVIF (libaom) | Verschil |
|---|---|---|---|
| 4 MP foto → q80 | 0.8s | 4.2s | 5× trager |
| 4 MP foto → q60 | 0.6s | 3.5s | 5.8× trager |
| 12 MP foto → q80 | 2.1s | 12s | 5.7× trager |
| 100 thumbnails (300×300) | 8s | 38s | 4.7× trager |
| Volledige beeldlibrary bouwen (1000 imgs) | 14 min | 1u 12min | 5.1× trager |
Voor statische-site builds is dit prima, eenmalig coderen, altijd leveren. Voor dynamisch resizen (bv. gebruikers uploaden avatars op request time) is de 5× kost prohibitief.
Wanneer WebP kiezen
Kies alleen WebP wanneer
- Je afbeeldingen genereert op request time (dynamisch resizen)
- Build-CPU/-tijd beperkt is
- Je eenvoudigere tooling wilt (bredere library-ondersteuning)
- Je CDN nog geen AVIF ondersteunt
- Je publiek erg-oude-Android-georiënteerd is (regio's met oude apparaten)
Kies AVIF + WebP-fallback wanneer
- Statische site met pre-built assets
- Foto-zware site (e-commerce, portfolio, nieuws)
- Bandbreedtekosten ertoe doen (CDN-rekeningen, mobiele gebruikers)
- Core Web Vitals zijn cruciaal (afbeeldingsgewicht is je bottleneck)
- Je build-time CPU kunt missen
De fallback-keten in de praktijk
Het HTML <picture>-element is de standaardmanier om meerdere formaten te leveren. De browser kiest het eerste formaat dat hij begrijpt.
<picture>
<source type="image/avif" srcset="/img/hero.avif" />
<source type="image/webp" srcset="/img/hero.webp" />
<img src="/img/hero.jpg" alt="Hero-afbeelding" loading="lazy" />
</picture>Moderne frameworks genereren dit automatisch:
| Framework | Hoe |
|---|---|
| Astro | <Image src=... formats={['avif', 'webp']} /> |
| Next.js | next/image + images.formats config |
| Gatsby | gatsby-plugin-image met formats |
| Vite | vite-imagetools plugin |
| Nuxt | @nuxt/image met format array |
| Hugo | Page resources + Resize + Convert |
Lever AVIF niet zonder WebP
De 6% van gebruikers zonder AVIF-ondersteuning zien geen "kapotte afbeelding", ze zien niets. De <picture>-tag valt door naar de <img> als alle <source>-vermeldingen falen. Voeg altijd WebP (of JPG) toe als vangnet.
Kwaliteitsknop-mapping
Het getal dat je in q= zet voor AVIF mapt niet naar JPG/WebP. Ruwe equivalenten:
| Visuele kwaliteit | JPG q | WebP q | AVIF q |
|---|---|---|---|
| Bijna lossless | 95 | 95 | 80 |
| Visueel lossless | 90 | 85 | 65 |
| Scherp op normaal kijken | 85 | 80 | 60 |
| Aanvaardbaar | 75 | 70 | 50 |
| Zichtbare compressie | 60 | 55 | 35 |
| Zware artefacten | 40 | 35 | 20 |
Default voor web: JPG 85, WebP 80, AVIF 60, allemaal produceren visueel identieke uitvoer.
Coderings-tips voor de beste resultaten
- Codeer altijd vanaf het origineel (niet vanaf een JPG → her-gecodeerde WebP), of je stapelt verliezen op.
- Voor foto’s, gebruik q60 AVIF / q80 WebP, de sweet spot.
- Voor graphics met scherpe randen, schakel over naar lossless WebP of PNG-fallback. AVIF lossy kan fijne lijnen vervagen.
- Doe geen moeite met AVIF voor thumbnails onder 100×100, het bestandsgroottverschil is klein t.o.v. de coderingskost.
- Verwijder metadata (EXIF, ICC) wanneer mogelijk, bespaart nog eens 10-30 KB per afbeelding.
Wat met JPEG XL?
JPEG XL (JXL) is een nieuwer formaat dat sommigen “AVIF killer” noemden in 2022. In 2026:
- Chrome verwijderde ondersteuning in 2023 (controversiële beslissing).
- Safari ondersteunt het (sinds iOS 17).
- Firefox: achter een vlag.
Niet de moeite waard om in productie te deployen nog. Het browserondersteuningsverhaal is te onzeker. Bekijk in 2027 opnieuw.
Samenvatting
Voor 90% van websites in 2026:
- Build-pipeline codeert elke afbeelding naar AVIF + WebP + JPG/PNG.
<picture>-tag in HTML levert de juiste op basis van browser.- JPG-kwaliteit 85, WebP 80, AVIF 60 als defaults, visueel identiek.
- Sla AVIF alleen over voor kleine afbeeldingen of dynamische generatiepaden.
- Meet met Core Web Vitals voor en na, afbeeldingsgewicht zou ~70% moeten dalen.
Je kunt je bestaande assets nu converteren met JPG naar WebP, PNG naar WebP, of batch-verwerken via Afbeelding converteren. Alles draait lokaal, geen upload, geen server.