Afbeeldingen optimaliseren voor een snelle website (WebP, lazy load)

Afbeeldingen optimaliseren voor een snelle website komt neer op vier ingrepen.

Je kiest een licht formaat zoals WebP of AVIF, en je comprimeert en verkleint je bestanden.

Je levert per scherm de juiste maat met responsive images. En je laat alles onder de vouw lazy loaden.

Het verdict: wie afbeeldingen op zijn website optimaliseert, wint meestal meer laadtijd dan met welke andere ingreep ook. Je hero-beeld is de enige uitzondering: dat krijgt juist voorrang.

Beelden zijn doorgaans het zwaarste wat een browser moet downloaden, dus daar valt de meeste snelheidswinst te halen.

Hieronder de vier lagen in volgorde van impact, met de valkuilen die je laadtijd juist verpesten.

Wil je eerst het grotere plaatje, lees dan onze gids om een B2B-website te laten maken.

Dit stuk gaat over snelheid en techniek. Bestandsnamen, alt-tekst en een afbeeldings-sitemap behandelen we in ons artikel over afbeeldingen SEO.

Waarom wegen afbeeldingen zo zwaar op je laadtijd?

Omdat ze letterlijk het zwaarste bestand zijn dat een browser binnenhaalt.

Op de meeste pagina’s vormen beelden het grootste deel van het totale paginagewicht.

Elk megabyte vertaalt zich in wachttijd voor je bezoeker.

Je hero is vaak het element dat Google meet

Een trage hero-afbeelding bovenaan is vaak precies het element dat Google meet als Largest Contentful Paint.

Dat is een van de Core Web Vitals die je laadervaring scoren. LCP meet wanneer het grootste zichtbare element klaar is; meer daarover in wat LCP is.

Zo ziet dat eruit in de velddata van onze eigen site. Kijk naar de LCP-waarde links en naar de eindbeoordeling:

Onze eigen mobiele velddata in PageSpeed Insights, oktober 2026. LCP is goed (1,9 s), maar één zwak meetpunt (CLS 0,13) laat de beoordeling falen.

Een goede LCP volstaat dus niet.

Ook verschuivende beelden kunnen je beoordeling laten zakken.

Waarom dat in B2B net zo hard telt

Voor B2B is de inzet subtieler dan voor een webshop, maar even hard.

Er loopt geen winkelmandje weg, maar een trage eerste indruk zegt onbewust “amateuristisch”.

En een prospect die afhaakt voor je pagina geladen is, vult geen contactformulier in. Hoe snelheid en conversie samenhangen, lees je in de impact van paginasnelheid op SEO en conversie.

Vuistregel: stuur op de bezoeker, niet op het cijfer.

De vier lagen, in volgorde van snelheidswinst:

Welk afbeeldingsformaat kies je: WebP, AVIF, JPEG of PNG?

Kies het lichtste formaat zonder zichtbaar kwaliteitsverlies.

De vraag is dus niet “wat werkt”, maar “wat is het lichtst”. Voor de meeste websitebeelden is WebP vandaag de logische standaard, met AVIF als nog lichter alternatief.

De vijf formaten op een rij

Elk formaat heeft een eigen taak:

WebP wordt al jaren in alle gangbare browsers ondersteund. Het geeft een betere kwaliteit per kilobyte dan JPEG of PNG.

AVIF is doorgaans een flink stuk kleiner bij vergelijkbare kwaliteit. Volgens Can I use ondersteunt ruim 96% van de browsers wereldwijd AVIF (gecontroleerd 4 november 2026).

Je kunt het dus veilig inzetten, zolang je een fallback voorziet.

PNG gebruik je waar je transparantie of haarscherpe details nodig hebt, bijvoorbeeld een productschema.

SVG is ideaal voor iconen en logo’s: vectorgebaseerd, dus scherp op elk scherm en vaak piepklein. Alle grafieken op deze pagina zijn trouwens inline SVG.

Serveer AVIF eerst, met WebP en JPEG als terugval

In de praktijk serveer je het liefst AVIF eerst, met WebP en dan JPEG als terugval.

Dat doe je met een picture-element. De browser kiest de eerste bron die hij aankan, en het img-element blijft de laatste terugval.

Zo ziet dat er in code uit:

<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img src="hero.jpg" alt="Beschrijving van het beeld" width="1200" height="630">
</picture>

Zo profiteert iedereen, zonder dat je oudere browsers in de kou laat staan.

Hoe comprimeer en verklein je afbeeldingen zonder kwaliteitsverlies?

Verklein eerst de afmetingen, comprimeer daarna het bestand.

Comprimeren maakt het bestand lichter, verkleinen past de afmetingen aan. Je hebt allebei nodig, en dit is de stap die de meeste mensen overslaan.

