Een gewone bedrijfssite sneller maken is een kwestie van lichtere afbeeldingen, minder plugins en een goede paginacache. Bij een webshop komt u daar niet mee weg. Precies de pagina’s waar het geld verdiend wordt, de winkelwagen en de afrekenpagina, mogen namelijk helemaal niet in de cache. Ze moeten voor iedere bezoeker apart worden opgebouwd.
Daar komt bij dat WooCommerce meer database-werk doet dan een gewone site: voorraden bijhouden, prijzen berekenen, verzendkosten bepalen, kortingen controleren. Wie WooCommerce sneller maken wil, moet dus weten waar de tijd naartoe gaat. Hieronder loopt u de vier gebieden langs waar in onze ervaring de meeste winst zit.
Eerst meten: welk deel is traag?
Meet nooit alleen de homepage. Een webshop heeft vier soorten pagina’s die zich totaal verschillend gedragen, en u wilt ze los van elkaar beoordelen:
- De homepage en informatiepagina’s. Volledig cachebaar, gedragen zich als een gewone site.
- Categoriepagina’s met filters. Deels cachebaar, maar zodra er gefilterd wordt ontstaat er een unieke pagina.
- Productpagina’s. Cachebaar zolang de bezoeker niet is ingelogd en de voorraad niet live getoond wordt.
- Winkelwagen, afrekenen en mijn account. Nooit cachebaar. Hier telt hoe snel uw server rekent.
Vul uw winkelwagen met een product en meet daarna de afrekenpagina. Duurt het opbouwen daar meer dan anderhalve seconde voordat de eerste byte komt, dan ligt uw probleem bij de server en de database, niet bij uw afbeeldingen. Hoe u die wachttijd interpreteert, staat in ons artikel over de reactietijd van uw server.
Productpagina’s en categorieoverzichten
Hier zit meestal het meeste zichtbare gewicht. Vier maatregelen die vrijwel altijd werken:
Beperk het aantal producten per pagina. Veel shops tonen er 24 of zelfs 48 in een raster. Elk product betekent een afbeelding, een prijsberekening en vaak een voorraadcontrole. Twaalf tot zestien per pagina is voor de meeste shops genoeg en scheelt de helft van het werk.
Kies verstandige afbeeldingsformaten. WooCommerce genereert eigen formaten voor de catalogus, de productpagina en de miniaturen. Staan die te groot ingesteld, dan laadt uw categoriepagina zestien foto’s van elk 800 pixels breed voor kaders van 300 pixels. Pas de formaten aan onder Weergave in het thema-aanpassingsscherm en laat daarna de miniaturen opnieuw genereren.
Wees terughoudend met wat er op de kaart staat. Sterbeoordelingen, kortingslabels, voorraadindicatoren, kleurstalen en een snelle-weergaveknop: elk element voegt code en soms een extra databasevraag toe. Per stuk lijkt het niets, maal zestien producten is het merkbaar.
Kijk kritisch naar galerijen. De productgalerij van WooCommerce laadt een zoomfunctie, een schuifbibliotheek en een lichtbak. Gebruikt u het zoomen niet, zet het dan uit. Dat scheelt drie scriptbestanden op elke productpagina.
Filters: de stille kostenpost
Filteren op kleur, maat, merk en prijs is voor bezoekers prettig en voor uw server duur. Elke filtercombinatie is een unieke pagina die niet uit de cache komt en die de database dwingt om over meerdere tabellen te zoeken. Bij een shop met duizend producten en tien attributen loopt dat hard op.
Wat helpt:
- Kies een filterplugin die met een eigen index werkt in plaats van rechtstreeks door de standaardtabellen te ploegen. Het verschil in snelheid is bij grotere catalogi groot.
- Beperk het aantal filters. Vier of vijf goed gekozen filters worden gebruikt; twaalf filters worden genegeerd en kosten wel rekentijd bij het opbouwen.
- Laat filters via AJAX werken zodat alleen het productraster ververst wordt en niet de hele pagina.
- Zet aantallen achter filters uit als u een grote catalogus hebt. Het getal tussen haakjes achter elke kleur vraagt per optie een aparte telling.
Winkelwagen en afrekenen
Dit is het deel dat u niet kunt cachen en waar u het dus van de server moet hebben. Drie punten maken hier het verschil.
Zet de winkelwagenfragmenten uit waar ze niet nodig zijn. WooCommerce stuurt op elke pagina een apart verzoek naar de server om het aantal artikelen in de winkelwagen bij te werken. Op een homepage zonder winkelwagenknop is dat verspild werk, en op een drukke shop tikt het aan. Verschillende optimalisatieplugins bieden de mogelijkheid dit per pagina uit te schakelen.
Gebruik objectcache. Omdat paginacache hier niet werkt, is een objectcache met Redis de meest effectieve maatregel voor het ingelogde deel van uw shop. De antwoorden op terugkerende databasevragen blijven dan in het werkgeheugen staan. Hoe dat precies werkt staat in het artikel over objectcaching met Redis.
Sluit de juiste pagina’s uit van de paginacache. Winkelwagen, afrekenen en mijn account horen er nooit in. De meeste cacheplugins herkennen WooCommerce en regelen dit vanzelf, maar bij een zelfgebouwde opzet of een aangepaste afrekenpagina moet u het handmatig controleren. Doet u dat niet, dan ziet in het ergste geval de ene klant de bestelling van de andere.
De database en achtergrondtaken
Een webshop die twee jaar draait, heeft een database die aanzienlijk zwaarder is dan die van een gewone site. Vier plekken waar het zich ophoopt:
- Verlopen sessies. Elke bezoeker met een winkelwagen krijgt een sessie. WooCommerce ruimt die op, maar bij een shop met veel verkeer kan de tabel toch fors worden.
- De actieplanner. WooCommerce zet achtergrondtaken in een wachtrij. Afgeronde taken blijven standaard een maand staan; bij een drukke shop zijn dat honderdduizenden regels.
- Instellingen die altijd meegeladen worden. Sommige plugins zetten grote hoeveelheden gegevens in de optietabel met de vlag dat ze bij elk paginabezoek geladen moeten worden. Dat vertraagt letterlijk elk verzoek.
- Restanten van verwijderde plugins. Tabellen en instellingen die nooit zijn opgeruimd.
Overweeg daarnaast de nieuwe opslagwijze voor bestellingen van WooCommerce. Bestellingen staan dan in eigen tabellen in plaats van tussen de berichten, wat het beheer en het zoeken in bestellingen aanzienlijk versnelt bij grotere aantallen.
Een praktijkvoorbeeld
Een webshop in fietsonderdelen uit Amersfoort had ruim vierduizend producten en twaalf filters. De homepage laadde prima, maar de categoriepagina’s deden er zes tot acht seconden over en de afrekenpagina drie. Klanten haakten af, vooral op mobiel.
Wat we deden: producten per pagina van 48 naar 16, de filterplugin vervangen door een variant met eigen index, aantallen achter filters uit, de catalogusafbeeldingen teruggebracht en opnieuw gegenereerd, winkelwagenfragmenten uitgezet buiten de shoppagina’s, Redis aangezet en de actieplanner opgeschoond van bijna een half miljoen regels. Categoriepagina’s kwamen uit rond de twee seconden, de afrekenpagina onder de anderhalf. Er is niets aan het ontwerp veranderd.
Wat u zelf kunt en wat u beter uitbesteedt
Het aantal producten per pagina, de afbeeldingsformaten, het aantal filters en het opschonen van revisies kunt u zelf. Dat zijn instellingen, geen ingrepen. Doe het buiten piekuren en met een verse back-up.
Redis aanzetten, de opslagwijze voor bestellingen omzetten en de database opschonen zijn ingrepen waarbij bestellingen op het spel staan. Die horen thuis op een oefenomgeving, met een test van het complete bestelproces inclusief betaling voordat het live gaat. Loopt uw shop tegen de grenzen aan, dan is dat een goed moment om te kijken naar een gerichte snelheidsoptimalisatie waarbij de hele bestelflow wordt nagelopen.
Uw volgende stap
Meet vandaag drie pagina’s apart: uw homepage, uw drukste categoriepagina en een afrekenpagina met een product erin. Noteer de drie tijden. Zit het verschil vooral bij de categoriepagina, dan liggen uw filters en afbeeldingen voor de hand. Zit het bij afrekenen, dan is het de server en de database. Die vijf minuten meten voorkomen dat u een half jaar aan de verkeerde knop draait.
