Lazy loading correct implementeren

Eén simpel HTML-attribuut kan je paginasnelheid drastisch verbeteren - of juist je Largest Contentful Paint verpesten. Lazy loading is een van de meest toegepaste performance-technieken voor WordPress, maar wordt verrassend vaak verkeerd geïmplementeerd. Het verschil tussen goed en fout zit in de details: welke afbeeldingen laad je uit, welke juist niet, en hoe ga je om met de LCP?

WordPress voegt sinds versie 5.5 automatisch loading="lazy" toe aan afbeeldingen. Dat klinkt als een opgelost probleem, maar in de praktijk levert die automatisering regelmatig performance-problemen op. In dit artikel leer je hoe lazy loading écht werkt, waar WordPress de mist in gaat en hoe je het zelf correct implementeert.

Wat lazy loading doet (en niet doet)

Lazy loading stelt het laden van resources uit totdat ze nodig zijn. Voor afbeeldingen betekent dit: pas downloaden wanneer ze de viewport van de bezoeker naderen. Een pagina met twintig afbeeldingen laadt daardoor aanvankelijk alleen de drie of vier die direct zichtbaar zijn.

De voordelen zijn concreet:

• Lagere initiële laadtijd - minder bytes bij het eerste verzoek
• Minder bandbreedte - bezoekers die niet scrollen laden geen onzichtbare afbeeldingen
• Betere Speed Index - de zichtbare content verschijnt sneller
• Lager dataverbruik - relevant voor mobiele bezoekers

Wat lazy loading niet doet: het versnelt niet het laden van de afbeeldingen zelf. De bestanden worden niet kleiner en niet sneller gedownload. Het verschuift alleen het moment waarop ze worden opgehaald. Voor daadwerkelijke bestandsverkleining heb je een image optimization pipeline nodig.

Native lazy loading vs. JavaScript-oplossingen

Er zijn twee fundamenteel verschillende aanpakken voor lazy loading: het native loading-attribuut en JavaScript-gebaseerde bibliotheken.

Het native loading-attribuut

Sinds 2019 ondersteunt Chrome het loading-attribuut, en inmiddels volgen alle moderne browsers. De implementatie is zo simpel als:

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

De browser bepaalt zelf wanneer de afbeelding geladen wordt, op basis van de afstand tot de viewport, de verbindingssnelheid en het apparaat. Dit gedrag is geoptimaliseerd door de browserfabrikanten en werkt zonder enige JavaScript.

JavaScript-bibliotheken

Voordat native lazy loading bestond, waren bibliotheken als Lozad.js, lazysizes en vanilla-lazyload de standaard. Ze werkten door het src-attribuut te vervangen door data-src en de echte bron pas in te laden via een Intersection Observer.

<!-- JavaScript lazy loading patroon -->
<img data-src="foto.jpg" class="lazyload" width="800" height="600" alt="Beschrijving">

Het probleem met deze aanpak in 2026: de src ontbreekt in de initiële HTML. Dat betekent dat zoekmachines die geen JavaScript renderen de afbeelding niet zien. Hoewel Googlebot JavaScript rendert, is het native attribuut veiliger en eenvoudiger.

De vuistregel: gebruik altijd native lazy loading. Grijp alleen naar JavaScript wanneer je geavanceerde controle nodig hebt, zoals custom thresholds of fade-in animaties.

Hoe WordPress lazy loading afhandelt

WordPress voegt sinds versie 5.5 automatisch loading="lazy" toe aan afbeeldingen in de content. Sinds versie 5.9 krijgt ook de eerste content-afbeelding loading="eager" om te voorkomen dat de LCP-afbeelding vertraagd wordt. In versie 6.3 is deze logica verder verbeterd met automatische fetchpriority="high" voor het waarschijnlijke LCP-element.

Wat er automatisch gebeurt

WordPress past lazy loading toe via de wp_img_tag_add_loading_optimization_attrs-functie. De logica werkt als volgt:

1. Alle <img>-tags in the_content krijgen loading="lazy"
2. De eerste afbeelding in de content wordt uitgezonderd en krijgt loading="eager"
3. Sinds WP 6.3 krijgt die eerste afbeelding ook fetchpriority="high"

Waar het misgaat

Het probleem is dat WordPress alleen kijkt naar afbeeldingen binnen the_content(). Je thema bevat waarschijnlijk afbeeldingen buiten de content-loop:

• Hero-afbeeldingen in de header
• Logo's en navigatie-elementen
• Featured images die via the_post_thumbnail() worden geladen
• Slider-afbeeldingen boven de vouw

Deze afbeeldingen vallen buiten de automatische logica van WordPress. Afhankelijk van je thema krijgen ze standaard loading="lazy" - terwijl ze boven de vouw staan en direct zichtbaar zijn. Het resultaat: de belangrijkste afbeelding op je pagina wordt als laatste geladen.

