Welk formaat, welke maat, welke laadvolgorde? AVIF, WebP, srcset, fetchpriority en lazy loading in gewone taal, met de fouten die de meeste sites maken.

Chris KettmannOprichter · Sales · Design · Development · AI

WebdesignPublicatie 10 november 20266 min lezen

Afbeeldingen voor het web: AVIF, WebP, srcset en lazy loading uitgelegd

Drie keramische lijstjes van groot naar klein met hetzelfde berglandschap en een oranje gloeiende zon, naast een stapel matglazen tegels

Lever afbeeldingen aan als AVIF of WebP, in de maat waarin ze op het scherm staan, met srcset voor verschillende schermen. Geef de belangrijkste afbeelding bovenaan fetchpriority="high" en laad alleen afbeeldingen lager op de pagina lazy. Zet altijd een breedte en hoogte. De meeste sites doen nog minstens één van deze dingen verkeerd (Web Almanac 2025).

Waarom dit uitmaakt: LCP is op vrijwel elk platform de Core Web Vital die het vaakst faalt, en het LCP-element is meestal een afbeelding. De vergelijking per platform staat in Core Web Vitals in 2027.

AVIF of WebP: welk formaat kies je?

Beide zijn veel kleiner dan JPEG bij dezelfde kwaliteit. Google mat voor WebP 25% tot 34% kleinere bestanden dan JPEG bij gelijke beeldkwaliteit (Google for Developers). Voor AVIF zegt web.dev dat de besparing afhangt van het beeld en de instellingen, maar dat zij en anderen meer dan 50% besparing ten opzichte van JPEG zagen (web.dev).

Ondersteuning is geen reden meer om te wachten. Volgens caniuse.com werkt AVIF in browsers die samen ruim 96% van het gebruik dekken, en WebP in ruim 97% (caniuse AVIF; caniuse WebP). Safari ondersteunt AVIF sinds versie 16 op iOS.

Toch gebruikt bijna niemand het. Van de LCP-afbeeldingen op het web is 57% een JPG, 26% een PNG, 11% WebP en 0,7% AVIF (Web Almanac 2025). De meeste sites leveren hun belangrijkste afbeelding dus aan in een formaat waarvoor al jaren een kleiner alternatief bestaat.

Onze vuistregel:

Foto’s: AVIF, met WebP of JPEG als terugval via <picture>.
Logo’s, iconen en illustraties met vlakke kleuren: SVG waar het kan.
Screenshots met tekst: WebP of AVIF lossless, of PNG als het echt scherp moet.
Nooit: een PNG-foto. Dat is de duurste combinatie.

Wie op WordPress zit: sinds versie 6.5 kan WordPress AVIF-bestanden verwerken, zolang de server het ondersteunt (Make WordPress Core). Shopify en Squarespace zetten afbeeldingen zelf om naar WebP. Hoe dat bij Shopify werkt, staat in Shopify-winkel sneller maken.

Wat doen srcset en sizes?

Een telefoon met een scherm van 400 pixels breed heeft geen afbeelding van 2400 pixels nodig. Met srcset geef je de browser een lijst met versies van dezelfde afbeelding in verschillende breedtes, en met sizes vertel je hoe breed de afbeelding op de pagina wordt. De browser kiest dan zelf het kleinste bestand dat scherp genoeg is (MDN).

<img
  src="hero-1200.avif"
  srcset="hero-600.avif 600w, hero-1200.avif 1200w, hero-2000.avif 2000w"
  sizes="(max-width: 768px) 100vw, 50vw"
  width="1200" height="800"
  alt="Werkplaats met gereedschap aan de wand">

De fout die we het vaakst zien: een sizes die niet klopt, of helemaal ontbreekt. Dan gaat de browser ervan uit dat de afbeelding de volle schermbreedte inneemt, en haalt hij een veel te groot bestand op voor een kaartje in een raster van drie. WordPress maakt de verschillende maten automatisch aan bij het uploaden. Of de sizes klopt, hangt af van je thema.

Waarom zijn width en height zo belangrijk?

Zonder breedte en hoogte weet de browser niet hoeveel ruimte hij moet vrijhouden. Hij tekent de pagina alsof de afbeelding nul pixels hoog is en schuift alles omlaag zodra die binnenkomt. Dat is layoutverschuiving en telt mee in CLS. De oplossing is width en height op elke afbeelding, of aspect-ratio in CSS (Web Almanac 2025).

