3.7 Snelheid, mobiel & Core Web Vitals

Snelheid is geen technisch detail maar een verkoophefboom. Elke seconde extra laadtijd kost conversie, en Google gebruikt snelheid als rankingfactor. Op mobiel — waar de meeste van je bezoekers zitten — telt het dubbel. Dit hoofdstuk maakt snelheid meetbaar en geeft je de concrete ingrepen die het meeste opleveren.

🎯 Na dit hoofdstuk kun je:

• Je weet wat LCP, INP en CLS meten en kent hun streefwaarden.
• Je kunt je belangrijkste pagina’s meten met PageSpeed Insights en de mobiele scores interpreteren.
• Je kent de ingrepen met de meeste winst: afbeeldingen comprimeren naar WebP/AVIF, lazy loading (behalve op het LCP-element), apps opschonen en vaste afmetingen tegen CLS.
• Je begrijpt waarom je lazy loading juist níet op je hoofdfoto (LCP-element) zet.
• Je kunt mobiel-first meten en een prioriteitenplan op impact opstellen.

Kernconcepten

Core Web Vitals (CWV) — drie meetbare snelheids- en stabiliteitssignalen die Google gebruikt om de gebruikerservaring te beoordelen. Ze zitten in je ranking en zijn meetbaar in echte gebruikersdata.

LCP (Largest Contentful Paint) — hoe snel het grootste element (vaak je hero-beeld of producthoofdfoto) zichtbaar is. Meet gevoelde laadsnelheid.

INP (Interaction to Next Paint) — hoe snel de pagina reageert op een klik of tik. Vervangt sinds 2024 de oude FID-metric. Meet responsiviteit.

CLS (Cumulative Layout Shift) — hoeveel de pagina “verspringt” tijdens het laden. Een knop die wegspringt terwijl je erop tikt is slechte CLS.

Lazy loading — afbeeldingen pas laden wanneer ze bijna in beeld komen, in plaats van alles tegelijk. Versnelt de eerste indruk.

WebP / AVIF — moderne beeldformaten die fors kleiner zijn dan JPEG/PNG bij gelijke kwaliteit.

CDN (Content Delivery Network) — een netwerk van servers wereldwijd dat je bestanden dicht bij de bezoeker serveert. Shopify heeft dit ingebouwd; bij WooCommerce voeg je het toe.

Themabloat — overbodige code en functies in je thema die de pagina onnodig verzwaren.

Waarom snelheid omzet en SEO raakt

Onderzoek van onder meer Google en grote retailers toont consistent: hoe trager de pagina, hoe lager de conversie. Indicatief:

• Een laadtijd van 1 naar 3 seconden verhoogt de kans op een bounce aanzienlijk; van 1 naar 5 seconden meer dan verdrievoudigt die kans.
• Pagina’s die de Core Web Vitals halen, presteren in zowel gebruikerstevredenheid als zoekresultaten beter dan pagina’s die ze niet halen.
• Op mobiel, met tragere verbindingen en zwakkere processors, is het effect groter dan op desktop.

De vuistregel: elke seconde die je wint above the fold, win je een stukje conversie terug. En omdat CWV een rankingfactor is, win je tegelijk SEO (zie 6.3 Technische SEO).

Stap-voor-stap workflow

1. Meet eerst, gok niet. Draai je belangrijkste pagina’s (homepage, een categorie, je bestseller-productpagina) door PageSpeed Insights. Noteer de mobiele scores en de drie CWV-waarden.

2. Pak je afbeeldingen aan. Dit is bijna altijd de grootste winst. Comprimeer alles, zet om naar WebP/AVIF, en upload op de juiste afmeting (geen 4000 pixels brede foto die op 800 pixels getoond wordt).

3. Zet lazy loading aan voor alles onder de vouw, maar níet voor je LCP-element (de hero-/hoofdfoto) — die wil je juist zo snel mogelijk.

4. Ruim apps en scripts op. Elke app laadt code. Verwijder wat je niet gebruikt (zie 3.8 Apps & plugins).

5. Beperk en optimaliseer fonts. Gebruik maximaal twee lettertypen, laad alleen de gewichten die je echt gebruikt, en stel font-display zo in dat tekst direct zichtbaar is.