Dit is precies het type performance bottleneck dat moeilijk te spotten is zonder gerichte meting. Je site lijkt snel, maar Lighthouse geeft een slechte LCP-score.

De LCP-afbeelding correct behandelen

De Largest Contentful Paint is een van Google's Core Web Vitals en meet hoe snel het grootste zichtbare element op de pagina verschijnt. In de meeste gevallen is dat een afbeelding. Als die afbeelding lazy loading heeft, wacht de browser met laden totdat het te laat is.

Stap 1: Identificeer je LCP-element

Open je pagina in Chrome DevTools, ga naar het Performance-tabblad en maak een opname. Het LCP-element wordt gemarkeerd. Alternatieven:

• PageSpeed Insights - toont het LCP-element in de diagnostiek
• Lighthouse - geeft een waarschuwing als de LCP-afbeelding loading="lazy" heeft
• Web Vitals extensie - toont real-time LCP in de browser

Stap 2: Verwijder lazy loading van de LCP-afbeelding

Voor afbeeldingen die je via wp_get_attachment_image() laadt:

wp_get_attachment_image($image_id, 'hero-lg', false, [
    'loading'       => 'eager',
    'fetchpriority' => 'high',
    'decoding'      => 'async',
]);

De drie attributen werken samen:

• loading="eager" - laad direct, niet uitgesteld
• fetchpriority="high" - geef deze resource voorrang in de downloadwachtrij
• decoding="async" - decodeer de afbeelding op een achtergrondthread

Stap 3: Preload de LCP-afbeelding

Voor de snelste LCP voeg je een <link rel="preload"> toe in de <head>. Hiermee begint de browser de afbeelding te downloaden nog voordat de HTML-parser de <img>-tag tegenkomt:

add_action('wp_head', function () {
    if (is_front_page()) {
        echo '<link rel="preload" as="image" href="/images/hero.webp" fetchpriority="high">';
    }
}, 1);

Gebruik preload spaarzaam - alleen voor de LCP-afbeelding. Te veel preloads concurreren met elkaar en vertragen juist de rest van de pagina.

Lazy loading voor iframes en video's

Lazy loading is niet beperkt tot afbeeldingen. Iframes - denk aan YouTube-embeds, Google Maps en externe widgets - zijn vaak nog zwaarder dan afbeeldingen.

YouTube-embeds

Een enkele YouTube-embed laadt meer dan 500 KB aan scripts, stylesheets en afbeeldingen. Met native lazy loading op het iframe voorkom je die impact voor bezoekers die niet tot de video scrollen:

<iframe
  src="https://www.youtube.com/embed/VIDEO_ID"
  loading="lazy"
  width="560"
  height="315"
  title="Videotitel"
  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope"
  allowfullscreen
></iframe>

Een nog effectievere aanpak is de lite-youtube techniek: toon eerst alleen een thumbnail met een afspeelknop. Pas bij een klik laad je het daadwerkelijke iframe. Dit bespaart honderden kilobytes aan initieel paginagewicht.

Google Maps

Hetzelfde geldt voor Maps-embeds. Voeg loading="lazy" toe aan het iframe. Als de kaart onderaan de pagina staat, scheelt dit merkbaar in laadtijd.

Veelgemaakte fouten bij lazy loading

Na het debuggen van trage plugins en het analyseren van tientallen WordPress-sites, zijn dit de fouten die we het vaakst tegenkomen.

Fout 1: Lazy loading op de LCP-afbeelding

De meest schadelijke fout. Je hero-image of featured image staat boven de vouw maar heeft loading="lazy". De browser wacht met laden tot de afbeelding de viewport nadert, wat zinloos is omdat ze al in beeld is.

Oplossing: controleer in de HTML-bron of je boven-de-vouw-afbeeldingen loading="eager" en fetchpriority="high" hebben.

Fout 2: Ontbrekende width en height

Lazy loading zonder expliciete afmetingen veroorzaakt layout shifts. De browser reserveert geen ruimte voor de afbeelding, en zodra deze laadt springt de content omlaag. Dit schaadt je CLS-score.

<!-- Fout: geen afmetingen -->
<img src="foto.jpg" loading="lazy" alt="Beschrijving">

<!-- Correct: met afmetingen -->
<img src="foto.jpg" loading="lazy" width="800" height="600" alt="Beschrijving">

Een alternatief is de CSS aspect-ratio-property:

img {
    aspect-ratio: 4 / 3;
    width: 100%;
    height: auto;
}

Fout 3: Dubbele lazy loading

Sommige thema's of plugins voegen hun eigen lazy loading toe bovenop de native WordPress-implementatie. Je eindigt met zowel loading="lazy" als een JavaScript-bibliotheek die het src-attribuut manipuleert. Dit resulteert in onvoorspelbaar gedrag en soms in afbeeldingen die helemaal niet laden.

Controleer je HTML op dubbele patronen:

<!-- Dubbele implementatie - problematisch -->
<img data-src="foto.jpg" src="placeholder.gif" loading="lazy" class="lazyload">

