WooCommerce checkout wordt traag bij een grote catalogus: waar begin je?
4 berichten · 32 weergaven
A
Albert
Lid
OP #128 juli 2026, 20:26
Mijn WooCommerce-shop groeit en de checkout wordt merkbaar trager nu de catalogus richting een paar duizend producten gaat. De rest van de site is prima, alleen het afrekenen hapert. Ik vermoed te veel queries of een zware plugin, maar ik weet niet waar ik moet beginnen met meten. Draaien jullie Query Monitor, of pakken jullie het op serverniveau aan? Alle tips voor het profileren zijn welkom.
C
Cas
Lid
#229 juli 2026, 04:26
Voordat je in de plugins duikt: kijk eerst of het echt de applicatie is en niet de database. Ik had precies dit, en het bleek een trage query plus autoload-opties die veel te groot waren geworden. Query Monitor op de checkout-pagina laat vaak binnen een minuut zien welke query eruit springt. Zet daarnaast object caching aan als je dat nog niet hebt, dat scheelde bij mij het meest.
Angelo
Lid
Beste antwoord #39 augustus 2026, 07:52
Goede vraag, en herkenbaar. De kern zit hem hierin: je checkout is bijna nooit te cachen (WooCommerce sluit cart/checkout terecht uit van page-cache omdat het per bezoeker dynamisch is).
De rest van je site draait waarschijnlijk op een pagecache en voelt daardoor snel, terwijl de checkout de "kale" prestatie van je stack laat zien. Die traagheid was er dus altijd al, hij wordt alleen zichtbaar op het enige niet-gecachete pad. De oplossing is dan ook: dat dynamische pad snel maken.
Eerst meten, dan pas sleutelen. Zo pak ik het aan:
1. Query Monitor (begin hier, gratis en snel)
Ja, Query Monitor is de eerste stap. Installeer 'm, log in als admin en open de checkout. Let vooral op:
- Queries → Sorteer op tijd en groepeer op Component. Zo zie je meteen welke plugin (of core) de trage/dubbele queries veroorzaakt.
- Duplicate queries — WooCommerce-plugins die dezelfde meta keer op keer ophalen zijn een klassieker.
- HTTP API Calls — dit is goud. Een payment- of verzendplugin die tijdens het laden van de checkout een externe API belt, blokkeert je hele pagina. Dit zie je nergens anders zo snel.
Belangrijke valkuil: het zware werk op de checkout zit vaak niet in de eerste paginalaad, maar in de AJAX-herberekening. Bij de klassieke (shortcode) checkout is dat ?wc-ajax=update_order_review (vuurt bij elke wijziging van een veld), bij de nieuwere Checkout-block is het de Store API (/wp-json/wc/store/...).
Open je browser-devtools (F12) → tabblad Network, doorloop de checkout, en kijk welke request een hoge TTFB heeft. Zo weet je meteen of het de eerste laad is of de recalculatie.
Meet ook een keer uitgelogd/incognito met devtools, want als admin heb je een andere load (admin bar, geen cache).
2. Serverniveau (voor de diepere oorzaak)
Query Monitor wijst meestal al de richting aan. Wil je functie-niveau zien wat de tijd opeet, dan pak je het op de server:
- PHP-FPM slowlog (request_slowlog_timeout in je pool-config). Die dumpt de PHP-stacktrace van elke trage request. Ideaal om zonder gedoe een blokkerende externe call of een trage functie te vinden.
- MySQL slow query log aanzetten (long_query_time laag), de trage queries eruit halen en er EXPLAIN op draaien.
- Een echte profiler als Blackfire, Tideways of New Relic geeft je een flame graph: precies welke plugin/functie hoeveel tijd kost. Dit is het krachtigst, maar Query Monitor + slowlog brengt je meestal al bij de dader.
3. Meest voorkomende oorzaken bij een groeiende catalogus
Op volgorde van "vaak raak":
- Geen persistente object cache. Zonder Redis of Memcached gaan alle transients en WooCommerce-sessies naar de database. Installeer Redis + Redis Object Cache. Voor een niet-cachebare checkout is dit vaak de grootste winst.
- Opgeblazen autoload in wp_options. Check: SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS mb FROM wp_options WHERE autoload = 'yes';
- Zit je boven ~1 MB, dan wordt elke request afgeremd. Ruim verweesde autoload-opties van oude plugins op.
- Action Scheduler-bloat. Bij WooCommerce loopt wp_actionscheduler_actions snel vol. Kijk onder WooCommerce → Status → Geplande acties (of wp action-scheduler clean via WP-CLI).
- Product lookup-tabel stuk of verouderd. WooCommerce → Status → Hulpmiddelen → Producttabellen opnieuw genereren. Die wc_product_meta_lookup-tabel houdt productquery's snel; is die scheef, dan val je terug op trage postmeta-joins, en dat schaalt slecht met duizenden producten.
- Verzendberekening. Table-rate plugins met veel regels, of een koeriers-API die live wordt aangeroepen, kunnen de checkout ophouden. Test: zet tijdelijk een simpele flat rate en kijk of het scheelt.
- Payment gateway. Sommige gateways initialiseren bij het laden van de checkout. Test met BACS/overboeking; scheelt dat veel, dan zit het daar.
- Database-indexen op grote tabellen. Bij een grote wp_postmeta helpt de plugin Index WP MySQL For Speed (voegt betere indexen toe aan de WP-kern tabellen). Vaak een flinke sprong bij grote catalogi.
- Basis op orde: PHP 8.2/8.3 of hoger in plaats van 7.x, OPcache aan, genoeg PHP-geheugen, en een MariaDB/MySQL met een fatsoenlijke buffer pool.
Praktische volgorde
- Query Monitor + devtools Network → is het de laad of de AJAX/Store-API-call, en welke component?
- Redis object cache aanzetten en autoload opschonen (bijna altijd winst).
- Product lookup-tabellen regenereren + Action Scheduler opschonen.
- Bisect: op een staging-kopie plugins in helften uitzetten tot de boosdoener bovenkomt (Query Monitor wijst 'm meestal al aan).
- Blijft er iets hangen op functie-niveau, dan een profiler (Blackfire/Tideways) of de PHP-FPM slowlog erbij.
Dus wat ik zou doen in het kort:
Query Monitor eerst om de dader te vinden, object cache + opschonen als quick wins, en serverniveau (slowlog/profiler) voor de laatste hardnekkige gevallen. Meestal blijkt het een specifieke plugin of een externe API-call op het checkout-pad te zijn. Laat je horen wat Query Monitor bij de update_order_review- of Store-API-call laat zien, dan denken we mee.
A
Albert
Lid
#414 augustus 2026, 14:02
Dankjewel Cas en Angelo!
Dankzij jullie advies heb ik de hele checkout aanzienlijk kunnen verbeteren.
Het is nu heel snel, en zelfs de Google Lighthouse testen geven een zeer hoge scoren!