6. Voorkom layout shift (CLS). Geef afbeeldingen en advertentie-/embed-blokken vaste afmetingen mee zodat er niets verspringt tijdens het laden.

7. Zorg voor een CDN en caching. Bij Shopify automatisch; bij WooCommerce via je host of Cloudflare plus een caching-plugin.

8. Test mobiel-first. Bekijk en meet alles op een telefoon, niet alleen op je brede desktopscherm.

9. Meet opnieuw en vergelijk met je nulmeting. Herhaal tot je in het groen zit.

Voorbeeld: een trage productpagina versnellen

Een NL-shop meet zijn bestseller-productpagina op mobiel: LCP 4,8 seconden, INP 320 ms, CLS 0,28. Alles in het rood. De ingrepen:

1. Hoofdfoto: een JPEG van 3,2 MB op 3000 pixels breed werd een WebP van 180 KB op 1200 pixels. LCP zakt naar 2,6 seconden.
2. Lazy loading aangezet voor de galerij en reviews onder de vouw. Minder bytes bij eerste load.
3. Drie ongebruikte apps verwijderd (een oude pop-up, een ongebruikte wishlist, een dubbele trackingsnippet). INP zakt naar 180 ms.
4. Vaste afmetingen op alle afbeeldingen en het reviewblok ingesteld. CLS zakt naar 0,05.
5. Eén overbodig lettergewicht geschrapt. Marginale, maar gratis winst.

Eindmeting: LCP 2,1 seconden (goed), INP 150 ms (goed), CLS 0,05 (goed). Alle drie in het groen, zonder dat er iets aan het design veranderde. De add-to-cart-rate steeg meetbaar mee.

💡 Waarom mag je lazy loading juist niet op je hoofdfoto zetten, terwijl het overal anders winst oplevert?

Lazy loading werkt door de browser te vertellen: laad dit beeld pas wanneer het bijna in beeld scrollt. Voor foto’s onder de vouw is dat puur winst — je bespaart bytes bij de eerste load. Maar je LCP-element, vaak de hoofdfoto bovenaan, is per definitie meteen zichtbaar. Zet je daar lazy loading op, dan stelt de browser het laden eerst uit, ontdekt daarna pas dat het beeld toch nodig is, en begint dán pas met downloaden. Dat kost een extra ronde en kan je LCP een halve seconde of meer vertragen.

In het voorbeeld hierboven zakte LCP van 4,8 naar 2,6 seconden puur door het comprimeren van die hoofdfoto. Had de shop er ook lazy loading op gezet, dan was die winst deels weer verdampt — je optimaliseert het beeld en saboteert tegelijk het laadmoment. De regel is dus geen tegenspraak: lazy loading versnelt de gevoelde laadtijd door onbelangrijke bytes uit te stellen, maar je LCP-beeld is juist het belangrijkste byte op de pagina. Dat wil je niet uitstellen, dat wil je vooraan in de wachtrij.

Formules & benchmarks

Core Web Vitals hebben officiële streefwaarden (op het 75e percentiel van echte bezoekers):

Metric	Goed	Verbetering nodig	Slecht
LCP	Minder dan 2,5 s	2,5 tot 4,0 s	Meer dan 4,0 s
INP	Minder dan 200 ms	200 tot 500 ms	Meer dan 500 ms
CLS	Minder dan 0,1	0,1 tot 0,25	Meer dan 0,25

Aanvullende streefwaarden voor een gezonde shop:

Aspect	Goede richtwaarde
Mobiele PageSpeed-score	Meer dan 70 (boven 90 is uitstekend)
Totale paginagrootte (eerste load)	Minder dan 2 MB, liefst onder 1 MB
Time to First Byte (TTFB)	Minder dan 200 ms
Aantal hoofdfoto-bytes (LCP-beeld)	Minder dan 200 KB
Aantal geïnstalleerde apps met frontend-code	Zo laag mogelijk; elke app weegt

Indicatieve conversie-impact:

Geschatte conversiewinst ≈ verbetering in laadseconden × gevoeligheid van je publiek

Reken niet op een exacte formule, maar weet: van 5 naar 2,5 seconden LCP is doorgaans een merkbare conversiestijging waard, vaak meer dan welke design-tweak ook.

Tools