Oplossing: kies één methode. In 2026 is native lazy loading bijna altijd de juiste keuze. Schakel JavaScript-lazy-loading uit in je thema of plugin-instellingen.

Fout 4: Lazy loading op CSS-achtergronden

Het loading-attribuut werkt alleen op <img>- en <iframe>-elementen. CSS background-image wordt niet beïnvloed. Als je grote achtergrondafbeeldingen hebt die buiten de viewport staan, heb je een andere aanpak nodig.

Gebruik de Intersection Observer API om een klasse toe te voegen wanneer het element in beeld komt:

const observer = new IntersectionObserver((entries) => {
    entries.forEach(entry => {
        if (entry.isIntersecting) {
            entry.target.classList.add('bg-loaded');
            observer.unobserve(entry.target);
        }
    });
});

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

.section-bg {
    background: #f0f0f0; /* placeholder kleur */
}
.section-bg.bg-loaded {
    background-image: url('/images/achtergrond.webp');
}

WordPress-filters voor fijnmazige controle

WordPress biedt filters waarmee je het lazy loading-gedrag per afbeelding kunt aanpassen. Dit is vooral nuttig in thema's die zonder plugins werken.

Lazy loading volledig uitschakelen voor specifieke afbeeldingen

add_filter('wp_img_tag_add_loading_attr', function ($value, $image, $context) {
    // Geen lazy loading voor afbeeldingen met 'hero' in de class
    if (strpos($image, 'hero-image') !== false) {
        return 'eager';
    }
    return $value;
}, 10, 3);

Het aantal eager-afbeeldingen aanpassen

WordPress markeert standaard de eerste content-afbeelding als eager. Met het filter wp_omit_loading_attr_threshold kun je dit aantal aanpassen:

add_filter('wp_omit_loading_attr_threshold', function () {
    return 3; // De eerste 3 afbeeldingen worden niet lazy geladen
});

Op pagina's met meerdere boven-de-vouw-afbeeldingen - zoals een portfolio of productoverzicht - kan het verhogen van deze threshold zinvol zijn.

Meten of je lazy loading werkt

Implementeren zonder meten is gokken. Na het instellen van lazy loading wil je twee dingen verifiëren: werkt het uitstellen correct, en is de LCP-afbeelding niet vertraagd?

Chrome DevTools

1. Open het Network-tabblad en filter op Img
2. Schakel Disable cache in
3. Laad de pagina en scroll langzaam
4. Afbeeldingen die pas verschijnen bij scrollen worden correct lazy geladen

Lighthouse en PageSpeed Insights

PageSpeed Insights controleert specifiek op:

• Defer offscreen images - zijn onzichtbare afbeeldingen uitgesteld?
• Largest Contentful Paint element - heeft de LCP-afbeelding geen lazy loading?
• Image elements do not have explicit width and height - zijn afmetingen meegegeven?

Combineer deze metingen met de uitgebreide performance-meetmethoden die we eerder bespraken. Een optimaal geconfigureerde lazy loading implementatie in combinatie met een goed ingestelde CDN levert het grootste verschil op voor je eindgebruikers.

Veelgestelde vragen

Wat is lazy loading en waarom is het belangrijk?

Lazy loading is een techniek waarbij afbeeldingen en andere zware resources pas worden geladen wanneer ze in beeld komen bij de bezoeker. Dit bespaart bandbreedte, verlaagt de initiële laadtijd en verbetert je Core Web Vitals - met name LCP en Speed Index.

Moet ik de hero-afbeelding ook lazy loaden?

Nee, juist niet. De hero-afbeelding is vaak het LCP-element en moet zo snel mogelijk laden. Gebruik loading="eager" en fetchpriority="high" voor boven-de-vouw-afbeeldingen. Lazy loading op de LCP-afbeelding vertraagt je Largest Contentful Paint merkbaar.

Werkt native lazy loading in alle browsers?

Ja, loading="lazy" wordt ondersteund door alle moderne browsers, inclusief Chrome, Firefox, Safari en Edge. De globale ondersteuning ligt boven de 95%. Een JavaScript-fallback is voor de meeste sites niet meer nodig.

Hoe test ik of lazy loading correct werkt?

Open de DevTools in je browser, ga naar het Network-tabblad en filter op afbeeldingen. Scroll langzaam door de pagina en controleer of afbeeldingen pas laden wanneer ze de viewport naderen. Lighthouse en PageSpeed Insights waarschuwen ook als de LCP-afbeelding onterecht lazy loading heeft.

Kan lazy loading mijn SEO schaden?

Mits correct geïmplementeerd niet. Googlebot ondersteunt native lazy loading en rendert JavaScript. Gebruik altijd het native loading-attribuut in plaats van pure JavaScript-oplossingen, en zorg dat de img-tag met src-attribuut altijd in de HTML staat - ook zonder JavaScript.