Een afbeelding van 1920 pixels breed op een pagina wordt ook door telefoongebruikers helemaal gedownload en daarna op het scherm teruggeschaald naar 390 pixels: vijf keer zoveel bandbreedte en een tragere pagina, zonder dat het iets oplevert. Met srcset kiest de browser de versie die bij het scherm past, mits jij die versies hebt gemaakt.
Waarom één afbeelding niet genoeg is
De LCP-waarde in Core Web Vitals is meestal de grote afbeelding boven de vouw. Geef je een telefoon een bestand van 1920 breed en 400 KB, dan haalt de LCP zelden 2,5 seconden; een versie van 480 breed en 40 KB is op dezelfde verbinding een orde van grootte sneller. Het paginaervaringssignaal van Google leest dat getal rechtstreeks.
Omgekeerd ziet een afbeelding van 768 breed er op een groot bureaubladscherm zacht uit. Vandaar meerdere formaten, waaruit de browser kiest.
Een praktische breakpointtabel
Breakpoints volgen de breedte waarmee de afbeelding op de pagina wordt weergegeven, niet de viewport. Voor de twee meest voorkomende gevallen, bannerafbeeldingen over de volle breedte en afbeeldingen in artikelen:
- Afbeeldingen over de volle breedte (hero, banners): 480, 768, 1200, 1920. Telefoon, tablet, laptop, groot scherm.
- Artikelafbeeldingen (inhoudskolom tot ongeveer 800): 400, 800, 1200; de 1200 bedient schermen van 1,5x–2x.
- Thumbnails en kaarten (weergegeven rond 300): 300 en 600.
Meer stappen is niet beter. Elke stap is een extra export en een extra bestand om op te slaan, en browsers kunnen een afwijking prima hebben; stappen die 1,5–2x uit elkaar liggen zijn de sweet spot. Vier stappen dekken meer dan negen van de tien apparaatcombinaties.
Heb je 2x-versies nodig?
Retina- en de meeste telefoonschermen werken met 2x–3x pixeldichtheid; een afbeelding die 400 breed wordt weergegeven, heeft daar 800 pixels nodig om scherp te ogen. De grotere stappen uit de tabel fungeren al als 2x-versie van de kleinere – 768 is 2x voor een telefoon van 390 breed, 1200 is 2x voor een kolom van 600 breed.
Een aparte „@2x“-set is dus overbodig. Houd ongeveer een factor 2 tussen de stappen en de browser kiest op basis van de dichtheid de hogere.
Formaat: eerst WebP, JPG als terugval
Bij gelijke kwaliteit is WebP 25–35 procent kleiner dan JPG en elke moderne browser ondersteunt het. Exporteer WebP op elk formaat en bewaar via het picture-element een JPG als terugval voor oude browsers; als browsers van vóór 2020 voor je publiek niet meer meetellen, volstaat WebP alleen.
AVIF is nog kleiner, maar wordt in de browser veel trager gecodeerd, wat bij grote batches pijn doet. AVIF, WebP en JPEG vergeleken behandelt de afwegingen uitgebreid.
De hele set in één keer exporteren
Zet de bronafbeeldingen in Batchverwerking van afbeeldingen en draai per stap één keer, waarbij je telkens de breedte en het achtervoegsel aanpast:
- Formaat: breedte 480, Kleine afbeeldingen mogen vergroot worden uit, uitvoer WebP op 80 procent, achtervoegsel -480.
- Dezelfde instellingen op 768 met achtervoegsel -768; daarna 1200; daarna 1920.
- Voor een JPG als terugval zet je de uitvoer op JPG, houd je de achtervoegsels en draai je opnieuw.
Elke run duurt seconden en de ZIP bevat al hero-480.webp, hero-768.webp enzovoort, klaar voor de afbeeldingenmap. Laat vergroten uit, zodat een origineel van 1000 pixels nooit naar 1920 wordt uitgerekt.
Wil je het verschil in grootte per stap op één afbeelding zien, probeer dan Afbeeldingen vergroten/verkleinen op een enkel bestand.
De HTML schrijven
Voor een afbeelding over de volle breedte:
<img src="hero-1200.jpg"
srcset="hero-480.webp 480w, hero-768.webp 768w, hero-1200.webp 1200w, hero-1920.webp 1920w"
sizes="100vw" width="1920" height="1080" alt="...">Zet bij artikelafbeeldingen sizes op de echte breedte, bijvoorbeeld sizes="(max-width: 840px) 100vw, 800px". Geef altijd width en height op, zodat de browser ruimte reserveert en de pagina niet verspringt.
Voeg daarna de tips over lazy loading en compressie uit afbeeldingen sneller laten laden toe en het afbeeldingsdeel van je prestatiescore is vrijwel maximaal.