Offscreen afbeeldingen uitstellen op mobiel: Gids voor native lazy loading

Afbeeldingen op mobiel uitstellen: de standaard

Mobiele pagina's vechten om beperkte verbindingen en beperkte CPU. Elke offscreen afbeelding die je vooraf laadt, steelt bandbreedte van de afbeeldingen en scripts die er daadwerkelijk toe doen voor de initiële paint.

Laatst beoordeeld door Arjen Karel in maart 2026

1. Offscreen afbeeldingen uitstellen op mobiel: native lazy loading

Wanneer een browser een pagina laadt, opent deze een beperkt aantal parallelle verbindingen (afhankelijk van veel factoren, maar 6 per domein is een gangbaar gemiddelde). Als deze verbindingen worden gebruikt voor het downloaden van offscreen afbeeldingen (bijv. een footer logo of carrousel slide), zal de download van kritieke resources (meestal de LCP afbeelding, belangrijke scripts en lettertypen) concurreren om slots en bandbreedte. Dit is netwerkcontentie en het verslechtert direct je Core Web Vitals.

Door offscreen afbeeldingen uit te stellen met het native loading attribuut, geef je prioriteit aan wat belangrijk is. De browser haalt alleen op wat direct zichtbaar is en reserveert bandbreedte voor de assets die impact hebben op Largest Contentful Paint (LCP) en First Contentful Paint (FCP). Native lazy loading besteedt deze prioritering uit aan het eigen mechanisme van de browser, wat sneller is en de noodzaak voor JavaScript lazy loading bibliotheken wegneemt.

Implementatie

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

<!-- Standaard uitgestelde afbeelding -->
<img src="product-detail.jpg"
     loading="lazy"
     alt="Zijaanzicht van het chassis"
     width="800"
     height="600"
     decoding="async">

De width en height attributen zijn essentieel. Zonder deze attributen kan de browser geen ruimte reserveren voordat de afbeelding laadt, wat een layout shift (CLS) veroorzaakt. Op 62% van de mobiele pagina's ontbreken nog steeds expliciete afmetingen bij ten minste één afbeelding.

Hoe lazy loading werkt op mobiel: De browser heuristiek

Native lazy loading is superieur aan JavaScript oplossingen omdat de browser de laaddrempel (wanneer een afbeelding wordt getriggerd om te downloaden) aanpast op basis van het Effective Connection Type (ECT).

• Op 4G/WiFi: De Blink engine (Chrome/Edge) gebruikt een conservatieve drempel van ongeveer 1.250px. Het gaat uit van een lage latentie en haalt de afbeelding pas op wanneer de gebruiker er relatief dichtbij scrolt.
• Op 3G/Slow-2G: De drempel wordt verruimd naar ongeveer 2.500px. De browser start het verzoek veel eerder om te compenseren voor hoge round-trip tijden, zodat de afbeelding klaar is voordat de gebruiker deze in beeld scrolt.

Volgens de 2025 Web Almanac laadt de mediane mobiele pagina 15 afbeeldingen met een totaal van 911 KB. Slechts ongeveer 26% van die afbeeldingen gebruikt loading="lazy". De rest laadt eager en concurreert om dezelfde beperkte verbindingen. Op een typische 4G mobiele verbinding betekent dit dat de LCP afbeelding vastzit en moet wachten achter een dozijn afbeeldingen die de gebruiker de eerste seconden toch niet zal zien.

Kritieke uitzondering: De LCP kandidaat

Een veelvoorkomende performance regressie: het toepassen van loading="lazy" op het Largest Contentful Paint element (meestal de hero afbeelding). Dit vertraagt de fetch totdat de lay-out compleet is.

Onderzoek van Google toont aan dat het lazy-loaden van de LCP afbeelding 624ms toevoegt aan de mediane LCP. Dat is geen theoretisch risico. 17% van de mobiele pagina's maakt nog steeds deze fout volgens de 2025 Web Almanac. Als Lighthouse dit markeert, bekijk dan hoe je de lazy-loaded LCP waarschuwing oplost.

De LCP afbeelding moet eager-loaded en geprioriteerd worden:

<!-- Hero afbeelding: Eager en geprioriteerd -->
<img src="hero.jpg"
     alt="Zomercollectie"
     width="1200"
     height="800"
     loading="eager"
     fetchpriority="high">

Combineer loading="lazy" niet met fetchpriority="high". Ze spreken elkaar tegen: lazy vertelt de browser om te wachten, high vertelt hem om te haasten. De browser negeert de priority hint wanneer lazy is ingesteld. Voor meer informatie over hoe browsers resources prioriteren, zie de gids voor resource prioritization.

2. Mobiele complexiteiten: Viewport en Touch

Mobiele viewports zijn niet statisch. Het zichtbare gebied verandert naarmate de gebruiker scrolt, het apparaat roteert of ervoor zorgt dat de URL-balk zich terugtrekt. Dit is waar native lazy loading een echt voordeel heeft ten opzichte van JavaScript oplossingen.

De dynamische viewport

