Lazy loading voor afbeeldingen: wanneer wel en wanneer niet?

Wat verandert lazy loading?

Lazy loading verandert wanneer de browser een afbeelding opvraagt. De pixelafmetingen, het formaat en de compressie blijven gelijk. Op een lange receptenpagina heeft een bezoeker het begin meteen nodig, maar bereikt die misschien nooit de vijftien foto's aan het einde. Die later opvragen kan onnodige downloads bij het openen voorkomen.

Er zijn drie aparte taken. Verkleinen haalt overbodige pixels weg, compressie vermindert de hoeveelheid gegevens en lazy loading stelt de aanvraag uit. Een grote afbeelding blijft zwaar wanneer ze uiteindelijk laadt. Een kleine kan laat verschijnen als de aanvraag te lang wacht.

Bereid geschikte afmetingen voor met de tool om afbeeldingen te schalen en vergelijk zo nodig de compressie. Bepaal daarna welke beelden direct nodig zijn. De gids over bestandsgrootte behandelt de voorbereiding; hier gaat het om het laadmoment.

Aan de slag zonder te programmeren

Je hoeft geen HTML te bewerken om te bepalen welke beelden eerst moeten laden. Begin met een productpagina of lang artikel. Met het eerste scherm bedoelen we het deel dat je ziet vóór het scrollen.

1. Zoek de bestaande instelling. Kijk in het websitebeheer bij thema, afbeeldingen of prestaties naar “lazy loading” of “afbeeldingen uitgesteld laden”. Naam en plaats verschillen; sommige diensten regelen dit automatisch. Vraag de beheerder om hulp voordat je een extra plug-in installeert.
2. Houd het eerste scherm beschikbaar. De hoofdfoto en meteen zichtbare beelden moeten normaal laden. Zoek uit hoe eventuele uitzonderingen werken. Zet geen algemene regel aan voordat je weet wat er met de hoofdfoto gebeurt.
3. Probeer beelden verderop. Latere artikelillustraties zijn een goed begin. Gebruik zo mogelijk een voorbeeld- of testpagina en controleer daarna de gepubliceerde versie. Test galerijen apart, want bezoekers kunnen snel wisselen.
4. Controleer het lezen. Open op telefoon en computer. Verschijnt de hoofdfoto vlot? Zijn volgende beelden op tijd bij langzaam en snel scrollen? Springt tekst zodra een beeld verschijnt? Probeer ook een link naar een lager onderdeel.

Ontstaat een probleem, draai dan je laatste wijziging terug en vraag hulp voor die pagina. Dit onthult duidelijke vertragingen en verschuivingen, maar bewijst geen snelheidswinst. Daarvoor heb je metingen nodig; het testonderdeel vertelt welke.

Je kunt de beheerder vragen: “Controleer lazy loading op deze pagina. Laat de hoofdafbeelding en meteen zichtbare beelden normaal laden, stel geschikte beelden verderop uit en reserveer hun ruimte zodat tekst niet springt. Test op mobiel en desktop en vergelijk de laadtijd van de hoofdafbeelding vóór en na de wijziging.” Voeg de paginalink toe en noem beelden die laat verschijnen.

Welke afbeeldingen kun je later laden?

Open een typische pagina zonder te scrollen. Noteer welke afbeeldingen zichtbaar zijn en het verhaal helpen begrijpen. Herhaal dit op een smalle telefoon en een breed computerscherm: banner, titel en productgalerij kunnen anders geplaatst zijn.

Ga uit van de echte plaats, niet van bestandsnamen of uploadvolgorde. De eerste foto in de mediabibliotheek hoeft niet de eerste op de pagina te zijn. Een foto na een lange inleiding kan in een ander sjabloon meteen zichtbaar worden.

Staat hetzelfde beeld op desktop direct in beeld en op mobiel verderop, dan is normaal laden de veiligere start. loading heeft geen mediaquery zoals picture. Voeg niet speciaal een script voor schermformaten toe om één aanvraag te besparen. Controleer eerst of die aanvraag merkbaar belastend is.

Een verborgen galerijbeeld wordt niet gegarandeerd uitgesteld. Galerijscripts kunnen onafhankelijk van de attributen vooruit laden. Test snel doorklikken en teruggaan naar eerdere beelden, niet alleen scrollen.

Waarom de hoofdafbeelding niet moet wachten

