Image-optimalisatie checklist

Stap 1 — converteer naar WebP

WebP is 25-35% lichter dan JPG. Werkt in 99% van browsers in 2026. Convert tools: Squoosh.app handmatig, of ShortPixel/Imagify voor WordPress automatisch. Volledige uitleg: WebP vs JPG.

Stap 2 — schaal naar de juiste dimensie

Eén van de meest voorkomende MKB-fouten: 4000×3000px foto's uploaden voor plekken waar 800×600px genoeg is. Browser downloadt 8x te veel data. Richtlijnen:

• Hero (full-width): 1920px breed maximaal, 1200px voor MKB vaak voldoende
• Inline content-foto's: 1200px breed
• Sidebar/thumbnails: 400-600px breed
• Iconen: SVG of WebP 128px
• Avatar/team-foto: 400×400px

Vuistregel: nooit groter dan 2x de display-grootte. Een foto die 600px breed wordt getoond mag maximaal 1200px breed in bestand (voor retina-schermen).

Stap 3 — implementeer srcset

Eén foto = vier maten. Laat de browser kiezen welke past bij scherm + verbinding:

<img src="hero-1200.webp"
  srcset="hero-480.webp 480w,
          hero-800.webp 800w,
          hero-1200.webp 1200w,
          hero-1800.webp 1800w"
  sizes="(max-width: 640px) 100vw, 1200px"
  alt="..." width="1200" height="800" />

Op WordPress: automatisch sinds WP 4.4 als je theme het gebruikt. Op Webflow: ingebouwd. Op Shopify: ingebouwd via image-API.

Stap 4 — lazy-loading (selectief)

Lazy-loading = de browser laadt foto's pas zodra ze in beeld komen. Bespaart data en versnelt initial paint. Implementatie:

<img src="..." loading="lazy" alt="..." />

Belangrijk: doe dit NIET op je hero-afbeelding. Die moet direct laden — Google straft loading="lazy" op de LCP-element. Pas vanaf de tweede afbeelding op de pagina (en alles eronder).

Stap 5 — width en height attributen

Geef altijd width en height mee in de HTML. Hoeft niet de display-grootte te zijn — alleen de verhouding. Effect: browser reserveert de juiste ruimte, geen CLS (layout shift) als de foto laadt.

<img src="foto.webp" width="1200" height="800" alt="..." />

CSS kan daarna nog steeds width: 100% doen. De attribuut is alleen voor de verhouding-reservering. Zie ook CLS uitleg.

Stap 6 — alt-tags

Alt-tags hebben drie functies:

• SEO: Google leest ze als foto-beschrijving
• Accessibility: screen-readers lezen ze voor aan blinde gebruikers
• Fallback: als foto niet laadt, wordt alt-tekst getoond

Schrijfregels:

• Beschrijf wat er te zien is, niet wat het betekent. "Tuin met grasperk en buxus" niet "Onze mooie tuin".
• Maximaal 125 karakters.
• Geen "afbeelding van" of "foto van" — screen-readers weten al dat het een afbeelding is.
• Decoratieve foto's (achtergronden, dividers): alt="" — leeg maar aanwezig.

Stap 7 — overweeg een CDN

CDN (Content Delivery Network) serveert je foto's vanaf servers dichtbij de bezoeker. Voor lokale MKB met alleen NL-bezoekers: marginale impact. Voor sites met internationale doelgroep of veel verkeer: significant.

Goedkope opties:

• Cloudflare — gratis tier ondersteunt basis-CDN + Polish (auto-WebP-conversie)
• BunnyCDN — €0.005/GB, image-optimalisatie ingebouwd
• Cloudinary — gratis tier 25 GB, image transformation API

Stap 8 — automatiseer voor toekomstige uploads

Foto's optimaliseren is geen one-off klus. Elke nieuwe upload moet door dezelfde pipeline. Tools:

• WordPress: ShortPixel of Imagify met "auto-optimize bij upload" aan
• Shopify: standaard, niets te doen
• Webflow: standaard, niets te doen
• Statische sites: build-step met sharp.js of imagemin

Effect: jij of je collega's hoeven niet meer te denken over WebP-conversie, de CMS doet het.

Resultaten — wat dit oplevert

