Kort antwoord: snelheid is geen technische metric maar een vermenigvuldiger voor de hele funnel. Ze werkt tegelijk op conversie, posities in zoekmachines en de prijs van een betaalde klik. Het is de enige verbetering die je niet "alleen voor één kanaal" kunt doen: ze werkt overal tegelijk.
Wat Google precies meet
Sinds 2020 zijn er drie metrics die Google verzamelt bij echte gebruikers van je site en niet in het laboratorium. Ze heten Core Web Vitals en de drempels zijn:
| Metric | Wat het in gewone taal betekent | Drempel "goed" |
|---|---|---|
| LCP | Wanneer het hoofdblok van de pagina verschijnt: productfoto, kop | tot 2,5 s |
| INP | Hoe snel de pagina op klikken reageert | tot 200 ms |
| CLS | Hoeveel de inhoud tijdens het laden verspringt | tot 0,1 |
Een detail dat regelmatig wordt gemist: het 75e percentiel telt. Het is niet genoeg dat "bij mij op de laptop hij snel opent": drie kwart van de echte bezoeken, inclusief oude Androids op mobiel internet, moet binnen de drempel vallen.
Bij webshops op WordPress faalt meestal INP: de pagina is snel getekend, maar reageert nog een seconde niet op klikken, omdat op de achtergrond scripts van plug-ins, chat, pixels en het winkelmandje nog werken. De gebruiker leest dat niet als "trage pagina" maar als "de pagina is kapot", en komt niet terug.
Wat het in geld kost
De eerlijkste openbare illustratie is de casestudy van Vodafone op web.dev: een A/B-test op twee visueel identieke versies van een pagina liet zien dat een verbetering van de LCP met 31% 8% meer verkoop opleverde. Zonder redesign, zonder nieuwe actie: alleen snelheid.
Reken het om naar je eigen cijfers, net als in het eerste onderwerp: als de shop 40 000 € per maand omzet, is 8% elke maand 3 200 €. Het werk aan snelheid is eenmalig.
Er is nog een tweede effect dat zelden wordt meegerekend: snelheid verandert de advertentiekosten. Een trage landingspagina verlaagt de kwaliteitsscore in advertentiesystemen en verhoogt de prijs van een klik. Je betaalt dubbel: er komen minder mensen aan, en elke aankomst kostte meer.
Waarom juist WooCommerce vertraagt
WooCommerce zelf is niet traag. Traag wordt het door de typische constructie eromheen. Uit mijn audits is de volgorde van de boosdoeners bijna altijd deze:
- Thema met een builder. Een multifunctioneel thema met een visuele builder sleept tientallen CSS- en JS-bestanden mee op elke pagina, ook de bestanden die alleen op de homepage nodig zijn. Dit is de meest voorkomende en meest onderschatte oorzaak.
- Plug-ins die overal laden. De plug-ins voor slider, formulier, reviews en berekening van levering registreren hun scripts in de hele shop en niet alleen waar ze worden gebruikt.
- Geen paginacache. Elke categoriepagina is een volledige PHP-cyclus plus databasequery's. Op shared hosting van 5 €/maand is dat 1,5–3 seconden tot de eerste byte.
- Winkelmandfragmenten. WooCommerce roept standaard op elke pagina
wc-ajax=get_refreshed_fragmentsaan om de teller van het winkelmandje te verversen. Op een verder gecachete pagina is dit het enige niet-cachebare verzoek, en het blokkeert de rest. - Foto's op originele grootte. De fotograaf leverde JPEG's van 4 000 px à 3 MB en ze zijn ongewijzigd geüpload. De browser downloadt 3 MB om een afbeelding van 600 px breed te tonen.
- Externe scripts. Chat, pixels, kaarten, reviewwidgets. Elk ziet er onschuldig uit, samen vreten ze de INP op.
Wat je repareert in volgorde van rendement
De volgorde is belangrijk: eerst het goedkoopste en meest effectieve:
- Foto's: converteren naar WebP/AVIF, de juiste grootte serveren, alles onder de eerste schermhoogte lazy-loaden, maar niet de hoofdfoto van het product (dat bederft de LCP)
- Paginacache + object cache: statische caching van categorieën en productpagina's, Redis of Memcached voor databasequery's
- Winkelmandfragmenten uitschakelen waar ze niet nodig zijn, of vervangen door een lichte verversing van de teller
- Plug-ins doorlichten: ongebruikte verwijderen, het laden van scripts beperken tot pagina's die ze echt nodig hebben
- Externe scripts uitstellen: chat en pixels laden na interactie en niet in
<head> - Fonts: eigen hosting,
font-display: swap, alleen de gebruikte varianten - Hosting: als de TTFB na dit alles nog steeds boven 600 ms ligt, zit het probleem in de hardware en niet in de code
De eerste drie punten geven meestal 70% van het effect en kosten een paar dagen. De technische details van elk ervan staan in de naastliggende gids: Core Web Vitals, afbeeldingen, fonts en scripts en caching.
Insert voor de developer
- Zet HPOS aan. High-Performance Order Storage verplaatst bestellingen van
wp_posts/wp_postmetanaar eigen tabellen. Bij een shop met tienduizenden bestellingen verandert dat zowel het dashboard als elke query naar bestellingen. - Meet veldgegevens, geen labgegevens. De labmodus van PageSpeed Insights is handig om te debuggen, maar de beoordeling komt uit de veldgegevens van CrUX. Het Core Web Vitals-rapport in Search Console vertelt de waarheid.
- Zoek naar lange taken, niet naar het "gewicht van de pagina". INP wordt gedood door concrete handlers: het hertekenen van het winkelmandje, het script van een slider, synchrone analyticscode. Profileer het tabblad Performance in plaats van kilobytes te tellen.
- Controleer de autoload-opties.
SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes': als dat megabytes zijn, sleept elk verzoek die ballast mee. Meestal zijn het resten van verwijderde plug-ins. - Verifieer op een mobiel profiel met netwerk- en CPU-throttling. Op je MacBook is het altijd snel.
Wanneer thema-optimalisatie niet meer helpt
Er is een grens waarachter niets meer te verbeteren valt: thema en plug-ins leggen een minimum aan werk op dat niet te verwijderen is zonder de shop kapot te maken. Symptomen dat je hem hebt bereikt:
- De mobiele LCP blijft hangen op 3–4 seconden, terwijl foto's en cache al gedaan zijn
- Elke nieuwe plug-in verslechtert de metrics merkbaar
- Je moet kiezen tussen "snel" en "heeft de benodigde functies"
Op dit punt blijven twee wegen over. De eerste is functionaliteit afslanken: de builder opgeven, templates herschrijven, een deel van de plug-ins verwijderen. De tweede is de site en de backend scheiden: WooCommerce laten voor producten, bestellingen en het dashboard, en de frontend apart op een snelle stack bouwen. Hoe dat werkt en wanneer het loont, beschrijft de pagina WooCommerce en headless, inclusief een eerlijke beschrijving van wanneer het niet loont. Een kant-en-klare oplossing van dit type is NextWoo, een Next.js-site op een bestaande WooCommerce.
Praktische test
- Ik heb het Core Web Vitals-rapport in Google Search Console geopend en de mobiele adressen bekeken
- Ik ken LCP, INP en CLS uit veldgegevens en niet alleen uit een labtest
- Ik heb het gewicht van de hoofdfoto van het product gecontroleerd: onder 150–200 KB
- Ik heb de TTFB op een categoriepagina gecontroleerd: onder 600 ms
- Ik heb de winkelmandfragmenten uitgeschakeld of beperkt
- Ik heb de lijst met plug-ins doorgenomen: elke plug-in is nodig of verwijderd
- Ik heb uitgerekend wat 8% meer verkoop in mijn geld waard is
Hoe nu verder
Een snelle shop is een voorwaarde en geen reden om te kopen. Daarna komt de bezoeker op de productpagina en beslist hij of hij je genoeg vertrouwt om zijn geld af te geven: een productpagina die verkoopt.
Wil je het aan iemand overdragen: website sneller maken, met een audit, een lijst met werk op prioriteit en een vaste prijs voor de uitvoering.