Op mobiel laat 62% van de pagina’s die maten bij minstens één afbeelding weg (Web Almanac 2025). Het is de makkelijkste winst in dit hele artikel.

Wat doet fetchpriority=“high”?

Browsers geven afbeeldingen meestal geen hoge prioriteit, ook niet de grote foto bovenaan die je LCP-element is (Web Almanac 2025). Met fetchpriority="high" vertel je de browser dat deze ene afbeelding voorgaat. In een test op Google Flights verbeterde de LCP daarmee van 2,6 naar 1,9 seconden (web.dev).

Op het web staat het nu op 17% van de mobiele LCP-afbeeldingen (Web Almanac 2025). Gebruik het op één afbeelding per pagina, hooguit twee. Geef je alles hoge prioriteit, dan heeft niets meer voorrang.

WordPress doet dit sinds versie 6.3 automatisch: de kern zet fetchpriority="high" op de afbeelding die waarschijnlijk het LCP-element is. Het WordPress-team rekent op een LCP-verbetering van 5 tot 10% (Make WordPress Core). Page builders en sliders zetten de hero-afbeelding soms als CSS-achtergrond neer. Dan ziet WordPress hem niet en werkt dit niet.

Wanneer gebruik je lazy loading, en wanneer juist niet?

Met loading="lazy" haalt de browser een afbeelding pas op als die in de buurt van het scherm komt. In Chrome is dat op een snelle verbinding 1250 pixels van het zichtbare deel, op een trage verbinding 2500 pixels (web.dev). Voor alles onder de vouw is dat precies wat je wilt: minder downloads bij het laden.

Voor de afbeelding bovenaan is het funest. Google is duidelijk: lazy-load je LCP-afbeelding nooit (web.dev). Toch gebeurt het op ongeveer 16% van de pagina’s (Web Almanac 2025). Meestal komt dat door een plugin of thema dat lazy loading op alle afbeeldingen zet, inclusief de eerste.

De regel is simpel:

Plek op de pagina	`loading`	`fetchpriority`
Hero of grootste afbeelding bovenaan	weglaten (eager)	`high`
Overige afbeeldingen in het eerste scherm	weglaten	weglaten
Alles onder de vouw	`lazy`	weglaten

Hoe controleer je je eigen site?

Open PageSpeed Insights en kijk welk element als LCP-element wordt aangewezen. Is het een afbeelding, noteer dan het formaat en de bestandsgrootte.
Kijk in de broncode of op die afbeelding loading="lazy" staat. Zo ja, haal het weg.
Controleer of er width en height op je afbeeldingen staan.
Open een afbeelding uit een raster in een nieuw tabblad en kijk naar de afmetingen. Is die veel groter dan het vakje waar hij in staat, dan klopt je srcset of sizes niet.

Op een Wix- of Squarespace-site heb je minder knoppen, maar de maat en het gewicht van wat je uploadt, bepaal je wel zelf. Daarover gaat waarom je Wix- of Squarespace-site traag is. Op WordPress hoort dit bij goed onderhoud. Een thema dat de verkeerde maat opvraagt, blijft dat doen tot iemand het ziet. Wij nemen het mee in website onderhoud en bij nieuwe sites via WordPress website laten maken.

Veelgestelde vragen

Moet ik al mijn oude afbeeldingen omzetten naar AVIF?

Niet handmatig. Op WordPress kan een plugin of je host bestaande afbeeldingen omzetten. Shopify, Squarespace en Wix doen de omzetting zelf. Begin bij de afbeeldingen die het LCP-element zijn op je belangrijkste pagina’s. Daar levert het het meeste op.

Hoe groot mag een afbeelding zijn?

Daar is geen officiële grens voor. Squarespace adviseert onder de 500 KB per afbeelding (Squarespace Help Center). Belangrijker is dat de pixelbreedte past bij hoe breed de afbeelding op het scherm staat, met srcset voor grotere schermen.

Is lazy loading slecht voor SEO?

Nee, zolang je de native loading="lazy" gebruikt en de afbeelding in de HTML staat. Het risico zit in JavaScript-oplossingen die de echte bron verstoppen, en in lazy loading op de bovenste afbeelding, wat je LCP vertraagt.