Contact

Wat is lazy loading voor SEO: checklist voor webprofessionals

door | jul 30, 2026 | SEO | 0 Reacties

Webspecialist onderzoekt de prestaties van lazy loading

Lazy loading is goed voor SEO, maar alleen als je het correct toepast. Zet het verkeerd in en je sloopt je eigen LCP-score. De conclusie: gebruik loading="lazy" op alle afbeeldingen die niet direct zichtbaar zijn, en gebruik het nooit op je hero-afbeelding.

  • Hero/LCP-afbeelding: zet deze altijd op loading="eager" of gebruik rel=preload. Lazy loading op je LCP-element is de snelste manier om je Core Web Vitals te slopen.
  • JavaScript-complexiteit: hoe meer maatwerk-JS je lazy loading aanstuurt, hoe groter de kans dat Googlebot content mist. Native HTML-attributen zijn veiliger.
  • Site-type: webshops en blogs met veel media profiteren het meest. Een brochuresite met vijf afbeeldingen heeft er nauwelijks baat bij.

Wat nu direct doen? Controleer je hero-afbeelding, zet de rest op loading="lazy" en draai een Lighthouse-test om je LCP te meten.

Pro-tip: Gebruik de URL Inspection in Google Search Console om te controleren of Googlebot je lazy-loaded afbeeldingen daadwerkelijk ziet na rendering.

Iemand zit achter zijn laptop en bekijkt de statistieken in Google Search Console.

Inhoudsopgave

Wat is lazy loading?

Lazy loading betekent dat een browser een afbeelding, video of iframe pas laadt op het moment dat het element in of vlak bij het zichtbare scherm verschijnt. Alles wat de bezoeker nog niet ziet, laadt nog niet. Pas als iemand naar beneden scrollt en het element in beeld komt, stuurt de browser het verzoek naar de server.

Stel je voor dat je een grote kast hebt met honderd laden. Je opent alleen de la die je nu nodig hebt, niet alle honderd tegelijk. Zo werkt lazy loading: de browser haalt alleen op wat de bezoeker op dit moment nodig heeft.

Twee concrete voorbeelden:

  • Een productpagina in een webshop met 40 productafbeeldingen. Zonder lazy loading laadt de browser alle 40 afbeeldingen tegelijk, ook de 35 die de bezoeker nog niet ziet. Met lazy loading laadt alleen wat boven de vouw staat.
  • Een blogpost met een ingesloten YouTube-video halverwege de pagina. Het iframe laadt pas als de bezoeker er naartoe scrollt.

Er zijn twee manieren om lazy loading te implementeren: via het native loading="lazy" attribuut in HTML, of via JavaScript zoals de IntersectionObserver API of een library als lazysizes. Het native attribuut is in de meeste gevallen de betere keuze.

Hoe beïnvloedt lazy loading je SEO?

Positieve effecten

Lazy loading verlaagt het aantal initiële HTTP-verzoeken dat de browser bij het laden van een pagina verstuurt. Bij pagina’s met veel media kan dat het aantal initiële verzoeken flink terugdringen, waardoor de browser sneller prioriteit geeft aan tekst, CSS en kritische scripts. Het resultaat: een snellere eerste weergave en een betere Largest Contentful Paint (LCP).

Infographic: de voor- en nadelen van lazy loading voor SEO op een rij

Op mobiel is het voordeel nog groter. Mobiele netwerken hebben beperkte bandbreedte en datalimieten, waardoor uitgesteld laden direct merkbaar is voor de gebruiker. Minder data bij het eerste laden betekent snellere weergave en minder kans dat bezoekers afhaken.

Negatieve effecten en risico’s

Hier gaat het mis bij de meeste implementaties. Drie veelgemaakte fouten:

  • Hero-afbeelding lazy-loaden. De LCP meet hoe snel het grootste zichtbare element laadt. Als dat element lazy-loaded is, wacht de browser tot de gebruiker “scrollt” voor iets wat al in beeld staat. LCP gaat omhoog. Rankings gaan omlaag.
  • Maatwerk-JavaScript voor lazy loading. Google kan veel lazy-loading patronen verwerken, maar complexe JS-implementaties zorgen vaker voor indexatiefouten dan teams verwachten. Googlebot rendert JavaScript, maar niet altijd op hetzelfde moment als een echte browser.
  • Infinite scroll zonder paginatie. Als nieuwe content alleen via scrollen laadbaar is en er geen crawlbare URL’s zijn, indexeert Google die content simpelweg niet. Wortel eruit, altijd.

