Afbeeldingen optimaliseren voor het web: WebP, AVIF en formaat

Afbeeldingen optimaliseer je voor het web door elke afbeelding in een modern formaat te leveren (WebP of AVIF, met een fallback), op het aantal pixels waarop hij echt wordt getoond, met verstandige compressie, en door hem op het juiste moment te laden: vroeg voor de hoofdafbeelding, lazy voor alles onder de vouw. Heb je die vier dingen op orde, dan zijn afbeeldingen niet langer het zwaarste deel van je pagina's. Deze gids legt elke stap uit, laat zien wat WebP en AVIF echt veranderen en hoe je het resultaat controleert.

Waarom afbeeldingen belangrijk zijn voor snelheid

Op veel contentsites en webshops vormen afbeeldingen het grootste deel van de bytes die een pagina downloadt. Ze bepalen ook een van de drie Core Web Vitals: op veel pagina's is het Largest Contentful Paint-element een afbeelding, meestal een herobanner of een productfoto. Het LCP-artikel op web.dev (Engelstalig) noemt de downloadtijd van de afbeelding als een van de vier delen waaruit de meetwaarde bestaat.

Afbeeldingen beïnvloeden ook de stabiliteit van de lay-out. Een afbeelding zonder gereserveerde ruimte duwt de tekst omlaag zodra hij binnenkomt, en dat telt mee voor de Cumulative Layout Shift. Wil je het volledige beeld van hoe deze meetwaarden samenhangen, lees dan Core Web Vitals uitgelegd.

Het goede nieuws: problemen met afbeeldingen zijn meestal makkelijk te vinden en op te lossen, en de oplossingen raken de logica van je applicatie niet.

Kies het juiste formaat

Elk bestandsformaat heeft zijn eigen taak. Het verkeerde kiezen is een veelvoorkomende oorzaak van te grote bestanden.

Een paar vuistregels:

• Gebruik nooit PNG voor foto's. Een foto die als PNG is opgeslagen, is vaak veel groter dan dezelfde foto als JPEG, zonder zichtbaar voordeel.
• Gebruik SVG voor logo's en iconen in plaats van PNG-sprites. Zorg dat SVG's uit een betrouwbare bron komen, want ze kunnen scripts bevatten.
• Vervang geanimeerde GIF's door video. Een korte MP4- of WebM-loop is veel kleiner dan dezelfde animatie als GIF.

Wat WebP en AVIF echt veranderen

WebP en AVIF zijn nieuwere compressieformaten. Bij dezelfde visuele kwaliteit leveren ze over het algemeen kleinere bestanden op dan JPEG en PNG, en AVIF gaat vaak nog verder dan WebP, vooral bij foto's met vloeiende kleurverlopen. Hoeveel je bespaart, hangt af van de afbeelding en de kwaliteitsinstelling, dus er bestaat geen betrouwbaar universeel getal.

Wat ze niet veranderen: de afmetingen in pixels. Een AVIF van 4000 pixels breed in een kolom van 600 pixels is nog steeds verspilling. Formaat en afmetingen zijn twee aparte problemen, en je moet ze allebei oplossen.

Oudere browsers die een formaat niet begrijpen, hebben een fallback nodig. Dat kun je in de markup regelen met <picture>, of op de server door naar de Accept-header van de browser te kijken en per verzoek het formaat te kiezen.

<picture>
  <source srcset="/images/team.avif" type="image/avif">
  <source srcset="/images/team.webp" type="image/webp">
  <img src="/images/team.jpg" alt="Our team at the office" width="1200" height="800">
</picture>

Lever de juiste afmetingen

Een foto rechtstreeks van een camera of telefoon uploaden en CSS hem laten verkleinen, is de klassieke fout. De browser downloadt nog steeds elke pixel.

Verklein naar de weergavegrootte

Zoek uit hoe breed de afbeelding echt wordt getoond. In een desktoplay-out met een contentkolom van 1200 pixels hoeft een afbeelding over de volle breedte zelden breder te zijn dan ongeveer het dubbele daarvan om scherp te blijven op schermen met een hoge pixeldichtheid. Miniaturen in een productraster hebben veel minder nodig.

Gebruik srcset en sizes

Met responsive afbeeldingen kiest de browser voor elk scherm het juiste bestand:

<img
  src="/images/product-800.jpg"
  srcset="/images/product-400.jpg 400w,
          /images/product-800.jpg 800w,
          /images/product-1600.jpg 1600w"
  sizes="(min-width: 1024px) 50vw, 100vw"
  alt="Blue running shoe, side view"
  width="800" height="800">

srcset somt de beschikbare breedtes op, en sizes vertelt de browser hoe breed de afbeelding in de lay-out wordt. De browser combineert dat met de pixeldichtheid van het scherm en downloadt maar één bestand. De meeste CMS'en, waaronder WordPress, maken bij het uploaden meerdere formaten aan en geven srcset automatisch mee, zolang het thema de standaardfuncties voor afbeeldingen gebruikt.

Comprimeer verstandig

Bij lossy formaten is een kwaliteitsinstelling in het midden tot hogere bereik bij normale weergavegrootte meestal niet van het origineel te onderscheiden. Vergelijk een paar instellingen naast elkaar op een echt scherm in plaats van blind te vertrouwen op één standaardwaarde. Verwijder ook metadata zoals EXIF-gegevens van de camera: die voegen bytes toe en kunnen locatiegegevens prijsgeven die je niet wilde publiceren.

Laad afbeeldingen op het juiste moment

