De eigenaar van een webshop in tuinartikelen uit de omgeving van Breda had geen snelheidsprobleem, dacht hij. Hij had een omzetprobleem. Het aantal bezoekers groeide door advertenties, maar het aantal bestellingen bleef hangen. Zijn advertentiebureau wees naar de shop, de shopbouwer wees naar de advertenties. Hij wilde iemand die naar de cijfers keek in plaats van naar de ander.

Deze case gaat over het verband tussen webshop snelheid en conversie, en over hoe u kunt vaststellen of traagheid daadwerkelijk klanten kost voordat u er geld in steekt. De cijfers zijn afgerond, de shop is geanonimiseerd.

Situatie: bezoekers die halverwege verdwenen

De shop draaide op WooCommerce met ongeveer 1.400 producten, een filterplugin, een premium thema en een stuk of 40 plugins. Rond de 18.000 bezoekers per maand, waarvan ongeveer een derde via betaalde advertenties. De conversie lag op 1,1 procent. Voor een shop met producten van gemiddeld 65 euro is dat aan de lage kant, maar niet dramatisch.

Het interessante zat in de statistieken per stap. Van de bezoekers die een productpagina openden, kwam een opvallend klein deel op de categoriepagina met filters terecht, en van de mensen die iets in de winkelwagen legden, haakte ruim 70 procent af vóór de betaalstap. Op mobiel was dat nog hoger.

Toen we gingen meten, werd het beeld helder. De categoriepagina met filters laadde op mobiel in 6,8 seconden en elke filterklik kostte nog eens 3 tot 4 seconden voordat de producten ververst waren. De checkout deed er ruim 5 seconden over om te verschijnen en reageerde traag op het invullen van velden. Kortom: precies op de momenten dat een klant een beslissing nam, liet de shop hem wachten.

Aanpak: eerst meten waar het pijn doet

We hebben bewust niet de homepage geoptimaliseerd. Die was al redelijk. De winst zat in drie plekken: categoriepagina’s, productpagina’s en de checkout. Per plek de aanpak:

Categoriepagina’s en filters

De filterplugin voerde bij elke klik zware databasequery’s uit over alle productattributen. Na het toevoegen van objectcaching met Redis en het opschonen van de producttabellen (verlopen sessies, oude orderaantekeningen, honderdduizenden regels aan productmetadata van een oude importplugin) daalde de filterreactie naar ongeveer een halve seconde. Verder zijn de productafbeeldingen in het overzicht teruggebracht van 1.200 naar 400 pixels breed, want groter werd niet getoond.

Productpagina’s

Hier laadden per pagina zes tot tien foto’s in volle resolutie plus een zoomscript, een reviewwidget en een “anderen kochten ook”-blok dat live berekend werd. De foto’s zijn omgezet naar WebP met passende maten. Het aanbevelingenblok wordt nu één keer per dag berekend en gecached. Het zoomscript laadt pas als iemand een foto aanraakt.

Checkout

De grootste verrassing. De betaalpagina laadde de scripts van drie betaalproviders, waarvan er nog maar één in gebruik was, plus een chatwidget en een trackingpixel die de pagina blokkeerde tot hij geladen was. Na het verwijderen van de ongebruikte providers en het uitstellen van chat en tracking tot na het laden, verscheen de checkout in ongeveer anderhalve seconde en reageerden de velden direct.

Alle wijzigingen zijn eerst op een staging-kopie doorgevoerd en daar getest met een echte proefbestelling via iDEAL, voordat ze live gingen. Bij een webshop is dat geen luxe; een kapotte checkout kost per uur meer dan de hele optimalisatie.

Resultaat na twee maanden

  • Categoriepagina mobiel: van 6,8 naar 2,1 seconden; filterklik van 3 à 4 seconden naar ongeveer 0,5.
  • Productpagina mobiel: van 5,9 naar 2,0 seconden.
  • Checkout: van ruim 5 naar circa 1,5 seconden.
  • Afhakers in de winkelwagen: van ruim 70 procent naar ongeveer 58 procent.
  • Conversie: van 1,1 naar 1,4 procent bij vergelijkbaar bezoek. Dat kwam neer op 23 procent meer bestellingen in de twee maanden na de optimalisatie, vergeleken met de twee maanden ervoor.

Een eerlijke kanttekening: twee maanden is kort, en de shop draaide tegelijk een voorjaarsactie. We hebben daarom ook de conversie per verkeersbron vergeleken, en die steeg bij alle bronnen in dezelfde orde van grootte. Dat maakt het aannemelijk dat de snelheid de belangrijkste factor was, al is honderd procent zekerheid in dit soort cijfers nooit te geven.

Wat deze case leert

Kijk naar de stappen, niet naar het totaal. De totale conversie zei weinig. De uitval per stap wees precies naar de trage pagina’s. Elk analyticspakket kan dit tonen; het vergt een uur kijken.

Optimaliseer waar beslissingen vallen. Een snelle homepage is prettig, maar een klant beslist op de productpagina en in de checkout. Daar telt elke seconde dubbel. Meer concrete aanpassingen voor productpagina’s, filters en winkelwagen staan in dit stappenplan om WooCommerce sneller te maken.

Opruimen is de helft van het werk. Ongebruikte betaalproviders, oude importdata, een tweede reviewplugin: het stapelt zich in een paar jaar geruisloos op. Niets daarvan was ooit bewust gekozen.

Reken het uit voordat u begint. Bij 18.000 bezoekers en 65 euro per order is een paar tienden procent conversie al snel duizenden euro’s per maand. Hoe u die som voor uw eigen situatie maakt, leest u in dit artikel over wat laadtijd u kost.

Voor uw eigen webshop

Begin bij de cijfers die u al heeft: waar in de bestelroute haken mensen af? Meet vervolgens precies die pagina’s op een telefoon. Als de checkout of de categoriepagina er meer dan drie seconden over doet, is de kans groot dat u op dezelfde plek omzet laat liggen als de tuinshop uit deze case.

Voor een WooCommerce-shop is een eenmalige structurele snelheidsoptimalisatie het meest zinvol als hij gericht is op de bestelroute en getest wordt met een echte proefbestelling. Dat is ook hoe WebMaintor het aanpakt, maar welk bureau u ook kiest: vraag om metingen per stap, voor en na, en niet om één score voor de homepage. Uw klanten bestellen nu eenmaal niet op de homepage.