Google Search Central benadrukt dat content die via complexe JavaScript-patronen vertraagd wordt, risico loopt op niet-indexatie. Native lazy loading is de aanbevolen standaard.

Welke technische methoden zijn er voor lazy loading?

Native loading=“lazy”

Het loading="lazy" attribuut is een HTML-feature die werkt in alle moderne browsers. Je voegt het toe aan een <img> of <iframe> tag en de browser regelt de rest. Geen JavaScript nodig, geen extra afhankelijkheden.

<img src="afbeelding.jpg" loading="lazy" width="800" height="600" alt="Beschrijving">

Native lazy loading via het loading=“lazy” attribuut werkt in de meeste moderne browsers en is in verreweg de meeste gevallen de beste eerste keuze. Simpel, veilig en door Googlebot goed te verwerken.

IntersectionObserver API

De IntersectionObserver API geeft je meer controle: je bepaalt zelf wanneer een element als “in beeld” geldt, met een drempelwaarde (threshold). Handig voor complexe layouts, animaties of situaties waarbij je wilt dat content al laadt voordat het volledig in beeld is.

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const img = entry.target;
      img.src = img.dataset.src;
      observer.unobserve(img);
    }
  });
}, { rootMargin: '200px' });

document.querySelectorAll('img[data-src]').forEach(img => observer.observe(img));

Het nadeel: dit is JavaScript. Als Googlebot de pagina rendert voordat dit script uitvoert, ziet de crawler lege afbeeldingen.

JavaScript-libraries

Libraries zoals lazysizes bieden extra functies: ondersteuning voor achtergrondafbeeldingen, responsive images en complexe scenario’s. Maar elke extra library is ook extra gewicht en een extra foutbron. Gebruik ze alleen als native loading en IntersectionObserver echt niet volstaan.

SSR versus CSR en crawlbaarheid

Bij server-side rendering (SSR) levert de server al volledig gerenderde HTML. Googlebot ziet de content direct, ook als lazy loading via JavaScript is geïmplementeerd. Bij client-side rendering (CSR) bouwt JavaScript de pagina op in de browser. Googlebot moet dan wachten op de render-queue, wat vertraging en indexatierisico’s oplevert.

Methode Implementatie-moeilijkheid SEO-risico Performance-winst
Native loading="lazy" Laag Laag Goed
IntersectionObserver Gemiddeld Gemiddeld Goed tot uitstekend
JS-library (lazysizes) Gemiddeld tot hoog Gemiddeld tot hoog Uitstekend
CSR zonder SSR-fallback Hoog Hoog Wisselend

Pro-tip: Kies native tenzij je een concrete reden hebt voor meer controle. “Misschien heb ik het later nodig” is geen reden.

Hoe implementeer je lazy loading SEO-vriendelijk?

Goede implementatie draait om drie dingen: de juiste afbeeldingen uitsluiten, dimensies opgeven en fallbacks regelen.

Checklist voor correcte implementatie

  1. Geen lazy loading op de LCP-afbeelding. Gebruik loading="eager" of laat het attribuut weg. Voeg een <link rel="preload"> toe in de <head>.
  2. Altijd width en height opgeven. Zonder afmetingen weet de browser niet hoeveel ruimte hij moet reserveren. Dat veroorzaakt layout shifts (CLS). Specificeer altijd afmetingen op je img-tags.
  3. Alt-tekst op elke afbeelding. Googlebot leest alt-teksten ook als de afbeelding nog niet geladen is.
  4. Gebruik srcset voor responsive images. Zo laadt de browser de juiste bestandsgrootte voor elk scherm.

Codevoorbeelden

Hero-afbeelding met preload:

<!-- In de <head> -->
<link rel="preload" as="image" href="hero.jpg">

<!-- In de <body> -->
<img src="hero.jpg" loading="eager" width="1200" height="600" alt="Hero beschrijving">

Overige afbeeldingen met lazy loading:

