Afbeeldingsoptimalisatie in 2026: AVIF, WebP & Lazy Loading

Afbeeldingen blijven de zwaarste elementen op de meeste webpagina's. In onze builds bij DigiForge zien we regelmatig dat afbeeldingen een aanzienlijk deel van het totale paginagewicht uitmaken. In 2026 is het landschap uitgekristalliseerd: AVIF en WebP zijn de twee moderne formaten om naar te grijpen, responsieve afbeeldingen via srcset zijn basisvoorwaarden, en lazy loading is zo standaard dat het verkeerd doen de prestaties juist kan schaden. Dit artikel destilleert onze praktijkervaring tot een duidelijke, uitgesproken workflow die je op elk project kunt toepassen.

Het juiste formaat kiezen: AVIF versus WebP

Jarenlang was WebP het standaard next-gen formaat. AVIF kwam later, met beloftes van betere compressie en HDR-ondersteuning, maar met hogere encoderingskosten en browserondersteuning die nog niet universeel is (Safari was de laatste achterblijver). Dit is de stand van zaken in 2026:

• AVIF levert doorgaans kleinere bestandsgroottes dan WebP voor dezelfde waargenomen kwaliteit. Het ondersteunt 10-bit kleur, HDR, verliesvrije alpha en zelfs animatie. Encoderen is aanzienlijk langzamer dan WebP, waardoor het minder geschikt is voor real-time generatie, maar prima voor statische assets die tijdens de build worden gebakken.
• WebP wordt universeel ondersteund in elke moderne browser. Het biedt voorspelbare kwaliteit, snelle encoding en uitstekende tooling (cwebp, sharp, imagemin). Voor contentrijke sites waar encodingsnelheid belangrijk is, is WebP nog steeds de pragmatische standaard.
• JPEG XL (JXL) toonde aanvankelijk veelbelovend, maar heeft nooit tractie gekregen in browsers. Chromium heeft de vlag verwijderd en Safari heeft het nooit geïmplementeerd. Verspil er geen tijd aan totdat het landschap verandert.

Onze aanbeveling: Serveer AVIF met een WebP fallback. Gebruik <picture> zodat browsers eerst AVIF kiezen, dan WebP, en dan de originele JPEG/PNG. Dit maximaliseert compressie voor wie het kan gebruiken, terwijl niemand met lege handen blijft staan. De meeste moderne browsers ondersteunen AVIF, dus de fallback is belangrijk maar niet het primaire pad.

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="...">
</picture>

Responsieve afmetingen: niet alleen srcset

Het srcset-attribuut met sizes is algemeen bekend, maar veel implementaties die wij auditen, krijgen sizes verkeerd. De browser gebruikt sizes om te bepalen welke srcset-kandidaat moet worden gedownload – het is niet slechts een suggestie. Een ontbrekende sizes standaardiseert naar 100vw, wat betekent dat de browser mogelijk de grootste afbeelding kiest, zelfs op een klein scherm, wat bandbreedte verspilt.

Voor eenvoudige responsieve afbeeldingen die meeschalen met het viewport, schrijf je:

<img src="image-800.jpg" 
     srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w"
     sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 33vw"
     alt="...">

Maar er zit een nuance. sizes moet de werkelijke CSS-breedte weerspiegelen die de afbeelding op elk breekpunt inneemt, niet de fractie van de viewport. Voor een hero-afbeelding die altijd volledige breedte heeft, is simpelweg sizes="100vw" correct. Voor een galerij waar elke afbeelding een derde van de rij beslaat, gebruik je 33vw. Als de afbeelding padding heeft of zich in een container met een maximale breedte bevindt, moet je de werkelijke weergegeven breedte berekenen — soms is het gebruik van calc() in sizes noodzakelijk.

Breedtedescriptoren versus pixeldichtheid

Gebruik w-descriptoren (bijv. 400w) en sizes voor flexibele afbeeldingen waarvan de weergavegrootte verandert met de lay-out. Dichtheidsdescriptoren (1x, 2x) zijn alleen geschikt voor afbeeldingen met een vaste grootte, zoals logo's of pictogrammen, waarvan je de exacte fysieke afmetingen kent. Gebruik voor inhoudelijke afbeeldingen altijd w – dit geeft de browser echte flexibiliteit om de beste kandidaat te kiezen op basis van viewportbreedte en apparaatpixelverhouding.