Tool	Functie	Wanneer kiezen
PageSpeed Insights	CWV en aanbevelingen, lab + veld	Standaard startpunt; meet altijd hier
Lighthouse (in Chrome DevTools)	Diepe technische audit per pagina	Je wilt detail over welk element traag is
Google Search Console (CWV-rapport)	CWV over je hele site, echte gebruikers	Overzicht welke paginatypen falen
TinyIMG / Crush.pics / ShortPixel	Afbeeldingen comprimeren en WebP/AVIF	Bulk beeldoptimalisatie zonder handwerk
Cloudflare	CDN en caching (vooral WooCommerce)	WooCommerce zonder ingebouwd CDN
WP Rocket (WooCommerce)	Caching, lazy load, code minify	WooCommerce-shop die snelheid serieus neemt

Veelgemaakte fouten

• Ongecomprimeerde, te grote afbeeldingen. Veruit de grootste oorzaak van trage shops. Pak dit eerst.
• Lazy loading op het LCP-element. Je hero-/hoofdfoto wil je juist meteen laden, niet uitstellen.
• Te veel apps. Elke app injecteert code die op elke pagina meelaadt, ook als je hem nauwelijks gebruikt.
• Zware sliders en achtergrondvideo’s in de hero die de eerste indruk vertragen.
• Geen vaste afmetingen op afbeeldingen, waardoor de pagina verspringt (slechte CLS) en mensen mis-tikken.
• Te veel lettertypen en gewichten. Elk extra font is een extra download.
• Alleen op desktop testen. Je publiek zit op mobiel; meet daar.
• Eénmalig optimaliseren en vergeten. Na elke nieuwe app of bannercampagne kan je snelheid weer wegzakken. Meet periodiek.

Checklist

✅Voordat je verder gaat

• Ik heb een nulmeting (mobiel) van homepage, categorie en bestseller-productpagina
• Alle afbeeldingen zijn gecomprimeerd, in WebP/AVIF en op de juiste afmeting
• Lazy loading staat aan onder de vouw, maar níet op het LCP-element
• Ongebruikte apps en scripts zijn verwijderd
• Maximaal twee lettertypen, alleen de gebruikte gewichten geladen
• Afbeeldingen en embeds hebben vaste afmetingen (CLS onder 0,1)
• Een CDN en caching zijn actief (automatisch bij Shopify)
• LCP onder 2,5 s, INP onder 200 ms, CLS onder 0,1 op mobiel
• Ik heb na de ingrepen opnieuw gemeten en met de nulmeting vergeleken

Sjablonen

📋Snelheids-audit per pagina Kopieer

Pagina: [URL]
Gemeten op: mobiel, [datum]

NULMETING:
- LCP: [waarde] s  (doel: minder dan 2,5)
- INP: [waarde] ms (doel: minder dan 200)
- CLS: [waarde]    (doel: minder dan 0,1)
- Mobiele score: [getal]
- Paginagrootte: [MB]

GROOTSTE BOOSDOENERS (uit PageSpeed):
1. [bijv. te grote hero-foto]
2. [bijv. ongebruikte app-scripts]
3. [bijv. layout shift door reviewblok]

INGREPEN:
- [actie] → verwacht effect [metric]
- [actie] → verwacht effect [metric]

HERMETING:
- LCP: [waarde] | INP: [waarde] | CLS: [waarde]
- Score: [getal] (was [getal])

⚡Doe dit nu

1. Draai je bestseller-productpagina door PageSpeed Insights op mobiel en noteer LCP, INP en CLS.
2. Identificeer je grootste afbeelding en comprimeer hem naar WebP onder 200 KB.
3. Open je app-lijst en verwijder alles wat je niet meer gebruikt.
4. Meet opnieuw en noteer het verschil in het audit-sjabloon.

Oefen het zelf

✏️Case: diagnose en herstel van een trage categoriepagina

Een NL-shop meet zijn drukste categoriepagina op mobiel: LCP 4,2 seconden, INP 240 ms, CLS 0,18, mobiele score 58, paginagrootte 3,1 MB. De eigenaar wil weten welke metric in welke categorie valt (goed, verbetering nodig, slecht), welke ingreep hij als eerste aanpakt, en wat een realistische verwachting is na optimalisatie. Op de pagina staan twaalf productfoto’s zonder vaste afmetingen, een grote bannerafbeelding bovenaan van 1,8 MB, en vier geïnstalleerde apps waarvan een filter-app en een pop-up. Stel een prioriteitenplan op en onderbouw je volgorde.