Verkleinen: lever geen pixels die niemand ziet

Upload geen foto van 5000 pixels breed als hij op je site maar 800 pixels getoond wordt.

Die extra pixels download je bezoeker voor niets.

Vuistregel: voor de meeste websitebeelden is maximaal zo’n 2500 pixels ruim voldoende. Thumbnails of achtergronden mogen veel kleiner.

Een voorbeeld: stel, je teamfoto staat in een kolom van 800 pixels breed. Exporteer hem dan op 800 en op 1600 pixels voor scherpe retinaschermen, en niet op de 6000 pixels uit de camera.

Comprimeren: lossy waar het kan, lossless waar het moet

Lossy compressie (zoals bij JPEG en standaard WebP) gooit een beetje data weg die het oog toch niet ziet.

Dat maakt je bestand fors lichter.

Lossless houdt alle data. Gebruik dat alleen waar elk detail telt, zoals een technisch schema met kleine tekst.

Voor een blogbeeld merkt geen enkele bezoeker het verschil tussen een onbewerkte foto en een goed gecomprimeerde versie.

Hoe licht is licht genoeg?

Richtwaarde: ga per beeld zo licht mogelijk, vaak ruim onder een halve megabyte.

Controleer bij hero-beelden of ze echt zo zwaar moeten zijn.

Gratis tools doen het zware werk in een paar klikken. Moderne platformen en een headless CMS kunnen dit vaak automatisch bij het uploaden.

Wil je controleren wat je huidige site doet, draai hem dan door Google Lighthouse. Die geeft je per pagina aan welke beelden te zwaar zijn.

In de netwerkweergave van je browser zie je per beeld hoeveel kilobyte het weegt:

Sorteer op grootte.

Het zwaarste beeld bovenaan is je eerste kandidaat.

Werkt je site op WordPress, dan staan de typische boosdoeners in een trage WordPress-site sneller maken.

Wat zijn responsive images en waarom heb je ze nodig?

Responsive images leveren elk scherm de juiste maat in plaats van overal hetzelfde grote bestand.

Een telefoon krijgt een kleine versie, een breed bureaubladscherm een grote.

Dat scheelt enorm, want het merendeel van het B2B-verkeer komt mobiel binnen. Daar is een bestand van bureaubladformaat pure verspilling. Meer over die mobiele kant in mobiele conversie op een B2B-website.

Hoe regel je dat met srcset en sizes?

Technisch regel je dit met de attributen srcset en sizes op je afbeeldingen.

Met srcset geef je meerdere maten op. Met sizes vertel je de browser hoe groot het beeld op het scherm verschijnt.

De browser kiest dan zelf de meest geschikte versie voor het toestel en de schermresolutie, zoals MDN uitlegt. Oudere browsers negeren de attributen en laden gewoon de src.

Een voorbeeld met twee maten:

<img srcset="team-800.webp 800w, team-1600.webp 1600w"
     sizes="(max-width: 600px) 100vw, 800px"
     src="team-800.webp" alt="Ons team" width="800" height="533">

Goede website-CMS’en en frameworks genereren deze varianten automatisch. Je hoeft dan niet handmatig vijf formaten te exporteren.

Geef elke afbeelding een vaste breedte en hoogte

Een tweede winstpunt is stabiliteit.

Geef elke afbeelding een vaste breedte en hoogte (of een aspect-ratio) mee in je code. Dan reserveert de browser meteen de juiste ruimte.

Je lay-out springt dan niet meer op terwijl beelden inladen. Dat voorkomt een slechte score op Cumulative Layout Shift, het deel van de Core Web Vitals dat verschuivende content afstraft.

Hoe zwaar dat weegt, zie je in ons eigen Search Console-rapport. Let op het aantal URL’s met een CLS-probleem:

Het Core Web Vitals-rapport in onze eigen Search Console, oktober 2026. Het probleem zit in layoutverschuiving, niet in het platform.

Ook wij hebben dus werk.

Vaste afmetingen zijn de goedkoopste fix.

Hoe werkt lazy loading en wat is de valkuil?

Lazy loading laat een afbeelding pas inladen wanneer de bezoeker er bijna bij is.

Zonder lazy loading laadt alles tegelijk bij het openen van de pagina. Beelden onderaan je lange dienstenpagina hoeven nu niet meteen mee, wat de eerste laadtijd flink verkort.

In moderne browsers zet je dit aan met het attribuut loading="lazy" op je afbeelding. Een script heb je daarvoor niet nodig.

De valkuil: nooit je hero lazy loaden

De grote valkuil: lazy load nooit je hero of het belangrijkste beeld bovenaan.

