Bij Robuust regelen wij dit voor je. WooCommerce-shops draaien bij ons op VPS-niveau met objectcache en een migratieplan voor HPOS. Wil je weten waar de winst zit? Lees verder.
Als een WooCommerce-shop traag wordt, is het eerste advies dat iemand krijgt bijna altijd hetzelfde: installeer een cacheplugin, optimaliseer je afbeeldingen, kies een lichter thema. Dat is niet verkeerd, maar het is wel het verkeerde begin.
De reden: de trage delen van een webshop zijn precies de delen die je niet kunt cachen. Je productoverzicht kun je serveren vanuit cache. Je winkelwagen, je afrekenpagina, je accountpagina en je hele beheeromgeving niet. Die zijn per bezoeker anders en raken de database rechtstreeks. En dáár zit het probleem.
Waarom WooCommerce structureel vastloopt
WordPress is gebouwd om artikelen te publiceren. Alles wat je maakt (een pagina, een blogpost, een menu-item) belandt in twee tabellen: wp_posts voor de hoofdgegevens en wp_postmeta voor alle bijbehorende velden.
WooCommerce is bovenop dat systeem gebouwd. Dus toen er bestellingen bij kwamen, gingen die ook in wp_posts. Elke bestelling werd een "post", en elk detail van die bestelling (factuuradres, verzendadres, betaalmethode, transactie-ID, btw-bedrag, verzendkosten) werd een aparte rij in wp_postmeta.
Reken mee. Eén bestelling levert al snel veertig tot zestig rijen op in wp_postmeta. Duizend bestellingen zijn dus zo'n 50.000 rijen. Tienduizend bestellingen: een half miljoen rijen, in een tabel die ook nog alle metadata van je pagina's, producten en blogposts bevat.
En die tabel heeft geen indexen die voor bestellingen zijn ontworpen. Wil je "alle bestellingen van deze klant van vorige maand", dan moet de database daarvoor door een berg ongerelateerde data ploegen. Dat is waarom je beheerscherm met bestellingen langzaam onwerkbaar wordt, en waarom afrekenen bij piekdrukte hapert.
Wat HPOS eraan doet
High-Performance Order Storage haalt bestellingen uit die algemene tabellen en zet ze in eigen tabellen, speciaal ontworpen voor e-commerce en voorzien van de juiste indexen.
Het effect dat WooCommerce zelf rapporteert:
- Tot 5× snellere orderaanmaak
- Tot 1,5× sneller afrekenen
- Aanzienlijk sneller zoeken en filteren in je orderbeheer
- Minder gelijktijdige schrijfacties op dezelfde tabel, wat blokkades bij drukte voorkomt
Dat laatste punt is het onderschatte punt. Bij piekverkeer schrijven meerdere bestellingen tegelijk naar dezelfde tabel waar ook je pagina's in staan. Aparte ordertabellen halen die concurrentie weg, precies op het moment dat je het nodig hebt.
Sinds WooCommerce 10.4 (december 2025) is ook de bijbehorende cachinglaag van HPOS geen experimentele functie meer, maar een reguliere optie. Daarmee is de belangrijkste reden om nog te wachten vervallen.
HPOS aanzetten: doe het in deze volgorde
Dit is een databasemigratie. Niet gevaarlijk, wel onomkeerbaar genoeg om zorgvuldig te zijn.
1. Maak een back-up en test op staging. Niet overslaan. Dit is precies waar een staging-omgeving voor bestaat.
2. Controleer je plugins. Elke plugin die met bestellingen werkt (je betaalprovider, je boekhoudkoppeling, je verzendplugin, je factuurgenerator) moet HPOS-compatibel zijn. WooCommerce toont dit in het scherm onder WooCommerce → Instellingen → Geavanceerd → Functies. Zie je daar een plugin als incompatibel staan, dan werk je die eerst bij of vervang je hem. Ga niet door met een waarschuwing op het scherm.
3. Zet compatibiliteitsmodus aan. Deze modus synchroniseert bestellingen naar zowel de oude als de nieuwe tabellen. Bestaande shops moeten hier doorheen, zodat beide sets tabellen gelijk lopen voordat je omschakelt.
4. Laat de synchronisatie afronden. Bij een grote shop kan dat even duren. Wacht tot hij klaar is.
5. Schakel om naar HPOS als leidende opslag. Vanaf dat moment zijn de nieuwe tabellen de waarheid.
6. Laat compatibiliteitsmodus nog even aan: een week of twee. Werkt alles, dan kun je hem uitzetten en de dubbele schrijfacties besparen.
Nieuwe shops hebben dit standaard al aan. Shops die al jaren draaien vaak niet, en dat zijn precies de shops met de meeste bestellingen en dus de meeste winst.
Wat je daarna aanpakt
Met HPOS op orde loont de rest van de optimalisatie pas echt.
Objectcache (Redis)
Dit is de tweede grote stap. Objectcache bewaart losse databaseresultaten in het werkgeheugen. Voor een webshop is dat cruciaal, want juist de pagina's die je niet volledig kunt cachen (winkelwagen, account, gefilterde overzichten) leunen op tientallen query's die voor iedereen hetzelfde zijn.
Op gedeelde hosting is Redis meestal niet beschikbaar. Dat is een van de duidelijkste redenen om voor een serieuze shop naar een VPS te gaan.
De juiste pagina's uitsluiten van cache
Controleer dat deze nóóit als statische pagina gecachet worden:
- Winkelwagen
- Afrekenen
- Mijn account
- Elke pagina met een sessie-afhankelijke prijs
De meeste cacheplugins sluiten deze standaard uit. Heb je een aangepaste checkout of afwijkende URL's, dan is dat niet gegarandeerd. Test het door in een privévenster te kijken of je andermans winkelwagen ziet. Zie je die, dan heb je geen prestatieprobleem maar een datalek.
Opruimen wat je niet nodig hebt
Groeiende WooCommerce-databases lopen vol met:
- Verlopen transients: tijdelijke gegevens die niet altijd netjes worden opgeruimd.
- Actie-Scheduler-logs. WooCommerce plant achtergrondtaken en bewaart de geschiedenis. Op oudere shops staan hier soms honderdduizenden rijen.
- Productrevisies. Elke keer dat je een productomschrijving aanpast, wordt de oude versie bewaard. Beperk dit in je configuratie.
- Verweesde metadata van plugins die je jaren geleden hebt verwijderd.
Eén opruimactie levert op een oudere shop vaak honderden megabytes en merkbaar snellere query's op.
Je productoverzicht
Hier zit vaak onnodige zwaarte: het aantal producten per pagina te hoog gezet, filters die bij elke wijziging de hele catalogus opnieuw doorzoeken, en afbeeldingen die op volle resolutie worden ingeladen en met CSS worden verkleind.
Praktische regels: maximaal 24 producten per pagina, gebruik loading="lazy" op alles onder de vouw, en serveer moderne beeldformaten.
Wat je meet, en wat niet
Meet je snelheid op de pagina's die ertoe doen: een productpagina, en het traject van winkelwagen naar afrekenen. Een snelle homepage zegt niets over de plek waar je omzet ontstaat.
En meet de eerste laadbeurt, niet de tweede. De tweede komt uit cache en vertelt je vooral dat je cache werkt.
Voor je beheeromgeving is de simpelste graadmeter: hoe lang duurt het om je bestellingenoverzicht te openen? Duurt dat meer dan een paar seconden, dan heb je een databaseprobleem, geen frontendprobleem, en geen enkele cacheplugin gaat dat oplossen.
Kort samengevat
- Zet HPOS aan. Grootste winst, eenmalige migratie, en de belangrijkste blokkade is sinds versie 10.4 weg.
- Voeg objectcache toe als je op een VPS zit, en overweeg een VPS als je dat niet doet.
- Controleer je cache-uitsluitingen. Dit is een risico, geen optimalisatie.
- Ruim je database op, jaarlijks.
- Meet op de checkout, niet op de homepage.
Een WooCommerce-shop die traag wordt naarmate hij succesvoller wordt, heeft zelden een thema-probleem. Hij heeft een databasearchitectuur die voor blogartikelen is ontworpen en die je nu vraagt om een webwinkel te draaien. HPOS is precies de reparatie daarvan, en het staat al klaar in je instellingen.