Trage WooCommerce checkout oplossen zonder plugin-chaos

De homepage laadt in twee seconden. De productpagina ook. Maar zodra een klant op “Afrekenen” klikt, blijft de spinner draaien. Acht, tien, soms vijftien seconden. En precies daar ligt je conversie.

Een trage checkout is een van de hardnekkigste snelheidsproblemen in WooCommerce. Niet omdat het lastig op te lossen is, maar omdat de oorzaak vrijwel nooit op één plek zit. Het is bijna altijd een combinatie van zware plugins, externe scripts en de manier waarop WooCommerce zelf zijn werk doet.

Dit artikel laat zien hoe je trage WooCommerce checkout oplossen aanpakt zonder paniekerig plugins uit te schakelen. Eerst meten, dan begrijpen, dan ingrijpen.

Eerst meten: waar zit de vertraging echt

Voor je iets verandert, moet je weten waar de seconden blijven hangen. Anders schakel je willekeurig plugins uit en hoop je dat het beter wordt. Dat werkt zelden en breekt vaak iets anders.

Drie tools die je het meeste vertellen:

• Chrome DevTools, tab Performance. Open de checkout, klik op record, voeg een product toe, ga naar de checkout. Stop de opname. Je ziet welke scripts hoe lang draaien.
• PageSpeed Insights. Test specifiek de checkout-URL, niet alleen de homepage. De Field Data laat zien hoe echte gebruikers de pagina ervaren.
• Query Monitor (gratis WordPress-plugin). Logt elke databasequery met de tijd erbij. Op de checkout zie je vaak twintig of meer queries die langer dan honderd milliseconden duren.

Wat ik in de praktijk meet voor een normale WooCommerce-checkout: rond de 1,5 tot 2,5 seconden Largest Contentful Paint op mobiel. Daarboven zit er werk. Boven de 4 seconden is het echt urgent.

Een goede uitleg over wat die Core Web Vitals betekenen, staat op web.dev. Lees dat één keer rustig door voor je verder gaat.

Veelvoorkomende oorzaken in mijn praktijk

Negen van de tien trage WooCommerce-checkouts hebben dezelfde verdachten. Hieronder de patronen die ik bij vrijwel elke diagnose tegenkom.

Te veel actieve plugins op de checkout

WooCommerce laadt op de checkout-pagina standaard al meer scripts dan op een normale pagina. Komen daar een chatwidget, een cookie-banner, twee analytics-pixels en een upsell-plugin bovenop, dan zit je zo op twintig externe verzoeken voor de pagina volledig is.

Mijn aanpak: per plugin checken of hij echt nodig is op de checkout. Veel plugins laten zich beperken tot specifieke pagina’s. Dat scheelt vaak een halve seconde tot een seconde.

Een zwaar of slecht geschreven thema

Sommige populaire thema’s laden hun volledige JavaScript-bundel op elke pagina. Een paginabuilder zoals Elementor of een visueel zwaar thema kan een checkout twee tot drie keer langzamer maken dan nodig.

Verbeteren boven herbouwen geldt ook hier. Een ander thema is een groot project. Eerst kijken wat je in het huidige thema kunt uitschakelen voor de checkout-pagina.

Externe API-calls die wachten op antwoord

Een verzendkoppeling die per checkout-bezoek de tarieven ophaalt bij PostNL of DHL. Een belastingplugin die in real-time controleert. Een fraudechecker die elke klik logt. Als die externe service traag is, staat je checkout stil tot er antwoord komt.

Oplossing: cachen waar mogelijk, of de aanroep verschuiven naar na het laden van de pagina.

Database die rommelig is geworden

WooCommerce-tabellen groeien hard. Verlaten winkelwagens, oude sessies, post revisies, transient options die niet zijn opgeruimd. Een database van een paar jaar oud zonder onderhoud kan checkout-queries fors langzamer maken dan een schone.

Zie het artikel over WooCommerce database opschonen voor de aanpak. Dit is vaak de grootste verborgen winst.

Stapsgewijze diagnose

Een werkvolgorde die ik aanhoud, in plaats van willekeurig plugins uitschakelen. Stuk voor stuk meten of er iets verandert.