Wanneer je <picture> gebruikt voor formaatselectie, moet elke <source> zijn eigen srcset en optionele sizes hebben. Je kunt dezelfde sizes delen over bronnen als de lay-out identiek is, maar vermijd onnodige duplicatie.

Lazy Loading: Native, Intersection Observer of allebei?

Native lazy loading (loading="lazy") wordt sinds 2020 ondersteund in alle grote browsers. Het vereist geen JavaScript, werkt met afbeeldingen en iframes, en is de eenvoudigste weg. Maar het heeft eigenaardigheden die in de praktijk van belang zijn:

• Native lazy loading stelt het laden uit totdat de browser het element dicht bij de viewport acht. De drempelwaarde wordt door de browser bepaald – Chrome gebruikt een ruime marge om vroeg te beginnen met laden; Firefox gebruikt een kleinere marge. Dit betekent dat afbeeldingen in Firefox mogelijk later laden dan verwacht.
• Het werkt niet perfect met srcset in sommige vroege implementaties. Oude Safari-versies (vóór 16.4) hadden bugs. In 2026 zijn deze zeldzaam, maar het is nog steeds de moeite waard om te testen.
• Voor <picture>-elementen moet loading="lazy" op de <img>-tag staan, niet op de <source>-tags.

Wij gebruiken een hybride aanpak: native lazy loading als basis, plus een lichtgewicht Intersection Observer (IO) polyfill voor oudere browsers (hoewel dat in 2026 een nichegeval is). De IO kan ook fade-in animaties activeren of laagwaardige placeholders laden. Onze implementatie:

const lazyImages = document.querySelectorAll('img[loading="lazy"]');

if ('loading' in HTMLImageElement.prototype) {
  // Native lazy loading works – do nothing extra
} else {
  const observer = new IntersectionObserver((entries) => {
    entries.forEach(entry => {
      if (entry.isIntersecting) {
        const img = entry.target;
        img.src = img.dataset.src;
        observer.unobserve(img);
      }
    });
  });
  lazyImages.forEach(img => observer.observe(img));
}

Alles Samenbrengen: Een Praktische Workflow

Bij DigiForge volgen we deze pijplijn voor elk project, of het nu een statische site, een CMS-gestuurde site of een webapp is:

1. Bronafbeeldingen: Ontwerpers leveren in hoge resolutie PNG of TIFF. We bewaren originelen in een _originals-map voor toekomstige hercompressie als er nieuwe formaten opkomen.
2. Formaatgeneratie: Gebruik een Node.js-script met sharp of een Makefile met ImageMagick om AVIF, WebP en fallback JPEG/PNG te produceren op 3–5 breedtes (bijv. 480, 800, 1200, 1920). Voor grote projecten draaien we dit parallel met worker threads om de build te versnellen.
3. Kwaliteitsafstemming: Voer CI-checks uit die bestandsgrootte vergelijken met een perceptuele metriek (SSIM of Butteraugli). We blokkeren pull-requests als het totale afbeeldingsgewicht voor een typische pagina een redelijke drempel overschrijdt op basis van inhoudstype.
4. Markup: Genereer <picture> met type-volgorde (AVIF, WebP, fallback) en <img> met loading="lazy" (behalve eerste hero). Voor responsieve formaten genereren we sizes op basis van de daadwerkelijke CSS – dit komt vaak uit een design tokens-bestand dat gedeeld wordt tussen ontwerp en ontwikkeling.
5. Serveren via CDN: Voor statische sites serveren we vooraf gecodeerde assets via een CDN met lange cache-headers (bijv. Cache-Control: public, max-age=31536000, immutable). Bij gebruik van een image CDN zoals Cloudinary of imgix worden veel stappen geautomatiseerd via URL-transformaties, maar we coderen kritieke afbeeldingen nog steeds vooraf om koude-startkosten te vermijden.

Sites zoals Unsplash [3] en Pixabay [1] bieden hoge-resolutie afbeeldingen die vaak meerdere megabytes wegen in ruwe vorm. Onze pijplijn reduceert ze drastisch zonder waarneembaar verlies. Ook AI-gegenereerde afbeeldingen van tools zoals ChatGPT Images [4] komen vaak in hoge resolutie zonder optimalisatie, dus het doorlopen van dezelfde compressieworkflow is cruciaal. Stockfoto's van Shutterstock [5] of Bing Images [2] hebben vergelijkbare kenmerken – grote bestanden die de prestaties kunnen schaden als ze niet geoptimaliseerd zijn.

Veelvoorkomende valkuilen die we zien (en oplossen)