Niet elke afbeelding is even dringend. De browser moet die boven de vouw meteen ophalen en de rest laten liggen tot de bezoeker scrolt.

Lazy-load afbeeldingen onder de vouw

Native lazy loading heeft geen JavaScript nodig:

<img src="/images/gallery-3.webp" loading="lazy" alt="..." width="600" height="400">

Lazy-load nooit de LCP-afbeelding

Dit is de fout die al het andere tenietdoet. Heeft de hero-afbeelding loading="lazy", dan wacht de browser bewust met ophalen, en wordt de LCP slechter. Sommige plug-ins en thema's laden standaard elke afbeelding lazy, dus controleer specifiek de hero.

Voorkom layout shift

Geef afbeeldingen altijd width- en height-attributen (of een CSS-aspect-ratio). Moderne browsers gebruiken die om vooraf de juiste hoeveelheid ruimte te reserveren, ook als CSS de afbeelding responsive maakt met width: 100%; height: auto. Het CLS-artikel op web.dev (Engelstalig) legt uit waarom afbeeldingen zonder afmetingen een van de meest voorkomende oorzaken van layout shift zijn.

Hetzelfde geldt voor afbeeldingen die later worden ingevoegd, zoals carrousels of advertentieplekken: reserveer hun ruimte in CSS, zodat de rest van de pagina niet verspringt.

Cache afbeeldingen goed

Afbeeldingen veranderen zelden, dus browsers en CDN's horen ze lang te bewaren. Stuur Cache-Control-headers met een lange levensduur mee en verander de bestandsnaam (of voeg een versie-query toe) als je een afbeelding vervangt. Zo controleer je wat je server meestuurt:

curl -I https://www.example.com/images/hero.webp

Zoek naar cache-control met een lange max-age. Lever je vanaf dezelfde URL verschillende formaten, afhankelijk van de browser, dan moet het antwoord ook variëren op de Accept-header. Anders kan een cache een WebP-bestand geven aan een browser die het niet kan weergeven.

Zo helpt fast.site je

fast.site zit vóór je bestaande hosting, dus je afbeeldingen blijven waar ze zijn en je CMS werkt zoals altijd. Je laat de nameservers van je domein naar fast.site wijzen, en vanaf dan lopen verzoeken via het edge-netwerk.

De beeldoptimalisatie zet JPEG en PNG direct om naar WebP voor browsers die dat ondersteunen, en omzetting naar AVIF is beschikbaar afhankelijk van je abonnement. Browsers die een formaat niet ondersteunen, krijgen het origineel, zodat je niet voor elke afbeelding <picture>-fallbacks hoeft bij te houden. Net als andere statische bestanden worden afbeeldingen gecachet door de Fast Edge Cache™, dus een cache HIT komt van de edge die het dichtst bij de bezoeker ligt, zonder je server te benaderen.

De optionele instelling voor HTML-optimalisatie preloadt de gedetecteerde hero-afbeelding en voegt breedte en hoogte toe aan afbeeldingen om layout shift te beperken.

Wat fast.site niet doet: te grote uploads verkleinen of bepalen welke afbeeldingen lazy moeten laden. Dat blijft een taak voor je thema en je contentworkflow.

Meet het effect op je eigen site voor en na: vergelijk de overgedragen beeldbytes in het netwerkpaneel van je browser en controleer de LCP op corewebvitals.page. Je kunt het uitproberen met een gratis proefperiode van 7 dagen, zonder creditcard. Bekijk de abonnementen om te zien wat elk abonnement bevat.

Veelgestelde vragen

Is WebP of AVIF beter?

AVIF levert bij vergelijkbare kwaliteit vaak kleinere bestanden op dan WebP, vooral bij foto's, maar het encoderen duurt langer. WebP is een veilige standaardkeuze met brede ondersteuning. Veel sites leveren AVIF waar dat kan, met WebP of het origineel als fallback.

Hoe groot moeten afbeeldingen op een website zijn?

Stem ze af op de grootste weergave van de afbeelding, en lever voor schermen met een hoge pixeldichtheid ongeveer het dubbele van die breedte. Gebruik srcset, zodat kleinere schermen kleinere bestanden downloaden. De volledige resolutie van je camera uploaden is bijna nooit nodig.

Is lazy loading slecht voor SEO?

Native lazy loading met loading="lazy" wordt door Google ondersteund en verbergt afbeeldingen niet voor zoekmachines. Het echte risico zit in de performance: de hoofdafbeelding boven de vouw lazy laden vertraagt de LCP. Gebruik het alleen voor afbeeldingen verderop in de pagina.

Hoe controleer ik of mijn afbeeldingen geoptimaliseerd zijn?

Haal de pagina door corewebvitals.page en bekijk de LCP voor mobiel en desktop. Wil je weten welk element het LCP-element is, open dan het paneel Performance in Chrome DevTools. Filter in het netwerkpaneel van je browser op afbeeldingen en vergelijk bestandsgroottes en formaten. Onze gids over websitesnelheid meten laat zien hoe je een betrouwbare voor-en-natest uitvoert.

Heb ik in WordPress nog een plug-in voor beeldoptimalisatie nodig?

Dat hangt af van je opstelling. Een plug-in die uploads verkleint en comprimeert, helpt nog steeds, want alleen het formaat omzetten lost te grote afmetingen niet op. Regelt je CDN de omzetting naar WebP of AVIF al, dan kun je dat deel van de plug-in meestal uitschakelen, zodat het werk niet dubbel gebeurt. Zie waarom WordPress-sites traag worden voor het grotere plaatje.