Afbeeldingen buiten beeld uitstellen op mobiel: gids voor native lazy loading

Afbeeldingen uitstellen op mobiel: de standaard

Mobiele pagina's vechten om een beperkt aantal verbindingen en een beperkte CPU. Elke afbeelding buiten beeld die je vooraf laadt, steelt bandbreedte van de afbeeldingen en scripts die er echt toe doen voor de initial paint.

Laatst gecontroleerd door Arjen Karel in maart 2026

1. Afbeeldingen buiten beeld uitstellen op mobiel: native lazy loading

Laadt een browser een pagina, dan opent hij een beperkt aantal parallelle verbindingen (afhankelijk van veel factoren, maar 6 per domein is een gangbaar gemiddelde). Worden die verbindingen gebruikt voor het downloaden van afbeeldingen buiten beeld (zoals een footer-logo of een carousel-slide), dan concurreert de download van kritieke resources (meestal de LCP-afbeelding, belangrijke scripts en fonts) om slots en bandbreedte. Dit is network contention en het verslechtert je Core Web Vitals direct.

Stel je afbeeldingen buiten beeld uit met het native loading-attribuut, dan geef je voorrang aan wat ertoe doet. De browser haalt alleen op wat direct zichtbaar is en houdt bandbreedte vrij voor de assets met impact op Largest Contentful Paint (LCP) en First Contentful Paint (FCP). Native lazy loading laat deze prioritering over aan het eigen mechanisme van de browser. Dat is sneller en maakt JavaScript lazy loading libraries overbodig.

Implementatie

Voeg voor alle afbeeldingen onder de initiële viewport ("the fold") het attribuut loading="lazy" toe.

<!-- Standard Deferred Image -->
<img src="product-detail.jpg"
     loading="lazy"
     alt="Side view of the chassis"
     width="800"
     height="600"
     decoding="async">

De attributen width en height zijn essentieel. Zonder deze attributen kan de browser geen ruimte reserveren voordat de afbeelding laadt. Dat veroorzaakt layout shift (CLS). 62% van de mobiele pagina's stelt nog altijd geen expliciete afmetingen in voor minstens één afbeelding.

Hoe lazy loading werkt op mobiel: de browserheuristiek

Native lazy loading is superieur aan JavaScript-oplossingen omdat de browser de laaddrempel (wanneer de download van een afbeelding start) aanpast op basis van het Effective Connection Type (ECT).

• Op 4G/WiFi: de Blink-engine (Chrome/Edge) gebruikt een voorzichtige drempel van ongeveer 1.250px. Hij gaat uit van lage latency en haalt de afbeelding pas op als de gebruiker relatief dichtbij scrolt.
• Op 3G/Slow-2G: de drempel rekt op naar ongeveer 2.500px. De browser start het request veel eerder om hoge round-trip times te compenseren. Zo staat de afbeelding klaar voordat de gebruiker hem in beeld scrolt.

Volgens de Web Almanac van 2025 laadt de mediane mobiele pagina 15 afbeeldingen met een totale omvang van 911 KB. Slechts zo'n 26% van die afbeeldingen gebruikt loading="lazy". De rest laadt eager en concurreert om dezelfde beperkte verbindingen. Op een typische mobiele 4G-verbinding staat de LCP-afbeelding daardoor te wachten achter een dozijn afbeeldingen die de bezoeker pas seconden later ziet.

Kritieke uitzondering: de LCP-kandidaat

Een veelvoorkomende performance-regressie: loading="lazy" toepassen op het Largest Contentful Paint-element (meestal de hero image). Dit vertraagt de fetch totdat de layout klaar is.

Onderzoek van Google toont aan dat lazy loading van de LCP-afbeelding 624ms toevoegt aan de mediane LCP. Dat is geen theoretisch risico. Volgens de Web Almanac van 2025 maakt 17% van de mobiele pagina's nog altijd deze fout. Geeft Lighthouse deze melding, bekijk dan hoe je de lazy-loaded LCP-waarschuwing fixt.

De LCP-afbeelding moet eager worden geladen en geprioriteerd:

<!-- Hero Image: Eager and Prioritized -->
<img src="hero.jpg"
     alt="Summer Collection"
     width="1200"
     height="800"
     loading="eager"
     fetchpriority="high">

Combineer loading="lazy" niet met fetchpriority="high". Ze spreken elkaar tegen: lazy zegt dat de browser moet wachten, high dat hij haast moet maken. Staat lazy ingesteld, dan negeert de browser de priority hint. Bekijk de gids voor resource-prioritering voor meer informatie over hoe browsers resources prioriteren.

2. Mobiele complexiteit: viewport en touch

Mobiele viewports zijn niet statisch. Het zichtbare gebied verandert als de gebruiker scrolt, het apparaat kantelt of de URL-balk laat inklappen. Juist hier heeft native lazy loading een echt voordeel ten opzichte van JavaScript-oplossingen.

De dynamische viewport

In mobiele browsers is de viewport-hoogte (vh) fluïde. Zodra de gebruiker een touch-scroll start, klappen de URL-balk en navigatieknoppen vaak in, waardoor het zichtbare gebied van formaat verandert.