• sizes volledig missen: De browser downloadt de grootste srcset-kandidaat omdat hij uitgaat van 100vw. Geef altijd sizes op – zelfs een simpele 100vw is beter dan niets.
• JPEG gebruiken voor alles: Veel teams serveren nog steeds alleen JPEG. Vanaf 2026 is er geen excuus meer – WebP en AVIF zijn volwassen en de moeite om ze toe te voegen is minimaal.
• Te veel lazy-loaden: Elke afbeelding met loading="lazy" vertraagt de eerste betekenisvolle weergave. Gebruik loading="eager" voor kritieke afbeeldingen en overweeg de hero-afbeelding vooraf te laden met <link rel="preload" as="image" href="..."> voor maximale LCP-snelheid.
• Geen fallback voor geanimeerde formaten: Als je geanimeerd AVIF gebruikt (met wisselende ondersteuning), bied dan een WebP- of GIF-fallback via <picture>.
• Afbeeldingen on-the-fly coderen in serverless-functies: AVIF-codering is CPU-intensief. Een piek in aanvragen kan time-outs of hoge kosten veroorzaken. Genereer altijd vooraf assets tijdens de build, behalve voor door gebruikers geüploade afbeeldingen die niet vooraf kunnen worden verwerkt.

We hebben ook teams gezien die vertrouwen op een enkele afbeeldingsbron zonder versiebeheer. Wanneer een ontwerper een hero-banner bijwerkt, wordt het oude bestand overschreven, waardoor de CDN-cache wordt verbroken. Gebruik content-hashes in bestandsnamen (bijv. hero-a1b2c3.avif), zodat nieuwe versies een nieuwe URL krijgen en oude versies onbeperkt kunnen worden gecachet.

Aanbevolen tools

Voor ontwikkelaars die de voorkeur geven aan CLI zijn cwebp (van libwebp) en avifenc (van libavif) solide en scriptbaar. Voor Node.js-pijplijnen is sharp onverslaanbaar – het is snel, ondersteunt alle formaten en kan AVIF uitvoeren (vereist libvips gebouwd met AVIF-ondersteuning). Voor ad-hocvergelijkingen gebruiken we Squoosh of compare-tools zoals icdif (Image Compare Diff).

Overweeg voor grootschalige projecten een image-CDN zoals Cloudinary, imgix of Fastly's Image Optimizer. Deze automatiseren het aanpassen van afmetingen en formaatonderhandeling via URL-parameters, en ze verwerken AVIF-codering vaak op hun eigen cachelaag, zodat je de CPU-kosten niet op je oorspronkelijke server betaalt. Houd echter rekening met lock-in en kosten – voor een site met veel afbeeldingen kan de maandelijkse rekening aanzienlijk zijn. Wij raden vaak een hybride aan: genereer de meest voorkomende formaten en formaten vooraf, en laat de CDN zeldzame breekpunten of gebruikersuploads afhandelen.

Als je een CMS of statische sitegenerator gebruikt, zijn er plugins voor de meeste frameworks (bijv. @next/image voor Next.js, gatsby-plugin-sharp voor Gatsby, eleventy-img voor Eleventy). Deze genereren en markup automatisch, maar we raden aan om hun standaardkwaliteitsinstellingen te controleren – ze zijn vaak conservatief (lossless of bijna-lossless) om klachten te voorkomen, wat bytes kan verspillen.

De Bottom Line

Afbeeldingsoptimalisatie in 2026 draait om afwegingen: AVIF bespaart de meeste bytes maar kost CPU; WebP is het betrouwbare midden. Responsieve formaten moeten precies zijn, niet bij benadering. Lazy loading is bijna automatisch, maar vereist doordachte toepassing om LCP niet te schaden. Een goed afgestemde afbeeldingspijplijn kan het pagina gewicht drastisch verminderen – dat is een directe winst voor gebruikerservaring, Core Web Vitals en conversieratio's.

Wij hebben pijplijnen gebouwd voor sites die tientallen miljoenen geoptimaliseerde afbeeldingen per maand serveren. De principes zijn hetzelfde, ongeacht de schaal: codeer tijdens het bouwen, val terug met een goede fallback, pas formaat responsief aan, en laad lui maar niet hebzuchtig. Als je je huidige afbeeldingsstrategie wilt controleren of hulp nodig hebt bij het implementeren van een pijplijn, neem dan contact op met DigiForge – we kunnen het pagina gewicht meestal aanzienlijk verminderen in de eerste ronde.