Dat is meestal precies het element dat Google meet. Het uitstellen ervan vertraagt juist de score die je probeert te verbeteren.

web.dev zegt het letterlijk: lazy load geen beelden die bij het laden in beeld staan, en zeker geen LCP-beelden.

Geef je hero juist voorrang met fetchpriority

De omgekeerde beweging helpt wel.

Geef je hero-beeld een hoge laadprioriteit met het attribuut fetchpriority="high". Dan laadt het sneller binnen.

Hoeveel dat kan schelen, toont een test van Google op Google Flights, beschreven op web.dev:

Dat is één test op één site. Maar de richting is duidelijk: voorrang voor het ene beeld bovenaan, lazy loading voor alles eronder.

CDN en caching doen de rest

Aanvullend versnellen twee dingen je site verder:

• CDN: een netwerk van servers dat beelden dichter bij je bezoeker aflevert
• Browser caching: een terugkerende bezoeker downloadt de beelden niet opnieuw

Beide horen eerder bij je hosting en architectuur dan bij de beelden zelf. Ze tellen wel mee in het totaalplaatje.

In welke volgorde pak je afbeeldingen optimaliseren op je website aan?

Niet alles tegelijk: begin bij de ingreep met de meeste impact.

Deze checklist gaat van meeste naar minste impact:

1. Verklein je bronbestanden tot een logische maximale breedte.
2. Comprimeer elk beeld en zet om naar WebP, met AVIF waar je tooling het aankan.
3. Stel responsive images in met srcset en sizes.
4. Geef breedte en hoogte mee tegen verschuivende lay-out.
5. Zet lazy loading aan voor alles onder de vouw, nooit voor je hero.
6. Geef je hero hoge prioriteit met fetchpriority="high".
7. Controleer op mobiel en in Lighthouse, waar de ervaring het zwaarst weegt.

Hoe controleer je of het gewerkt heeft?

Meet na elke stap opnieuw, liefst op dezelfde pagina.

In PageSpeed Insights zie je hoe je LCP is opgebouwd. Kijk vooral naar de vertraging bij het laden van de resource:

LCP-opsplitsing in PageSpeed Insights voor een van onze eigen artikels, labtest op mobiel, oktober 2026. Hoge TTFB wijst op de server, hoge render delay op CSS en scripts.

Is je LCP-element tekst, zoals hier, dan liggen de winsten niet bij beelden maar bij server en CSS.

Ligt het probleem bij de server, kijk dan naar hosting en snelheid. De volledige aanpak per metric staat in Core Web Vitals verbeteren.

Veelgestelde vragen over afbeeldingen optimaliseren

Moet ik al mijn afbeeldingen naar AVIF omzetten?

Niet per se. WebP is een veilige standaard met brede ondersteuning. AVIF is nog lichter en wordt volgens Can I use door ruim 96% van de browsers ondersteund, maar serveer het altijd met een WebP- of JPEG-terugval via een picture-element.

Mag ik lazy loading op alle afbeeldingen zetten?

Nee. Zet lazy loading alleen op beelden onder de vouw. Je hero of het belangrijkste beeld bovenaan laad je meteen, liefst met fetchpriority="high", omdat dat vaak het element is dat Google als Largest Contentful Paint meet.

Hoe groot mag een afbeelding op mijn website zijn?

Zo klein als kan zonder zichtbaar kwaliteitsverlies: vaak ruim onder een halve megabyte per beeld, en maximaal zo’n 2500 pixels breed. Exporteer op de breedte waarop het beeld getoond wordt, met een dubbele versie voor retinaschermen.

Helpen geoptimaliseerde afbeeldingen ook voor SEO?

Ja, onrechtstreeks via snelheid en de Core Web Vitals. Voor vindbaarheid in Google Afbeeldingen tellen ook bestandsnamen en alt-tekst. Die kant behandelen we in ons artikel over afbeeldingen SEO.

De korte samenvatting

Afbeeldingen optimaliseren is geen rocket science, maar wel het detailwerk waarmee je de meeste laadtijd wint.

Werk in lagen: licht formaat, slimme compressie, responsive images en lazy loading. Je hero is altijd de uitzondering die juist prioriteit krijgt.

Doe je dat goed, dan laadt je site snel, blijft je lay-out stabiel en houd je prospects vast.

Bij Customer Impact sturen we op wat telt: leads en omzet, niet op ijdele technische cijfers. We bouwen platform-agnostisch (Webflow, WordPress of headless) en kiezen de aanpak die bij jouw geval past.

Wil je dat je nieuwe of bestaande site echt snel laadt en converteert? Bekijk dan hoe wij je website laten maken.

Neem contact op