JavaScript lazy loading libraries berekenen de viewport-hoogte (window.innerHeight) meestal maar één keer bij het laden van de pagina. Passen mobiele browsers het zichtbare gebied dynamisch aan door de URL-balk tijdens het scrollen te verbergen, dan blijven JavaScript-methoden de oude, kleinere hoogtewaarde gebruiken. Afbeeldingen blijven daardoor ongeladen, zelfs wanneer ze al binnen de grotere viewport vallen. Bezoekers zien dan lege placeholders.

De interne layout-engine van de browser volgt de visual viewport automatisch. Daardoor gaan de triggers van native lazy loading altijd af, ongeacht veranderingen in de viewport-afmetingen. Dit is een van de redenen om altijd te kiezen voor native lazy loading in plaats van een JavaScript-alternatief.

3. Afbeeldingen decoderen en CPU-throttling op mobiel

Mobiele apparaten hebben een beperkte CPU en het decoderen van afbeeldingen op mobiel is relatief traag en zwaar. Het omzetten van een JPEG naar een bitmap kost veel CPU-cycli. Op een mobiele processor kan het decoderen van een reeks grotere afbeeldingen de main thread per afbeelding 50ms tot 100ms blokkeren. Dat veroorzaakt input latency.

De fix: content-visibility

De CSS-property content-visibility: auto werkt als lazy rendering. Het vertelt de browser om de layout- en paint-fases voor elementen buiten beeld volledig over te slaan. Het element bestaat in de DOM, maar verschijnt pas in de Render Tree zodra het de viewport nadert.

Omdat deze optimalisatie de rendering van de subtree van een element overslaat, kun je dit niet rechtstreeks toepassen op een <img>-tag (die heeft geen subtree). Pas content-visibility toe op de product-container of image card waarin de afbeelding en bijbehorende content staan:

@media (max-width: 768px) {
    .image-card, .product-card {
        /* Skip rendering of the container and its children */
        content-visibility: auto;

        /* Essential: Prevents container from collapsing to 0px height */
        contain-intrinsic-size: auto 300px;
    }
}

Hierdoor betaalt de browser de layout- en paint-kosten pas zodra de gebruiker er echt naartoe scrolt, zelfs als de afbeelding al is gedownload.

content-visibility bereikte de Baseline-status in september 2024 toen Safari 18 ondersteuning toevoegde. Het werkt nu in 93% van de browsers wereldwijd. Benchmarks van Google laten een 7x betere rendering performance zien bij de initiële load voor pagina's met veel secties buiten beeld.

Wil je de rendering-verbetering verifiëren op echte apparaten, dan laat Real User Monitoring de echte INP- en LCP-impact zien op al je mobiele verkeer. Op sites die CoreDash monitort, laten pagina's met content-visibility: auto op product grids op mobiel een zo'n 15% betere INP zien dan pagina's zonder.

4. Verouderde methoden: waarom je ze moet vermijden

Voordat browsers loading="lazy" ondersteunden, was JavaScript de enige optie. Nu native lazy loading op 95% wereldwijde ondersteuning zit, zijn deze JavaScript-methoden puur technical debt. Verwijder ze.

Het scroll handler-tijdperk (2010 tot 2016)

Vroege implementaties koppelden event listeners aan het scroll-event.

// Obsolete: do not use
window.addEventListener('scroll', () => {
    images.forEach(img => {
        if (img.getBoundingClientRect().top < window.innerHeight) {
            img.src = img.dataset.src;
        }
    });
});

Main Thread Blocking: het scroll-event vuurt tientallen keren per seconde. Logica uitvoeren en de layout berekenen (getBoundingClientRect) tijdens actief scrollen veroorzaakt frame drops (jank).

Layout Thrashing: het opvragen van geometrische eigenschappen dwingt de browser om de layout synchroon opnieuw te berekenen. Dat is een zware operatie voor mobiele CPU's.

Het IntersectionObserver-tijdperk (2016 tot 2019)

De IntersectionObserver-API verbeterde de performance door veranderingen in de zichtbaarheid van elementen asynchroon te observeren.

// Legacy: prefer native loading="lazy" where possible
const observer = new IntersectionObserver((entries) => {
    entries.forEach(entry => {
        if (entry.isIntersecting) {
            const img = entry.target;
            img.src = img.dataset.src;
            observer.unobserve(img);
        }
    });
});

Script-afhankelijkheid: er moet JavaScript worden uitgevoerd. Is de main thread druk met het hydraten van een framework (React/Vue), dan blijven de afbeeldingen ongeladen, zelfs als ze al in de viewport staan.

Geen netwerkbewustzijn: in tegenstelling tot native lazy loading gebruikt IntersectionObserver vaste marges (zoals rootMargin: '200px'). De buffer rekt op trage netwerken niet automatisch op. Gebruikers op een slechte verbinding zien daardoor witte flitsen.

Bekijk de desbetreffende handleidingen voor een compleet overzicht van optimalisatietechnieken voor afbeeldingen naast lazy loading, of om te zien hoe je CSS-achtergrondafbeeldingen uitstelt (wat loading="lazy" niet dekt).