Largest Contentful Paint (LCP) meet hoe snel het grootste inhoudselement in het eerste scherm zichtbaar wordt. Vaak is dat de hoofdfoto, soms een tekstblok. Zoek het op in het prestatierapport. Is het een afbeelding, stel de aanvraag dan niet uit. Een adres in de oorspronkelijke HTML laat de browser eerder beginnen; een adres dat pas na een script verschijnt kan extra vertraging geven.

Lazy loading weghalen lost niet elke trage hoofdfoto op. Serverreactie, downloadgrootte en weergave kunnen blijven vertragen. Googles gids voor LCP-optimalisatie onderscheidt deze fasen. De Pixilo-gids over Core Web Vitals helpt laadproblemen van verschuivende inhoud te onderscheiden.

Gebruik fetchpriority="high" gericht voor een aantoonbaar belangrijk beeld. Hoge prioriteit voor alle galerijbeelden geeft geen nuttige volgorde. De hint heft lazy loading ook niet op.

Controleren wat CMS en galerij al doen

Inspecteer vóór een nieuwe plug-in het gepubliceerde beeld. CMS, thema of optimalisatiedienst kunnen het attribuut al toevoegen. Kijk naar de uiteindelijke HTML en de aanvraag, niet alleen een naam als “beeldoptimalisatie”.

Beheer het gedrag op één plek. Vervangt een script adressen, voegt het omhullende elementen toe of laadt het galerijbeelden vooruit, dan maakt een tweede aanpak de diagnose lastiger. Begin op één pagina en sluit de hoofdfoto uit van uitstel.

Een CSS-achtergrond is een apart geval: het laadattribuut van img past niet op een achtergrondregel. Vraag de sjabloonbeheerder hoe die bron wordt ontdekt. HTML in een inhoudsblok plakken verandert niet de achtergrond van het thema.

Native lazy loading toevoegen in HTML

Bewaar voor een illustratie duidelijk onder het eerste scherm het echte adres in src en voeg het laadattribuut toe. Vervang de voorbeeldpaden door eigen bestanden. Alt-tekst beschrijft wat het beeld toont; receptinstructies horen in de gewone tekst. Een puur decoratief beeld krijgt alt="".

<img
  src="/images/recipe-step-04.webp"
  width="1200"
  height="800"
  loading="lazy"
  alt="Deeg over de vulling gevouwen, met de randen nog open"
>

Een foto die in het eerste scherm als LCP is gemeten, vraagt een andere keuze:

<img
  src="/images/finished-loaf.webp"
  width="1200"
  height="800"
  loading="eager"
  fetchpriority="high"
  alt="Versgebakken brood met een goudbruine korst"
>

eager betekent normaal laden. loading weglaten heeft doorgaans hetzelfde effect. De expliciete waarde helpt als een sjabloon anders automatisch lazy loading toevoegt. Het betekent niet “meteen klaar”. De MDN-uitleg over het afbeeldingselement beschrijft de attributen.

De browser bepaalt wanneer een beeld dichtbij genoeg is om op te vragen, soms vóór het zichtbaar is. Een aanvraag buiten beeld bewijst dus geen fout. Gebruik geen vaste scrollafstand als testcriterium. Lees de web.dev-gids voor native lazy loading.

Ruimte reserveren en passende varianten behouden

Geef bij width en height de pixelafmetingen van de bron op, hier 1200 × 800. Ze bepalen de verhouding; CSS kan het beeld kleiner tonen. Deze getallen op een andere verhouding kopiëren reserveert verkeerde ruimte. Voor schalen zonder uitsnede:

.article-image {
  display: block;
  max-width: 100%;
  height: auto;
}

Voeg class="article-image" toe of pas een bestaande regel aan. Bij een vaste uitsnede reserveer je de getoonde oppervlakte. Controleer de echte indeling: andere CSS kan de regels overschrijven.

Lazy loading vervangt srcset en sizes niet. Bewaar bruikbare varianten voor de bestandskeuze. Binnen picture hoort de laadinstelling op img. De gids voor responsieve afbeeldingen bevat complete voorbeelden.

De gepubliceerde wijziging testen