<img src="product.jpg" loading="lazy" width="400" height="300"
     srcset="product-400.jpg 400w, product-800.jpg 800w"
     sizes="(max-width: 600px) 400px, 800px"
     alt="Productnaam en beschrijving">

Noscript-fallback voor crawlers zonder JavaScript:

<noscript>
  <img src="product.jpg" width="400" height="300" alt="Productnaam en beschrijving">
</noscript>

Dos en don’ts

  • Nooit lazy loading op above-the-fold content.
  • Geen custom scroll-triggers die crawlers missen.
  • Derde-partij embeds (YouTube, Vimeo, Google Maps) altijd lazy-loaden, tenzij ze above the fold staan.
  • Achtergrondafbeeldingen in CSS vallen buiten het bereik van loading="lazy". Gebruik daarvoor IntersectionObserver of een library.

De on-page SEO factoren zoals alt-teksten en afbeeldingsdimensies werken direct samen met lazy loading voor betere vindbaarheid.

Wat moet je weten over lazy loading in WordPress?

WordPress heeft native loading="lazy" standaard actief sinds versie 5.5, maar thema’s en plugins kunnen dat gedrag overschrijven of dubbel uitvoeren. Dat is waar het misgaat.

Veelvoorkomende valkuilen in WordPress:

  • Dubbele lazy scripts. Een caching-plugin en een page builder voegen allebei hun eigen lazy loading toe. Resultaat: conflicten en onvoorspelbaar gedrag.
  • Achtergrondafbeeldingen niet gedekt. WordPress’ native implementatie dekt alleen <img>-tags. CSS-achtergronden in thema’s of Elementor-secties vallen erbuiten.
  • Page builders overschrijven native gedrag. Elementor en vergelijkbare builders laden afbeeldingen soms via eigen scripts, waardoor het native attribuut wordt genegeerd.
  • LCP-afbeelding toch lazy-geladen. Sommige thema’s voegen loading="lazy" toe aan alle afbeeldingen, inclusief de hero. Controleer dit altijd.

Praktische checklist voor WordPress:

  • Controleer in Chrome DevTools of je hero-afbeelding loading="eager" heeft of geen loading-attribuut.
  • Zoek in de paginabron naar dubbele lazy-loading scripts (bijv. zowel lazysizes als het native attribuut).
  • Gebruik de Lighthouse-audit om CLS-scores te controleren op ontbrekende afmetingen.
  • Bekijk in de thema-templates of the_post_thumbnail() een loading-attribuut meekrijgt.

Filter-snippet om LCP-afbeelding uit te sluiten in WordPress:

add_filter( 'wp_lazy_loading_enabled', function( $default, $tag_name, $context ) {
    if ( 'img' === $tag_name && 'the_post_thumbnail' === $context ) {
        return false;
    }
    return $default;
}, 10, 3 );

Pro-tip: Installeer niet zomaar een aparte lazy loading-plugin als WordPress dit al native doet. Controleer eerst wat er al actief is via de paginabron of een tool als Query Monitor.

Hoe test je of lazy loading correct werkt?

Stap-voor-stap testprotocol

  1. Lighthouse in Chrome DevTools. Open DevTools, ga naar het tabblad Lighthouse en draai een audit op mobiel. Kijk naar LCP, CLS en de diagnostiek “Defer offscreen images”. Als je hero-afbeelding in de diagnostiek staat, is er een probleem.
  2. Chrome DevTools > Rendering > Disable JavaScript. Schakel JavaScript uit en herlaad de pagina. Zie je nog steeds afbeeldingen? Dan werkt de noscript-fallback. Zie je lege vlakken? Dan mis je fallbacks voor crawlers.
  3. WebPageTest in filmstrip-modus. Gebruik WebPageTest met een echte verbinding (bijv. 4G mobiel) om te zien wanneer afbeeldingen precies laden. Audittools die JavaScript renderen zijn essentieel om te bevestigen dat lazy-loaded assets in de gerenderde DOM verschijnen.
  4. URL Inspection in Google Search Console. Voer de URL in en klik op “Testen van live URL”. Bekijk de gerenderde HTML. Staan je afbeeldingen erin? Dan ziet Googlebot ze. Ontbreken ze? Dan is er een indexatieprobleem.

