Een trage WooCommerce-shop heeft bijna altijd een van deze oorzaken: oncachebare pagina's (winkelwagen, checkout, ingelogde klanten) die op elke klik de volledige PHP- en databasestack draaien, een database vol oude sessies en transients, te veel of te zware plugins, botverkeer dat je filter-URL's afstruint, of hosting die gebouwd is voor brochurewebsites in plaats van shops. De oplossing is meestal een combinatie: meten waar de tijd zit, paginacache voor de bezoekpagina's, Redis voor het dynamische deel, database en plugins opruimen, en bots buiten de deur houden. Hieronder loop ik die stappen een voor een langs — in de volgorde waarin ik ze zelf aanpak.
Sinds 2006 beheer ik bij Correcthosting de hosting van zo'n duizend mkb-bedrijven, waaronder flink wat WooCommerce- en Magento-shops. De patronen hieronder kom ik dus niet uit de theorie tegen, maar wekelijks in de praktijk.
Waarom een shop trager is dan een gewone website
Eerst het belangrijkste inzicht, want dit verklaart de helft van alle "mijn shop is traag"-vragen: een webshop is geen brochurewebsite.
Een gewone WordPress-site kan bijna volledig uit de paginacache geserveerd worden. De server bouwt een pagina één keer op, slaat het resultaat op, en duizend volgende bezoekers krijgen die kopie in milliseconden. PHP en de database komen er nauwelijks aan te pas.
Bij een shop werkt dat maar half. Zodra iemand iets in zijn winkelwagen legt, inlogt of gaat afrekenen, is elke pagina uniek voor die bezoeker. Winkelwagen en checkout zijn per definitie oncachebaar — je wilt niet dat klant B de winkelwagen van klant A te zien krijgt. Elke klik van zo'n bezoeker draait dus de volledige stack: PHP start op, alle plugins laden, WooCommerce bouwt de sessie op, de database wordt tientallen keren bevraagd.
Dat betekent: een shop vraagt per bezoeker een veelvoud aan serverwerk vergeleken met een gewone site. Houd dat in je achterhoofd bij alles wat volgt.
Stap 1: Meet eerst — welke pagina's zijn traag, en voor wie?
Begin niet met plugins installeren, begin met meten. Anders optimaliseer je op de verkeerde plek.
- Welke pagina's zijn traag? Homepage, categoriepagina's, productpagina's, winkelwagen, checkout? Test ze apart.
- Anoniem of ingelogd? Test in een gewoon browservenster én in een incognitovenster zonder items in de winkelwagen. Is de shop anoniem snel maar met een gevulde winkelwagen traag, dan weet je dat je probleem in het dynamische deel zit (PHP, database) en niet in de paginacache.
- Frontend of backend? Kijk in de netwerktab van je browser (F12) naar de TTFB — de tijd tot de eerste byte. Een hoge TTFB (boven de ~600 ms) betekent dat de server lang rekent. Een lage TTFB met toch een trage pagina wijst naar zware afbeeldingen, scripts of het thema.
Deze tien minuten meetwerk bepalen welke van de volgende stappen bij jou het meest oplevert.
Stap 2: Zet goede paginacache aan — maar besef dat het het halve verhaal is
Voor alle anonieme bezoekpagina's — home, categorieën, producten — is paginacache de grootste winst. Die pagina's veranderen zelden en kunnen prima uit de cache komen. Op serverniveau (LiteSpeed Cache, nginx-cache) werkt dat beter dan een losse PHP-plugin, omdat PHP dan helemaal niet opstart.
Maar voor een shop is dit maar het halve verhaal. De pagina's waar het geld verdiend wordt — winkelwagen en checkout — vallen buiten de cache, en iedere bezoeker met een gevulde winkelwagen krijgt óók zijn productpagina's vaak dynamisch (denk aan het winkelwagen-icoontje met aantal). Wie alleen paginacache aanzet en denkt klaar te zijn, heeft precies het bestelproces niet versneld.
Controleer ook dat je cache-plugin WooCommerce correct uitsluit: winkelwagen, checkout en account-pagina's mogen nooit gecachet worden.
Stap 3: Zet Redis in voor het dynamische deel
Voor alles wat níét uit de paginacache kan komen, is een object cache de belangrijkste versneller. Redis houdt de resultaten van databasequery's in het werkgeheugen. WordPress vraagt per paginaweergave al snel honderden dingen op — opties, productgegevens, termen, sessies. Zonder object cache gaat elke vraag naar de database; met Redis komt het overgrote deel uit het geheugen.
Juist voor een shop, met zijn vele oncachebare pagina's, is dit het verschil tussen een checkout van drie seconden en eentje van onder de seconde. Redis vereist wel dat je hoster het aanbiedt en dat er een koppelplugin actief is (zoals Redis Object Cache). Staat het er niet op? Vraag het je hoster — op serieuze WooCommerce-hosting hoort dit standaard te zijn.
Stap 4: Ruim je database op
WooCommerce-databases groeien stilletjes dicht:
- Sessies: de tabel
wp_woocommerce_sessionskan tienduizenden verlopen sessies bevatten, vaak aangemaakt door bots. - Transients: verlopen transients in
wp_optionsblijven staan en maken die tabel — die bij elke paginaweergave wordt gelezen — onnodig zwaar. Vooral autoloaded opties zijn een sluipmoordenaar: die worden állemaal bij elke request ingeladen. - Orderhistorie en logs: jaren aan orders, ordernotities, actielogs (Action Scheduler) en plugin-logtabellen. Orders wil je bewaren, maar afgeronde Action Scheduler-taken en oude logs kunnen weg.
Opruimen kan met WP-CLI (wp transient delete --expired), via de WooCommerce-statuspagina, of laat je hoster er even doorheen lopen. Maak eerst een back-up — dat spreekt voor zich, maar ik zeg het toch.
Stap 5: Saneer je plugins
Dit is de stap die het vaakst wordt overgeslagen en het vaakst het probleem is. Elke pagelaad draait álle actieve plugins mee — ook op pagina's waar die plugin niets doet. Een formulierplugin laadt zijn code ook op je productpagina's; een "alles-in-één"-optimalisatieplugin hangt overal tussen.
Ik kom regelmatig shops tegen waar één zware plugin — vaak zo'n alles-in-één-pakket met twintig functies waarvan er twee gebruikt worden — in zijn eentje de halve laadtijd voor zijn rekening neemt. Aanpak:
- Loop de pluginlijst na: wat gebruik je écht?
- Deactiveer wat overbodig is en verwijder het daarna ook (gedeactiveerde plugins zijn een veiligheidsrisico).
- Vervang zware multifunctie-plugins door één lichte plugin die precies doet wat je nodig hebt.
- Twijfel je welke plugin de boosdoener is? Met een profiler (Query Monitor, of profiling op serverniveau) zie je per plugin wat hij kost.
Stap 6: Optimaliseer je afbeeldingen
Productfoto's zijn vaak het zwaarste deel van de pagina. Drie dingen:
- Moderne formaten: lever WebP (of AVIF) in plaats van JPEG/PNG. Dat scheelt al snel 30–70% aan bytes, zonder zichtbaar kwaliteitsverlies.
- Juiste afmetingen: een foto van 4000 pixels breed die op 300 pixels wordt getoond, is pure verspilling. Zorg dat WordPress de juiste tussenmaten genereert en gebruikt.
- Lazy loading: afbeeldingen onder de vouw pas laden als de bezoeker erheen scrolt. WordPress doet dit tegenwoordig standaard; controleer dat je thema het niet saboteert.
Stap 7: Draai een actuele PHP-versie
Elke grote PHP-versie is merkbaar sneller dan de vorige; het verschil tussen een verouderde en een actuele versie kan zomaar tientallen procenten schelen op precies het dynamische werk waar een shop zwaar op leunt. Bovendien krijgen oude versies geen beveiligingsupdates meer.
Check je versie via de WooCommerce-statuspagina. Draai je nog op een versie die end-of-life is, plan dan een upgrade — test eerst op een staging-omgeving, want oude plugins kunnen struikelen over nieuwe PHP-versies.
Stap 8: Beperk externe scripts en trackers
Chatwidgets, reviewwidgets, meerdere analytics-pakketten, heatmaps, pixels van drie advertentieplatformen — het stapelt zich op. Elk extern script betekent een extra verbinding naar een server waar jij geen invloed op hebt, en veel van die scripts blokkeren het opbouwen van je pagina.
Loop ze na: wat levert daadwerkelijk iets op? Gooi de rest eruit. Wat blijft, laad je waar mogelijk uitgesteld (defer/async), zodat het je pagina niet ophoudt. Vaak is dit een kwestie van een halfjaar geleden "even iets uitproberen" en het nooit meer weghalen.
Stap 9: Weeg je thema en pagebuilder
Sommige thema's en pagebuilders genereren voor een simpele productpagina honderden kilobytes aan CSS en JavaScript en tientallen extra databasequery's. Dat merk je op élke pagina.
Radicaal van thema wisselen is een project, dus wees realistisch: begin met wat kan zonder herbouw — ongebruikte thema-modules uitzetten, de ingebouwde "performance"-opties van je builder aanzetten, demo-content en ongebruikte templates weggooien. Sta je toch voor een redesign, kies dan een licht thema en gebruik de standaard WordPress-blokken of de Woo-eigen blokken waar het kan.
Stap 10: Houd bots en crawlers buiten de deur
De onzichtbaarste oorzaak, en in mijn praktijk een van de grootste. Webwinkel-crawlers, prijsvergelijkers en scrapers lopen systematisch je hele shop af — inclusief alle filter-URL's. Elke combinatie van kleur, maat, merk en sortering is een eigen URL (?filter_kleur=rood&orderby=price&min_price=10), en dat zijn er bij een gemiddelde shop al snel tienduizenden. Vrijwel allemaal oncachebaar, dus elke request draait de volle PHP- en databasestack.
Het resultaat: een server die dag en nacht op 100% draait voor "bezoekers" die nooit iets kopen, terwijl je echte klanten in de wachtrij staan. Ik heb shops gezien waar méér dan de helft van alle serverwerk naar dit soort botverkeer ging.
Aanpak: filter dit op serverniveau. Blokkeer of vertraag agressieve crawlers, sluit de eindeloze filtercombinaties uit voor bots (robots.txt helpt bij de nette; de rest vang je met regels op de webserver of firewall), en laat zoekmachines alleen de URL's crawlen die er echt toe doen. Dit is typisch iets wat je hoster voor je hoort in te richten.
Wat dit in de praktijk oplevert
Een herkenbaar patroon uit mijn eigen beheer: een shop waar de laadtijd op drie tot vier seconden hing. Oorzaak, na meten: één alles-in-één-plugin die op elke request meedraaide, geen object cache, en een bot die continu duizenden filter-URL's afstruinde. Na Redis aanzetten, het botverkeer op serverniveau filteren en de pluginlijst saneren, zat dezelfde shop — op dezelfde server — onder de seconde. Geen nieuwe hardware, geen herbouw; gewoon de juiste knoppen in de juiste volgorde.
Dat is meteen de samenvatting van dit hele artikel: meet eerst, pak dan het dynamische deel aan (Redis, database, plugins), dek de bezoekpagina's af met paginacache, en zorg dat je server zijn tijd besteedt aan klanten in plaats van aan bots.
En als de hosting zelf het probleem is?
Alle bovenstaande stappen veronderstellen dat de onderliggende hosting past bij een shop. Dat is niet vanzelfsprekend: een shop vraagt meer PHP-werk per bezoeker, snelle opslag voor de database, Redis, en iemand die botverkeer voor je in de gaten houdt. Loopt je shop vast met een 500 Internal Server Error in plaats van gewoon traag, dan speelt er waarschijnlijk iets anders. Op een pakket dat is ingericht op statische websites loop je met een groeiende shop vroeg of laat tegen een plafond aan, hoe goed je ook optimaliseert.