kort antwoord
Een trage WooCommerce-webshop komt meestal door zwakke hosting, zware afbeeldingen, te veel plug-ins of verkeerde caching. Meet eerst met PageSpeed Insights, pak dan de grootste oorzaak aan en test opnieuw.
Een trage webshop heeft zelden één oorzaak. Meestal is het een mix van te zwakke hosting, zware afbeeldingen, plug-ins die overal scripts laden en caching die niet goed is ingesteld. Het goede nieuws: met een paar metingen zie je snel waar de winst zit.
Hoe snel moet een webshop zijn?
Google gebruikt drie metingen, de Core Web Vitals. Dit zijn de grenzen voor “goed”, volgens de documentatie van Google op web.dev:
- Largest Contentful Paint (LCP): het grootste element (vaak een productfoto) staat er binnen 2,5 seconden of sneller.
- Interaction to Next Paint (INP): de pagina reageert op een klik of tik binnen 200 milliseconden of sneller.
- Cumulative Layout Shift (CLS): de pagina verspringt niet tijdens het laden, score 0,1 of lager.
Google beoordeelt dit op het 75e percentiel van paginaweergaven, apart voor mobiel en desktop. Dat betekent: 3 van de 4 bezoekers moeten de goede ervaring krijgen. Test dus altijd ook op mobiel.
Hoe meet je wat er traag is?
Gokken helpt niet. Begin met meten:
- Draai Google PageSpeed Insights op je homepage, een categoriepagina en een productpagina. Die verschillen vaak sterk.
- Kijk bij de resultaten naar het deel met echte bezoekersdata, niet alleen naar de labtest.
- Test de winkelwagen en de afrekenpagina apart. Die zijn per bezoeker uniek en komen niet uit de cache, dus daar zit vaak het echte probleem.
- Schrijf de scores op voordat je iets verandert. Anders weet je straks niet of het hielp.
Welke oorzaken komen het vaakst voor?
Kinsta beschrijft in zijn gids over het versnellen van WooCommerce een reeks bekende oorzaken. Dit zijn de belangrijkste, vertaald naar gewone taal.
Hosting die te krap zit
Op gedeelde hosting concurreert je shop met andere sites om dezelfde rekenkracht. Kinsta noemt als richtlijn minimaal 4 PHP-workers (de processen die verzoeken uitvoeren) en een geheugenlimiet van 128 MB of meer voor PHP, met 256 MB aanbevolen. WordPress start standaard met 32 MB, wat voor WooCommerce meestal te weinig is. Let op: dit zijn richtlijnen van één hostingaanbieder, geen wet. Je eigen shop kan meer of minder nodig hebben.
Zware afbeeldingen
Productfoto’s vormen vaak het grootste deel van het gewicht van een pagina. Comprimeer ze (Kinsta noemt JPEG-kwaliteit 85 of lager) en laad ze pas als ze in beeld komen. Dat laatste heet lazyloading. Laad de eerste, grote foto op een productpagina juist niet lazy, want die bepaalt je LCP.
Plug-ins en thema’s die overal scripts laden
Veel plug-ins laden hun code op elke pagina, ook waar ze niets doen. Een betaalscript op de homepage is een voorbeeld dat Kinsta noemt. Zware pagebuilders en thema’s met veel functies kosten extra. Verwijder wat je niet gebruikt en kijk welke plug-ins scripts laden op pagina’s waar dat niet nodig is.
Caching die niet past bij een webshop
Caching bewaart een kant-en-klare versie van een pagina, zodat die niet elke keer opnieuw wordt opgebouwd. Voor een shop moet je winkelwagen, mijn account en afrekenen daar juist van uitsluiten. Staat dat verkeerd, dan zien bezoekers de winkelwagen van een ander of een verouderde prijs. Een goede server-cache regelt die uitzonderingen.
Een volle database
Oude revisies van berichten, verlopen tijdelijke gegevens (transients) en een opgeblazen opties-tabel maken queries trager. Je beperkt revisies met een instelling in WordPress; Kinsta noemt 15 of lager als voorbeeld. Een databaseopschoning doe je bij voorkeur met een back-up in de hand.
Het fragments-verzoek
WooCommerce stuurt op veel pagina’s een extra verzoek om het winkelwagenicoon actueel te houden. In de test van Kinsta duurde dat verzoek 0,76 seconden voor slechts 1,1 KB aan data. Bij een laadtijd van 3 seconden is dat meer dan een kwart. Uitschakelen kan, maar dan moet je wel zorgen dat het winkelwagenicoon nog klopt. Laat dit door iemand doen die weet wat het effect is.
Wat kun je zelf doen, en wat niet?
| Maatregel | Zelf te doen? | Verwacht effect |
|---|---|---|
| Afbeeldingen comprimeren | Ja, met een plug-in of vooraf | Vaak merkbaar op LCP |
| Ongebruikte plug-ins verwijderen | Ja, na een back-up | Minder code en minder verzoeken |
| Reviews pagineren | Ja, in de instellingen | Kleinere productpagina’s |
| Hosting en PHP-instellingen | Deels, vraag je host | Grootste winst bij krappe hosting |
| Caching met uitzonderingen | Liever een specialist | Groot, maar risico bij fouten |
| Scripts per pagina beperken | Specialist | Betere LCP en INP |
| Database en fragments aanpassen | Specialist | Wisselend, afhankelijk van shop |
Wanneer is opknappen niet genoeg?
Soms zit het probleem dieper. Dan helpt de zoveelste optimalisatieplug-in niet meer. Denk aan:
- een thema of pagebuilder die op elke pagina honderden kilobytes aan code meestuurt;
- een assortiment dat zo groot is geworden dat zoeken en filteren de database belasten;
- koppelingen met voorraad- of boekhoudsoftware die bij elke bestelling vastlopen;
- een shop die over jaren door meerdere partijen is aangepast, zonder dat iemand het overzicht heeft.
Dan kan een shop op maat goedkoper zijn dan eindeloos lappen. Een voorbeeld is Schroevendump uit Dordrecht, met meer dan 17.000 bestellingen per jaar. De oude webshop was het assortiment ontgroeid. We bouwden een WooCommerce-webshop op maat in 4 weken, met filters en zoeken, een kortere checkout en een koppeling met het voorraadsysteem. De conversieratio ligt sinds de lancering 35% hoger. Dat getal komt van de hele herbouw, niet van snelheid alleen, dus lees het niet als de winst van een snellere pagina.
Welke vragen stel je een bureau over snelheid?
- Welke scores (LCP, INP, CLS) halen jullie op mobiel, met echte bezoekersdata?
- Op welke hosting draait de shop en hoeveel PHP-workers zijn er?
- Hoe regelen jullie caching voor winkelwagen en afrekenen?
- Wat gebeurt er na de oplevering: wie bewaakt de snelheid als er plug-ins bijkomen?
Dat laatste punt is belangrijk. Een snelle shop blijft niet vanzelf snel. Updates, nieuwe plug-ins en extra marketingscripts trekken hem weer omlaag. Goed onderhoud hoort daarom bij een snelle shop. Wat een maatwerkshop kost, lees je in wat kost een website laten maken in 2026.
Veelgestelde vragen
Google noemt een LCP van 2,5 seconden of sneller “goed”, samen met een INP van 200 milliseconden of minder en een CLS van 0,1 of lager. Dit geldt voor het 75e percentiel van bezoekers, apart voor mobiel en desktop.
Nee, niet per definitie. WooCommerce is flexibel, maar doet veel dynamisch werk, zoals winkelwagen, voorraad en prijzen. Met goede hosting, nette code en juiste caching kan een WooCommerce-shop prima snel zijn. Problemen komen meestal van de omgeving eromheen.
Voor categorie- en productpagina’s vaak wel. Winkelwagen, mijn account en afrekenen kunnen niet uit de cache komen. Als die pagina’s traag zijn, moet je naar hosting, database en scripts kijken.
Dat hangt af van de oorzaak. Een audit laat zien of een paar ingrepen volstaan of dat een herbouw verstandiger is. Vraag een bureau eerst om een meting en een voorstel, voordat je tekent voor een groot traject.
Ja. Bij elke ingreep in plug-ins, database of cache-instellingen maak je eerst een back-up die je kunt terugzetten. Test daarna de bestelflow van begin tot eind.
Loopt je webshop vast op snelheid, zoeken of koppelingen? Lees hoe we webshops op maat bouwen.