In mobiele browsers is de viewport hoogte (vh) fluïde. Zodra de gebruiker een touch scroll initieert, trekken de URL-balk en navigatieknoppen zich vaak terug, waardoor de grootte van het zichtbare gebied verandert.

JavaScript lazy loading bibliotheken berekenen doorgaans de viewport hoogte (window.innerHeight) eenmalig tijdens het laden van de pagina. Wanneer mobiele browsers het zichtbare gebied dynamisch vergroten door de URL-balk te verbergen tijdens een scroll, blijven JavaScript methoden de oude, kleinere hoogtewaarde gebruiken. Afbeeldingen blijven ongeladen, zelfs wanneer ze de vergrote viewport binnenkomen, wat resulteert in lege tijdelijke aanduidingen voor bezoekers.

De interne lay-out engine van de browser volgt de visuele viewport automatisch, waardoor de triggers van native lazy loading afgaan ongeacht wijzigingen in de viewport grootte. Dit is één van de redenen om de voorkeur te geven aan native lazy loading boven elk JavaScript alternatief.

3. Mobiele image decoding en CPU throttling

Mobiele apparaten hebben een beperkte CPU en het decoderen van afbeeldingen kan op mobiel relatief traag en duur zijn. Het converteren van een JPEG naar een bitmap vereist veel CPU-cycli. Op een mobiele processor kan het decoderen van een reeks grotere afbeeldingen de main thread elk voor 50ms tot 100ms blokkeren, wat input latency veroorzaakt.

De oplossing: content-visibility

De CSS eigenschap content-visibility: auto fungeert als lazy rendering. Het instrueert de browser om de lay-out en painting fases voor off-screen elementen volledig over te slaan. Het element bestaat in de DOM, maar bestaat niet in de Render Tree totdat het de viewport nadert.

Omdat deze optimalisatie werkt door het renderen van de subtree van een element over te slaan, kun je het niet direct toepassen op een <img> tag (die geen subtree heeft). Pas content-visibility toe op de productcontainer of image card die de afbeeldingen en de bijbehorende content host:

@media (max-width: 768px) {
    .image-card, .product-card {
        /* Sla het renderen van de container en zijn child-elementen over */
        content-visibility: auto;

        /* Essentieel: Voorkomt dat de container inklapt tot 0px hoogte */
        contain-intrinsic-size: auto 300px;
    }
}

Dit zorgt ervoor dat zelfs als een afbeelding is gedownload, de browser de lay-out/paint kosten niet betaalt totdat de gebruiker er daadwerkelijk naartoe scrolt.

content-visibility bereikte de Baseline status in september 2024 toen Safari 18 ondersteuning uitbracht. Het werkt nu in 93% van de browsers wereldwijd. Benchmarks van Google tonen een 7x rendering performance boost bij de initiële laadtijd voor pagina's met veel off-screen secties.

Als je de verbetering in rendering wilt verifiëren op echte apparaten, zal Real User Monitoring de daadwerkelijke INP en LCP impact in je mobiele verkeer laten zien. Op sites gemonitord door CoreDash, tonen pagina's die content-visibility: auto gebruiken op productgrids ongeveer 15% betere INP op mobiel vergeleken met pagina's zonder.

4. Legacy methodieken: Waarom je ze moet vermijden

Voordat loading="lazy" browserondersteuning had, was JavaScript de enige optie. Met native lazy loading op 95% wereldwijde ondersteuning, zijn deze JavaScript methoden technical debt geworden. Verwijder ze.

Het Scroll Handler tijdperk (2010 tot 2016)

Vroege implementaties koppelden event listeners aan het scroll event.

// Verouderd: niet gebruiken
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 af. Het uitvoeren van logica en het berekenen van de lay-out (getBoundingClientRect) tijdens actief scrollen veroorzaakt frame drops (jank).

Layout Thrashing: Het opvragen van geometrische eigenschappen dwingt de browser om de lay-out synchroon opnieuw te bereken, een rekenintensieve operatie op 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: geef de voorkeur aan native loading="lazy" waar mogelijk
const observer = new IntersectionObserver((entries) => {
    entries.forEach(entry => {
        if (entry.isIntersecting) {
            const img = entry.target;
            img.src = img.dataset.src;
            observer.unobserve(img);
        }
    });
});

Script Dependency: Het vereist JavaScript uitvoering. Als de main thread bezig is met het hydrateren van een framework (React/Vue), blijven de afbeeldingen ongeladen, zelfs als ze in de viewport staan.

Gebrek aan netwerkbewustzijn: In tegenstelling tot native loading gebruikt IntersectionObserver vaste marges (bijv. rootMargin: '200px'). Het breidt zijn buffer niet automatisch uit op trage netwerken, wat leidt tot lege flitsen voor gebruikers met slechte verbindingen.

Voor een compleet overzicht van beeldoptimalisatietechnieken naast lazy loading, of om meer te leren over het uitstellen van CSS achtergrondafbeeldingen (wat loading="lazy" niet dekt), zie die specifieke gidsen.