1. Maak een backup. Voor elke wijziging een verse backup van bestanden en database. Altijd. Geen uitzondering.
2. Meet de huidige checkout drie keer. Eén keer leeg cache, twee keer met cache. Noteer de cijfers van LCP en totale laadtijd.
3. Schakel third-party scripts één voor één uit op de checkout. Chat, analytics, pixels. Meet na elke wijziging opnieuw. Zo zie je welke het meeste kost.
4. Activeer Query Monitor in een privé-browser-sessie. Bekijk welke queries traag zijn. Vaak komt er één plugin in beeld die buitenproportioneel veel queries doet.
5. Test de checkout met een ander, standaard thema. Tijdelijk wisselen naar Storefront of een vergelijkbaar simpel thema. Als de checkout dan opeens snel is, weet je waar het zit.
6. Controleer de hosting. PHP-versie, geheugen, opcache. Op gedeelde hosting raakt WooCommerce sneller verstopt dan op een server met genoeg lucht.

Werk je dit lijstje door, dan vind je in vrijwel alle gevallen de echte oorzaak. Soms is het één ding. Vaker zijn het twee of drie dingen samen die opgeteld het verschil maken.

Wat echt verschil maakt op mobiel

Op desktop zie je een trage checkout minder snel. Op mobiel wel. Daar speelt elke kilobyte en elke externe verbinding mee. Een paar concrete dingen die op mobiel het meeste opleveren.

• Lazy loading van scripts uitschakelen voor de checkout zelf. Op de checkout wil je dat de pagina meteen klaar is, niet dat er nog scripts in de wacht staan.
• Apple Pay en Google Pay als express-checkout aanbieden. Scheelt vijf tot tien handelingen voor een terugkerende klant.
• AJAX-fragmenten uit de mini-cart minimaliseren. WooCommerce verstuurt standaard veel kleine verzoeken voor de winkelwagenupdate. Op trage verbindingen merk je dat als haperingen.
• HTTP/2 of HTTP/3 op de hosting. Maakt verschil zodra een pagina veel kleine bestanden laadt, zoals een checkout doet.

Een snellere checkout op mobiel betekent niet automatisch hogere conversie, maar het wegnemen van wachttijd helpt vrijwel altijd. Vooral bij eerste bezoekers.

Voorbeeldscenario: een drukke checkout

Een fictief maar realistisch beeld. Dit is een voorbeeldscenario, niet een echte klant.

Stel: een WooCommerce-shop met ongeveer tweehonderd producten, drie jaar oud. De checkout deed acht seconden op mobiel. Bij diagnose kwam het volgende naar boven:

• een chatwidget die alleen op de homepage hoorde te staan, laadde sitewide
• een verzendplugin die elke checkout-bezoek tarieven ophaalde bij twee koeriers, beide traag
• een upsell-plugin die zelfs op de checkout-pagina nog cross-sells berekende
• de database had veertienduizend verlaten winkelwagens die niet werden opgeruimd

Wat erin ging: chatwidget beperkt tot de homepage, verzendtarieven gecached voor 24 uur, upsell uitgeschakeld op checkout, database opgeschoond. Resultaat is per project anders, maar de combinatie van kleine ingrepen telt vaak op tot een halvering van de laadtijd.

Geen wondermiddel, wel concreet werk. Het soort taak waar een paar uur structureel werk meer oplevert dan een nieuwe plugin installeren.

Wat ik bewust niet doe

Een paar dingen die in andere artikelen vaak als “snelle fix” worden genoemd, maar die ik in de praktijk vermijd:

• Geen vier cache-plugins door elkaar. Een goede cache-plugin volstaat. Soms zelfs geen, als de hosting al cacht. Stapelen geeft meer problemen dan winst.
• Geen “snelheidsboost”-plugins zonder te weten wat ze doen. Sommige zetten dingen uit die je productpagina kapot maken.
• Geen herbouw als eerste stap. Verbeteren boven herbouwen. Pas als een checkout fundamenteel verkeerd zit, is herbouw zinvol.

Ik ben technisch implementeerder, geen SEO-strateeg. De checkout sneller maken is implementatiewerk. De vraag of een snellere checkout ook tot meer omzet leidt, hoort thuis bij een marketingadviseur. Voor strategie verwijs ik je door.