1. Leg de uitgangssituatie vast. Noteer URL, vensterformaat, LCP-element en -tijd, start van de hoofdfotoaanvraag en overgedragen beeldgegevens vóór het scrollen. Noteer of het een eerste bezoek of test met cache is.
2. Bekijk de aanvragen. Open Network vóór het herladen en filter afbeeldingen. Welke bestanden worden eerst opgevraagd en wanneer starten ze?
3. Wijzig één laadregel. Haal bijvoorbeeld uitstel van de hoofdfoto weg of zet het voor latere illustraties aan.
4. Bevestig de gepubliceerde versie. Controleer attributen en adressen nadat je waar nodig caches ververst. Een lokale wijziging verandert de openbare pagina nog niet.
5. Herhaal en scroll. Vergelijk gelijkwaardige tests. Scroll langzaam en snel, gebruik galerijen en onderdeel-links. Let op lege plekken en verspringende inhoud.

“Disable cache” schakelt de browsercache uit zolang de ontwikkelaarstools open zijn, maar wist geen server- of CDN-cache. De Chrome-documentatie voor Network legt het uit. Houd de netwerkcondities gelijk en vergelijk meerdere runs, niet alleen de beste.

Begin bovenaan met hetzelfde venster, dezelfde verbinding en dezelfde observatieduur vóór het scrollen. Leg eerst de beginwaarden vast, anders verstoren latere aanvragen de vergelijking. Een herstelde scrollpositie kan een beeld verderop ook direct laten laden.

Een goede wijziging maakt het eerste scherm snel beschikbaar en toont volgende beelden wanneer nodig. Minder vroege aanvragen helpen alleen als lezen en navigeren soepel blijven. Gebruik de PageSpeed-gids om resultaten te vergelijken.

Voorbeeld: één omslagbeeld en twaalf illustraties

Een lang artikel heeft een omslagbeeld in het eerste scherm en twaalf foto's verderop. Een algemene instelling stelt alle dertien uit. De omslag verschijnt op mobiel laat ondanks een klein bestand. Dit illustreert een aanpak, geen gemeten snelheidswinst.

Controleer of de omslag het LCP-element is. Verwijder het uitstel en test alleen die wijziging. Houd selectief uitstel voor latere beelden met gereserveerde ruimte. Is de eerste illustratie op desktop meteen zichtbaar, laat die dan ook normaal laden.

Vergelijk na publicatie de start van de aanvraag en LCP onder gelijke omstandigheden. Controleer alle twaalf foto's en spring via een onderdeel-link. Komt de omslag vroeg aan maar houdt een animatie hem verborgen, onderzoek de weergavevertraging in plaats van het laadattribuut opnieuw te wijzigen.

Afbeeldingen vindbaar houden

Gebruik passende alt-tekst en een echte bron. Houdt een script alleen een tijdelijke aanduiding vast tot iemand klikt of scrollt, onderzoek het dan. Googles advies voor uitgesteld geladen inhoud beveelt laden bij binnenkomst in beeld aan, zonder afhankelijkheid van een gebruikersactie.

Bekijk zo nodig de gerenderde pagina met URL-inspectie in Search Console. Staan belangrijke beeldadressen in de gerenderde HTML? Een prestatie-instelling garandeert geen indexering van alle beelden of betere posities.

Veelgestelde vragen

Moet elk beeld lazy loading gebruiken?

Nee. Kies op plaats en belang. Beelden die meteen nodig zijn, vooral het LCP-beeld, horen niet te wachten.

Wordt het bestand kleiner?

Nee, de aanvraag verschuift. Verklein of comprimeer een aparte kopie als pixels of bestandsgrootte het probleem zijn.

Heb ik een JavaScript-bibliotheek nodig?

Niet voor native lazy loading van gewone HTML-afbeeldingen. Bij uitgeschakeld JavaScript vervalt het uitstel en laden beelden met echte bronadressen normaal. Een script dat het enige adres in data-src bewaart heeft een terugvaloptie nodig. Kies maatwerk alleen voor een concrete behoefte en test het goed.

Waarom laden sommige beelden buiten beeld meteen?

Ze kunnen dichtbij genoeg zijn of door een ander onderdeel worden voorgeladen. Controleer de aanvrager en de galerij- of thema-instellingen voordat je een fout aanneemt.

Vervangt asynchroon decoderen lazy loading?

Nee. decoding gaat over decoderen en tonen, loading over uitstel. De ene instelling zegt niets over de andere.

Samenvatten metChatGPT (opent in een nieuw tabblad)Grok (opent in een nieuw tabblad)Google (opent in een nieuw tabblad)Perplexity (opent in een nieuw tabblad)Claude (opent in een nieuw tabblad)