1. Onderzoek één beeld op één pagina
Kies een concrete projectkaart of banner. Noteer de pagina, de plaats van het beeld en een smalle en brede schermweergave waarin je het wilt beoordelen. Bewaar het oorspronkelijke beeld en werk met een publicatiekopie. Houd gebruiksrechten en eventuele privégegevens als afzonderlijke voorwaarden in beeld; een technisch klein bestand is niet automatisch geschikt voor openbare publicatie.
De vraag is hier anders dan bij foto’s aan een klant opleveren. Je onderzoekt de uiteindelijke website: wat is zichtbaar, wat wordt opgehaald en waar gaat onnodige beeldinformatie mee? Maak vooraf een eenvoudige controlekaart met pagina, beeld, zichtbare breedte, geladen bestand, bestandsgrootte en visuele bevinding. Zo kun je dezelfde plek na een aanpassing opnieuw vergelijken.
2. Houd zichtbare maat en beeldpixels uit elkaar
Een beeld kan op de pagina 400 CSS-pixels breed staan, terwijl het bestand 4000 pixels breed is. Ook de pixeldichtheid van het scherm speelt mee. web.dev legt uit dat een scherm met een hogere device pixel ratio meer beeldpixels kan gebruiken voor dezelfde zichtbare maat. Alleen de breedte van de afbeelding gelijkmaken aan de schermbreedte is daarom geen volledige keuzehulp.
Vraag je webbouwer welke beeldbreedtes bij deze component horen. Responsive images kunnen verschillende kandidaten aanbieden met srcset en de bedoelde weergavegrootte met sizes. De browser kiest een kandidaat. Dat is iets anders dan één groot bestand met CSS kleiner tonen. Controleer of jouw CMS zulke varianten werkelijk maakt en of de pagina ze ook gebruikt; een uploadscherm alleen bewijst dat niet.
3. Vergelijk uitvoer, niet alleen een kwaliteitsgetal
Maak voor dezelfde uitsnede een paar beperkte proefexports. Vergelijk op de bedoelde weergavegrootte scherpe randen, fijne structuren en rustige kleurverlopen. Bekijk daarnaast de bytes van ieder bestand. Een kwaliteitsinstelling van 80 in het ene formaat of programma is geen universele kwaliteitsmaat voor een ander. web.dev adviseert het compromis tussen bestandsgrootte en zichtbare kwaliteit per beeld te onderzoeken.
Kies het formaat passend bij het beeld en de website. MDN onderscheidt foto’s, die vaak verliesgevende compressie verdragen, van onder meer lijnwerk en schermafbeeldingen waarbij vervaagde tekst of gekleurde randjes snel opvallen. WebP en AVIF zijn relevante opties voor rasterbeelden; controleer ondersteuning en eventuele terugval in je concrete website. Zet een goed vectorlogo niet zonder reden om in een fotoformaat.
4. Bekijk het netwerkverzoek van de echte pagina
Open in Chrome de ontwikkelaarstools en ga naar Network. Schakel voor deze controle Disable cache in terwijl DevTools openstaat, herlaad de pagina en filter op afbeeldingen. Zoek het verzoek dat bij jouw beeld hoort. Controleer de bestands-URL, het type, de voorvertoning en de groottegegevens. Chrome beschrijft ook hoe overgedragen grootte en resourcegrootte afzonderlijk kunnen worden bekeken.
Een bestand dat uit geheugen of cache komt, zegt niet hoeveel een nieuwe bezoeker nu zou moeten ophalen. Noteer daarom de testconditie. Laat je webbouwer bij responsive afbeeldingen ook currentSrc controleren: volgens MDN geeft die eigenschap aan welke beeld-URL de browser heeft geselecteerd. Die waarde alleen bewijst nog niet dat het laden geslaagd is; controleer het verzoek en het zichtbare resultaat erbij.
5. Fictief voorbeeld: de verkeerde variant blijft staan
Een fictieve studio toont een projectfoto in een kaart van 400 CSS-pixels breed. De bron is 4000 pixels breed. Voor een proef op een scherm met pixelverhouding 2 bereidt de bouwer een variant van 800 pixels breed voor. Dit is een rekenvoorbeeld voor die ene kaart, geen vaste exportmaat voor iedere website.
Na uploaden oogt de kaart hetzelfde, maar in Network staat nog de URL van het grote origineel. De export was dus niet het hele probleem. De bouwer controleert de afbeeldingsverwijzing van de component en de instellingen waarmee varianten worden aangeboden. Pas na een nieuwe controle wordt duidelijk welk bestand werkelijk wordt opgehaald. Er worden hier geen gemeten besparingen of snelleresultaten van een echte site gepresenteerd.
6. Controleer mobiel opnieuw, inclusief de uitsnede
Herhaal de controle met een smalle weergave en een verse paginalading. Bekijk niet alleen de bytes: blijft het onderwerp herkenbaar en verdwijnt er geen belangrijk detail door de andere uitsnede? Een kleiner bestand is geen verbetering wanneer de bezoeker het product of uitgevoerde werk niet meer kan beoordelen. Controleer ook een tweede kaart met een ander soort foto.
Laat ruimte voor het beeld reserveren in de pagina. MDN beschrijft dat ontbrekende afmetingen bij beelden ongewenste verschuivingen kunnen veroorzaken wanneer ze laden. Bespreek daarnaast met de bouwer welke afbeeldingen later mogen laden. Pas niet blind dezelfde laadinstelling op alle beelden toe; de zichtbare opening van een pagina heeft een andere rol dan een beeld ver onderaan.
7. Bewaar een bruikbare voor-en-na-notitie
Leg per gecontroleerde situatie de pagina, datum, browser, schermweergave, geselecteerde beeld-URL, afmetingen, groottegegevens en visuele beoordeling vast. Houd een gewijzigd bestand en een gewijzigde websitecomponent uit elkaar. Als alleen het netwerkverzoek is gecontroleerd, schrijf dan niet dat de hele website sneller is geworden. Voor die conclusie is een passende bredere meting nodig.
Rond af met de gewone gebruikersvraag: zie ik het goede beeld zonder onnodig zware levering? Controleer de alt-tekst afzonderlijk, want compressie verandert de betekenis van een afbeelding niet. Dit is aanvullende websitekennis, geen automatische MANE-optimalisatiefunctie. Een lichtere afbeelding levert ook geen rankinggarantie of gegarandeerde vermelding door AI-zoekdiensten op.