Voor een gemiddelde MKB-site (30-50 foto's) na deze 8 stappen:

• Pagina-gewicht 50-70% lichter (van 4 MB naar 1.2-1.8 MB)
• LCP 2-3 seconden sneller op mobiel
• Lighthouse mobiel +20-30 punten
• CLS-score onder 0.05 (door width/height-attributen)
• Hosting-bandbreedte daalt 40-60% — soms wordt een hosting-pakket-downgrade mogelijk

Wat dit aan ranking en conversie oplevert: zie traag laden kost bezoekers en de verliescalculator.

Veelgemaakte fouten

• Foto's via mail blijven gebruiken. Een klant mailt een 8 MB JPG voor de site. Direct uploaden = nieuwe trage pagina. Altijd eerst door Squoosh.
• Lazy-loading op de hero. Veroorzaakt 800ms+ LCP-verlies. Check je HTML.
• Background-images zonder optimalisatie. CSS background-image wordt vaak niet door image-plugins gepakt. Optimaliseer handmatig.
• Geen alt-tags op blog-foto's. Mist SEO-kansen, faalt op accessibility-eisen (WCAG).
• Page-builder duplicates. Sommige page-builders maken 6+ varianten per upload — vergroot je media-library zonder dat je het ziet.

Tools-overzicht (top 5 voor MKB)

1. Squoosh.app — handmatige conversie, gratis, beste tool om verschil te zien
2. ShortPixel — WordPress-plugin, € 0-15/maand, automatisch
3. Cloudflare Polish — gratis CDN met auto-WebP, eenmalige setup
4. TinyPNG — bulk-optimalisatie voor PNG/JPG (geen WebP)
5. ImageOptim (Mac) — drag-and-drop bulk-compressie

Wanneer je dit beter uitbesteedt

De 8-stappen-checklist kost typisch 4-8 uur voor een MKB-site met 30 foto's. Als je dat niet hebt, of als de site daarbij nog meer issues heeft, is de gratis audit een goed startpunt. We doen image-optimalisatie ook als losse dienst (€350-€650 vast) of als onderdeel van een rebuild (zie prijzen). Voor MKB in de regio: DesignCheck Mijdrecht.

AVIF — het formaat na WebP

WebP loste de erfenis van JPG op. AVIF is de volgende stap. Ontwikkeld door de Alliance for Open Media, bouwt voort op de AV1-videocodec. AVIF is 20-30% lichter dan WebP bij vergelijkbare kwaliteit. Browser-support staat in 2026 op 94% wereldwijd (Chrome 85+, Firefox 93+, Safari 16+).

Voor MKB-sites die de laatste 0,5 seconde uit hun LCP willen knijpen is AVIF interessant. De aanpak met <picture>:

<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img src="hero.jpg" width="1200" height="800" alt="...">
</picture>

Browser pakt de eerste die hij begrijpt. Oude Safari valt terug op JPG, moderne Chrome pakt AVIF. Nadeel: drie bestanden per foto. Voordeel: gemiddelde paginagrootte zakt nog eens 15-20%. Onze Keurmeesters-site serveert AVIF voor alle decoratieve afbeeldingen en haalde daarmee de mobiele Lighthouse-score van 92 naar 96.

Wanneer AVIF niet de moeite waard is: sites met handmatige upload-flow zonder build-pipeline. Drie varianten per foto verviervoudigt je media-library. Voor zo'n geval volstaat WebP en optimaliseer je je werkflow, niet je formaat.

Een aandachtspunt voor AVIF: de encoder is trager. Een batch van 200 afbeeldingen kan 15-25 minuten kosten op build-time, tegenover 2-3 minuten voor WebP. Voor sites met een CI/CD-pipeline maakt dat niet uit — de build draait in de cloud. Voor lokaal werk op een oudere Mac kan het ergernis opleveren. Tools als sharp.js (Node) of cavif (Rust) zijn de snellere opties. Voor wereldwijde teams die remote samenwerken raden we sharp aan vanwege de stabiele cross-platform performance.

Image-CDN's — wanneer wel, wanneer niet

Een image-CDN doet drie dingen die je server niet doet: hij genereert varianten on-demand, levert vanaf het dichtstbijzijnde edge-knooppunt en cacheet agressief. Voor sites met internationaal of fluctuerend verkeer is dit een meaningful win. Voor een hoveniers-site met 90% van zijn bezoekers binnen 50 km is het marginaal.

De drie populaire opties voor MKB:

• Cloudflare Images. $5 per 100.000 afbeeldingen per maand. Genereert WebP/AVIF on-the-fly, integreert met Cloudflare CDN. Geschikt als je al een Cloudflare-account hebt.
• Cloudinary. Gratis tier tot 25 GB en 25 credits. Krachtige URL-API voor transformaties (resize, crop, watermark, format). Geschikt voor portfolio-sites en webshops met veel media.
• BunnyCDN Optimizer. €9,50 per maand voor unlimited optimalisatie. Goedkoopste optie met goede performance. Geschikt voor sites met groot maar stabiel mediavolume.

Vuistregel: heb je onder 50 afbeeldingen op je site of geen internationale doelgroep, hoeft een dedicated image-CDN niet. Pak Cloudflare's gratis Polish (auto-WebP) en je hebt 80% van de baten zonder maandelijkse kosten.

Een tweede vuistregel die we hanteren: als je remote werkt met klanten over meerdere tijdzones — DesignCheck levert wereldwijd — wordt een image-CDN sneller een goede investering. Bezoekers vanuit Australië of de VS profiteren disproportioneel van edge-levering omdat de afstand naar Europese servers anders honderden milliseconden kost per request.

Build-time vs runtime — twee filosofieën

Er zijn twee manieren om afbeeldingen te optimaliseren. Build-time betekent dat je tijdens deployment alle varianten genereert en als statische bestanden meelevert. Runtime betekent dat een service ze on-the-fly genereert wanneer een browser ze opvraagt.

Build-time wint op snelheid en kosten. Een statisch WebP-bestand uit een CDN-cache wordt in 30-80 ms geleverd, zonder afhankelijkheid van een derde partij. Astro, Next.js en Eleventy hebben image-componenten die tijdens build alle varianten produceren. Daar zit ook geen rate-limit of usage-quota op.

Runtime wint op flexibiliteit. Een redacteur die in een CMS een foto plaatst hoeft niet over varianten na te denken. De image-CDN of een serverless functie genereert ze on-demand bij eerste aanvraag, slaat ze op in cache, en levert ze daarna razendsnel. Voor MKB met veel content-updates is dit prettig.

Onze voorkeur voor de meeste MKB-projecten is build-time met een statische site-generator. Klanten krijgen een editor-interface waarin ze foto's uploaden, de build-pipeline regelt de rest. Geen maandelijkse CDN-kosten, snelste levering, voorspelbare prestaties.

Bij Keurmeesters draait dit pattern in productie. Foto's worden via een admin-interface geüpload, een Vercel-build-hook genereert vier WebP-varianten plus een AVIF, slaat 'em op in Vercel Blob storage en serveert 'em via edge-cache. Mediakosten: nul. Performance: Lighthouse 96/100/100/100 op mobiel met live BAG-API integratie. Het bouwprincipe schaalt van 30 afbeeldingen tot 30.000 zonder ander gedrag.

Volledige image-checklist — 14 punten

1. Inventariseer alle afbeeldingen op je site via de Network-tab van Chrome DevTools. Sorteer op grootte.
2. Identificeer de top-10 zwaarste bestanden. Begin daarbij.
3. Converteer JPG en PNG naar WebP via Squoosh, ShortPixel of een build-pipeline. Quality 80-82.
4. Overweeg AVIF bovenop WebP als je site een geautomatiseerde build heeft.
5. Schaal elke afbeelding naar maximaal 2x de display-grootte. Geen 4000-pixel-bron voor een 600-pixel-thumbnail.
6. Genereer per afbeelding minimaal vier varianten voor srcset: 480w, 800w, 1200w, 1800w.
7. Voeg width/height attributen toe in HTML. De waarde is voor de verhouding, niet de display-grootte.
8. Zet loading="lazy" op alle afbeeldingen onder de fold. Laat de hero zonder lazy attribuut.
9. Voeg fetchpriority="high" toe aan de hero-afbeelding. Browser laadt 'em dan met voorrang.
10. Schrijf zinvolle alt-tags. Beschrijf wat er staat, niet wat het betekent. Decoratieve afbeeldingen krijgen alt="".
11. Activeer Cloudflare Polish of een vergelijkbare auto-WebP-laag op je CDN als je 'em hebt.
12. Stel image-budgets in: hero onder 200 KB, content-afbeelding onder 80 KB, thumbnail onder 30 KB.
13. Automatiseer de pipeline. Eenmalig optimaliseren is verloren werk als nieuwe uploads niet door dezelfde flow gaan.
14. Meet met PageSpeed Insights na elke ronde. Specifiek: scroll naar "Properly size images" en "Serve images in next-gen formats" in de diagnostics-sectie.

Veelgemaakte fouten dieper bekeken

Naast de eerder genoemde fouten zien we in onze audit-historie nog drie patronen terugkomen die de moeite van het noemen waard zijn.

Te hoge JPG-quality. Wordpress-themes en sommige page-builders slaan uploads standaard op met quality 92 of 95. Het verschil tussen quality 82 en 95 is visueel niet zichtbaar, maar het bestand is 40% groter. Eén CMS-instelling kan je hele image-bibliotheek 40% lichter maken zonder kwaliteitsverlies.

Geen poster-images op video. Een <video>-tag zonder poster laat een zwarte plek zien tot de eerste frame binnen is. Dat telt mee als LCP. Voeg altijd een geoptimaliseerde poster-afbeelding toe in WebP — die laadt razendsnel en de browser herkent het als LCP-element.

Hero-video als achtergrond. Een autoplay-video van 8 MB in de hero zorgt voor LCP boven 6 seconden, ongeacht hoe goed je foto's zijn. Vervang door een korte poster-foto (statisch) of door een autoplay video met max 1,5 MB en muted attribuut. Onze regel: heeft de video géén concrete boodschap, vervang door foto.

Stock-images uit Unsplash zonder herwerk. Een directe download van Unsplash levert vaak 5-8 MB JPG's. Mensen plakken die rauw in hun CMS en denken klaar te zijn. De foto's zijn mooi, maar in dit formaat onverkoopbaar als performance. Altijd door een optimalisatie-stap heen. Een vuistregel die we klanten meegeven: zie ik een foto boven 400 KB op je site, dan zit er ruimte voor 50%+ winst.

Image-optimalisatie en LCP — de directe link

Op 78% van de MKB-sites die we auditen is een afbeelding het LCP-element. Dat betekent dat alles wat je aan image-optimalisatie doet rechtstreeks je LCP-score verbetert. Het is geen indirect verband.

Een rekenvoorbeeld. Stel je hero-foto weegt 1,8 MB JPG. Op een 4G-verbinding (10 Mbps effectief) duurt het downloaden alleen al 1,4 seconde. Daarboven komt TTFB van 350 ms, parsing van HTML 80 ms, decoding van het bestand 200 ms. Je LCP zit op 2,0+ seconden voordat je begonnen bent met het optimaliseren van wat dan ook.

Converteer diezelfde foto naar WebP op quality 82, schaal naar 1600 pixels breed. Resultaat: 180 KB. Downloadtijd op 4G: 140 ms. LCP zakt naar 0,9 seconde. Eén ingreep, één seconde gewonnen. Geen rebuild, geen framework-switch, geen plugin-audit.

Dit is de reden dat onze gratis audit altijd begint met een image-scan. Negen van de tien keer zit de grootste winst daar. Pas als afbeeldingen zijn opgelost en LCP blijft hangen boven 2 seconden, gaan we kijken naar hosting, fonts, render-blocking CSS of het framework eronder.

Wat doe je vandaag?

Open je homepage in Chrome. Druk F12 voor DevTools, klik op "Network", filter op "Img". Refresh de pagina. Sorteer op "Size" van groot naar klein. Bovenaan staat je zwaarste afbeelding. Open 'em in een nieuw tabblad, sleep 'em naar squoosh.app, kies WebP op quality 82, klik download. Vervang het bestand op je server of in je CMS. Refresh je pagina. Negen van de tien keer zie je in een nieuwe Lighthouse-meting je LCP zakken met 0,4-1,1 seconde. Eén foto, één avond, één meetbaar resultaat. Doe dit met de top-5 zwaarste afbeeldingen en je hebt deze week meer aan je site gefixt dan een gemiddelde MKB-eigenaar in een kwartaal.

Gerelateerde gidsen

• WebP vs JPG
• LCP fixen 2026
• CLS uitleg
• Diagnose: mijn website is traag

FAQ — image-optimalisatie

Door Lorenzo Ruisi — DesignCheck. Laatst bijgewerkt 16 mei 2026.