Toon uitwerking

Eerst de metrics tegen de benchmarktabel leggen:

• LCP 4,2 s: meer dan 4,0 s, dus slecht.
• INP 240 ms: tussen 200 en 500 ms, dus verbetering nodig.
• CLS 0,18: tussen 0,1 en 0,25, dus verbetering nodig.
• Score 58 en 3,1 MB: beide onder de richtwaarde (boven 70 en onder 2 MB).

Volgorde van ingrepen, grootste winst eerst:

1. Bannerafbeelding aanpakken. 1,8 MB is bijna alle ruimte boven de richtwaarde van onder 200 KB voor het LCP-beeld. Comprimeren naar WebP onder 200 KB en op de juiste afmeting uploaden haalt de slechtste metric, LCP, het hardst omlaag. Verwacht: LCP richting 2,5 seconden, paginagrootte ruim onder 2 MB.
2. Vaste afmetingen op de twaalf productfoto’s. Dit is de directe oorzaak van CLS 0,18; met vaste afmetingen zakt CLS naar onder 0,1 (goed).
3. Apps opschonen. De pop-up is vaak schrapbaar; minder frontend-scripts verlaagt INP richting onder 200 ms. De filter-app houd je als hij functioneel nodig is.

Oordeel: door eerst het zwaarste beeld te comprimeren en daarna layout shift en apps aan te pakken, kun je alle drie de metrics realistisch in het groen krijgen, met de banner als grootste hefboom. De les: meet, rangschik op impact, en begin altijd bij het grootste beeld.

Test jezelf

🧠Snelle kennischeck — snelheid, mobiel en Core Web Vitals

1. Waarom zet je geen lazy loading op je hoofdfoto bovenaan de pagina?

   A Omdat lazy loading de beeldkwaliteit verlaagt B Omdat dat juist het LCP-element is dat je zo snel mogelijk wilt tonen C Omdat lazy loading niet werkt op mobiel

2. Een productpagina meet CLS 0,18 op mobiel. In welke categorie valt dat en wat is meestal de oorzaak?

   A Verbetering nodig, vaak door afbeeldingen zonder vaste afmetingen B Goed, geen actie nodig C Slecht, vrijwel altijd door een trage server

3. Wat pak je doorgaans eerst aan als je een trage shop sneller wilt maken?

   A Het lettertype vervangen door een systeemfont B Een duurder hostingpakket nemen C De afbeeldingen comprimeren en verkleinen

4. Waarom moet je snelheid mobiel-first meten in plaats van alleen op desktop?

   A Omdat Google alleen mobiele paginas indexeert sinds dit jaar B Omdat het merendeel van je bezoekers op mobiel zit, met tragere verbindingen en zwakkere processors C Omdat CWV-metrics alleen op telefoons bestaan

📌 Samenvatting

• Meet eerst, gok niet: draai homepage, een categorie en je bestseller-productpagina door PageSpeed Insights en noteer LCP, INP en CLS op mobiel.
• Streefwaarden: LCP onder 2,5 s, INP onder 200 ms, CLS onder 0,1; het LCP-beeld onder 200 KB en de eerste load onder 2 MB.
• Te grote, ongecomprimeerde afbeeldingen zijn veruit de grootste oorzaak van trage shops; comprimeren naar WebP/AVIF op de juiste afmeting levert de meeste winst.
• Zet lazy loading aan onder de vouw maar níet op het LCP-element, anders vertraag je juist je belangrijkste beeld.
• Schoon ongebruikte apps op (elke app weegt), geef beelden vaste afmetingen tegen CLS, meet mobiel-first en hermeet na elke ingreep.

Lees verder

• 3.8 Apps & plugins — apps opschonen voor snelheid
• 6.3 Technische SEO — CWV als rankingfactor
• 3.2 Domein, hosting, SSL & e-mail — hosting en TTFB
• 3.4 High-converting productpaginas — beeld optimaliseren zonder conversie te verliezen
• 5.1 Funnel-lekken — snelheid als oorzaak van lekken