Welke metrics zijn relevant?

  • LCP: moet onder de 2,5 seconden blijven. Als lazy loading je hero raakt, stijgt dit getal.
  • CLS: moet onder de 0,1 blijven. Ontbrekende afmetingen op lazy-loaded afbeeldingen zijn de meest voorkomende oorzaak van hoge CLS.
  • INP (Interaction to Next Paint): minder direct gerelateerd aan lazy loading, maar zware JS-implementaties kunnen dit beïnvloeden.

Google Search Console’s URL Inspection en Lighthouse geven verschillende signalen. Combineer lab-tests via Lighthouse met velddata uit Search Console om te prioriteren wat je aanpakt.

Pro-tip: Vergelijk de gerenderde HTML in URL Inspection met de broncode. Staan afbeeldingen in de bron maar niet in de gerenderde versie? Dan rendert Googlebot je lazy loading-script niet.

Veelgemaakte fouten en hoe je ze repareert

  • Hero-afbeelding is lazy-geladen. Oorzaak: thema of plugin voegt loading="lazy" toe aan alle afbeeldingen. Fix: voeg loading="eager" toe aan de hero en een <link rel="preload"> in de <head>. Bevestig via Lighthouse dat LCP daalt.

  • Afbeeldingen ontbreken in gerenderde HTML. Oorzaak: JavaScript-gebaseerde lazy loading voert niet uit tijdens Googlebot-rendering. Fix: voeg noscript-fallbacks toe of schakel over op native loading="lazy". Valideer via URL Inspection.

  • Hoge CLS door ontbrekende afmetingen. Oorzaak: geen width en height op img-tags. De browser weet niet hoeveel ruimte hij moet reserveren. Fix: voeg altijd afmetingen toe of gebruik een aspect-ratio placeholder in CSS.

  • Infinite scroll zonder crawlbare URL’s. Oorzaak: nieuwe content laadt via JavaScript zonder dat er aparte pagina-URL’s bestaan. Googlebot kan niet verder dan de eerste lading content. Fix: implementeer paginatie met crawlbare URL’s, of gebruik de History API om URL’s bij te werken bij het scrollen, conform de richtlijnen van Google Search Central.

  • Dubbele lazy loading in WordPress. Oorzaak: meerdere plugins of het thema voegen elk hun eigen implementatie toe. Fix: schakel de extra plugins uit, controleer via de paginabron of er nog maar één implementatie actief is.

Na elke fix: draai opnieuw een Lighthouse-audit en controleer URL Inspection om te bevestigen dat Googlebot de content ziet.

Ramon’s praktische auditchecklist: wat doe je eerst?

Prioriteit 1: 0–2 uur werk, directe winst

  1. Controleer of je hero/LCP-afbeelding loading="lazy" heeft. Zo ja, verwijder het attribuut of zet het op eager.
  2. Voeg <link rel="preload" as="image" href="hero.jpg"> toe in de <head>.
  3. Controleer alle img-tags op aanwezigheid van width, height en alt.
  4. Voeg loading="lazy" toe aan alle afbeeldingen die niet above the fold staan.
  5. Draai een Lighthouse-audit en noteer LCP en CLS.

Prioriteit 2: 2–8 uur werk, structurele verbetering

  1. Voeg noscript-fallbacks toe aan lazy-loaded afbeeldingen.
  2. Controleer achtergrondafbeeldingen in CSS en thema-templates.
  3. Draai WebPageTest op mobiel en analyseer de filmstrip.
  4. Corrigeer CLS-issues door ontbrekende afmetingen toe te voegen.
  5. Valideer via URL Inspection of Googlebot alle afbeeldingen ziet.

Prioriteit 3: 8+ uur, alleen bij complexe situaties

  1. Bouw IntersectionObserver-implementatie voor complexe layouts of animaties.
  2. Herbouw infinite scroll naar paginatie met crawlbare URL’s.
  3. Implementeer SSR-fallbacks voor CSR-zware frameworks.

Pro-tip: Heb je een kleine brochuresite met minder dan tien afbeeldingen en geen video’s? Sla lazy loading dan over. De winst is minimaal en de kans op fouten is groter dan de kans op verbetering. Investeer die tijd liever in TTFB of het verminderen van zware JavaScript.

De technische SEO best practices voor Core Web Vitals gaan verder dan lazy loading alleen. Lazy loading is één onderdeel van een groter geheel.

