Lazy loading

Lazy loading betekent het uitstellen van niet-kritieke assets totdat ze de viewport naderen. Voor SEO is het voordeel eenvoudig: minder initiële requests, lichtere pagina’s en betere Core Web Vitals. Het nadeel is net zo simpel. Laad de verkeerde asset lazy, vooral de LCP-afbeelding, en je maakt de pagina trager, niet sneller.

Wat er echt toe doet voor SEO

Bij templates met veel afbeeldingen kan lazy loading het aantal initiële afbeeldingsrequests met 30-80% verlagen en het aantal overgedragen bytes met 500 KB tot enkele MB verminderen. Dat helpt meestal indirect bij LCP, INP en bij crawl-efficiëntie op grote sites. Gebruik Google Search Console voor trends in Core Web Vitals, Lighthouse of DebugBear voor tests in een labomgeving, en Screaming Frog in JavaScript-renderingmodus om te bevestigen dat uitgestelde assets nog steeds verschijnen in de gerenderde HTML.

Google ondersteunt native lazy loading al jaren, en Google’s John Mueller heeft herhaaldelijk gezegd dat Google lazy-loaded content kan verwerken wanneer het correct is geïmplementeerd. Die nuancering is belangrijk. Correct betekent dat de asset nog steeds laadt in de gerenderde DOM, zonder dat er rare interacties met de gebruiker nodig zijn, custom scroll-events of kapotte JS-afhankelijkheden.

Zo implementeer je het zonder je rankings te schaden

• Gebruik native loading="lazy" voor onder-de-vouw img- en iframe-elementen.
• Doe niet aan lazy loading voor de hero-afbeelding of een asset die waarschijnlijk de LCP is. Zet die op eager loading en overweeg fetchpriority="high".
• Reserveer afmetingen met width/height of CSS aspect-ratio om CLS te voorkomen.
• Houd de echte afbeeldings-URL in de markup. Vermijd setups waarbij de URL pas verschijnt na complexe JS-executie.
• Test het gerenderde resultaat in Screaming Frog en de URL-inspectie in GSC, niet alleen in je browser.

Ahrefs en Semrush vertellen je niet of lazy loading kapot is. Ze kunnen pas achteraf een daling in verkeer tonen. De diagnose gebeurt in renderingtools, browser waterfalled views en GSC’s inspectie op paginaniveau.

Waar teams dit verkeerd doen

De meest gemaakte fout is lazy loading behandelen als een algemene regel. Dat is het niet. Productgrid’s, artikelteksten, modules met gerelateerde content en ingesloten video’s zijn goede kandidaten. Afbeeldingen boven de vouw, CSS-achtergronden die als hero-visual worden gebruikt, en kritieke review-widgets zijn dat meestal niet.

Een ander probleem: background images. Native lazy loading doet niets voor CSS-achtergrondafbeeldingen, waardoor teams denken dat ze de pagina geoptimaliseerd hebben wanneer de zwaarste visual nog steeds het renderen blokkeert. Daar heb je een andere aanpak nodig, vaak templatewijzigingen of het vervangen van decoratieve backgrounds door echte afbeeldings-elementen.

De eerlijke kanttekening

Lazy loading is niet op zichzelf een rankingtactiek. Het is een bezorgingstactiek. Als je bottleneck een trage TTFB is, opgeblazen JavaScript of een CSS-bundel van 1,5 MB, dan redt lazy loading de pagina niet. Ook crawl-budgetwinst wordt vaak overdreven. Op de meeste sites met minder dan 100.000 URL’s is de grootste SEO-winst snelheid die je gebruiker ziet, niet efficiëntie van bots.

Gebruik het waar het echt requests bespaart. Sla het over waar het kritieke content vertraagt. Dat is het hele spel.