Belangrijkste inzichten

Lazy loading verbetert SEO alleen als je de hero-afbeelding uitsluit, afmetingen opgeeft en native implementatie kiest boven maatwerk-JavaScript.

Man bekijkt een SEO-checklist terwijl zijn laptop naast hem openstaat

Punt Details
Hero-afbeelding nooit lazy-loaden Gebruik loading="eager" of rel=preload voor je LCP-element, anders stijgt je LCP-score.
Altijd afmetingen opgeven Zonder width en height op img-tags ontstaan layout shifts die je CLS-score schaden.
Native boven JavaScript loading="lazy" in HTML is in de meeste gevallen voldoende en veiliger voor indexatie.
Test met URL Inspection Controleer via Google Search Console of Googlebot lazy-loaded afbeeldingen daadwerkelijk ziet na rendering.
Nebber voor technische audit Ramon Gulikers controleert je implementatie en geeft een concrete prioriteitenlijst voor directe verbetering.

Lazy loading is geen rankings-recept

Hier is de eerlijke boodschap: lazy loading lost geen SEO-problemen op als je fundering niet klopt. Als je TTFB boven de 600 ms zit, als je pagina 400 KB aan JavaScript laadt voordat er iets zichtbaar is, of als je server traag reageert, dan is lazy loading een pleister op een gebroken been.

De echte winst zit in de volgorde. Eerst: een snelle server, minimale render-blokkerende scripts en een schone HTML-structuur. Dan pas: lazy loading voor media die niet direct zichtbaar is. In die volgorde, niet andersom.

Lazy loading is ook geen garantie voor hogere rankings. Verbeterde Core Web Vitals zijn een afgeleide winst. De echte drijfveer is een betere gebruikerservaring, minder data-gebruik op mobiel en een lagere kans dat bezoekers afhaken voordat de pagina geladen is. Rankings volgen als gevolg, niet als oorzaak.

Voor kleine brochuresites zonder veel media is lazy loading simpelweg geen prioriteit. Zet die tijd in op iets wat meer oplevert: betere content, snellere hosting of het wegwerken van crawlfouten. De SEO-trends voor 2026 laten zien dat performance-optimalisatie breder gaat dan één techniek.

Nebber helpt je met een lazy loading-audit

Wil je weten of jouw implementatie correct is? Nebber voert een gerichte technische audit uit op je lazy loading-configuratie: hero-afbeelding, CLS-issues, indexatierisico’s en WordPress-conflicten. Je krijgt een concreet rapport met een prioriteitenlijst, zodat je weet wat je vandaag aanpakt en wat kan wachten.

Nebber

De audit duurt gemiddeld een halve werkdag en levert een checklist op die je direct aan je developer kunt doorgeven. Geen vage adviezen, maar concrete regels per pagina-type. Neem contact op via nebber.nl en vraag een technische SEO-audit aan.

Bronnen en tools om verder te lezen

  • Google Search Central: Fix lazy-loaded website content — de primaire bron voor hoe Googlebot omgaat met lazy loading en JavaScript-rendering. Gebruik dit als referentie bij indexatieproblemen.
  • web.dev: Browser-level image lazy-loading — gedetailleerde uitleg van het native loading="lazy" attribuut, browserondersteuning en wanneer je het gebruikt.
  • web.dev: Cumulative Layout Shift (CLS) — uitleg over hoe ontbrekende afmetingen op afbeeldingen CLS veroorzaken en hoe je dat voorkomt.
  • Lighthouse in Chrome DevTools — gebruik dit voor lab-tests van LCP, CLS en diagnostiek van uitgestelde afbeeldingen. Start hier bij elke audit.
  • WebPageTest — test op echte verbindingen en gebruik de filmstrip-weergave om te zien wanneer afbeeldingen precies laden. Onmisbaar voor mobiele performance-analyse.
  • Google Search Console URL Inspection — valideer of Googlebot lazy-loaded content ziet na rendering. Combineer met Lighthouse voor een volledig beeld.
  • MDN Web Docs: History API — relevant voor infinite scroll-implementaties waarbij je URL’s bijwerkt bij het scrollen zodat Googlebot pagina’s kan crawlen.

Aanbeveling