Vraag nú je snelheidsoptimalisatie aan voor de zomer!
Vraag nú je snelheidsoptimalisatie aan voor de zomer!
“WooCommerce maakt je website traag.” De klant zei het met de overtuiging van iemand die er lang over heeft nagedacht en nu wil migreren naar Shopify.
Ik dacht: dit gaan we even uitzoeken.
Een week later stond zijn PageSpeed-score op mobiel op 73. Dat was 28 toen ik begon. De webshop had 200 producten en draaide gewoon op WooCommerce, voor en na de optimalisatie. Wat ik had aangepast: afbeeldingen geoptimaliseerd, caching correct ingesteld, cart-scripts uitgeschakeld op pagina’s die ze niet nodig hadden, en de database opgeschoond. WooCommerce zelf had ik niet aangeraakt.
De traagheid zit bijna nooit in WooCommerce zelf. Die zit in hoe de webshop is geconfigureerd. En dat onderscheid is alles, want als je het platform de schuld geeft, ga je op zoek naar de verkeerde oplossing.
WooCommerce heeft inderdaad meer functionaliteit dan een standaard WordPress-site. Producten, variaties, voorraadbeheer, betaalmodules, verzendopties. Dat kost rekenkracht. Maar de traagheid die klanten ervaren, komt zelden van die functionaliteit.
Ik heb webshops met 500 producten op een LCP van 1,4 seconden gebracht. Niet door minder producten, niet door een ander platform. Door de juiste instellingen.
Hoe? Dat leg ik hieronder uit.
Caching is bij een gewone WordPress-site een van de makkelijkste snelheidswinsten. Bij WooCommerce is er een belangrijk voorbehoud, en dit is precies het punt waar ik de meeste fouten zie.
De winkelwagen, de checkout en de Mijn account-pagina zijn dynamisch. Ze zijn voor elke bezoeker anders. Als je die pagina’s cacht, serveert bezoeker A de gevulde winkelwagen van bezoeker B. Een ingelogde klant ziet de checkout van iemand anders. Ik hoef niet te leggen waarom dat een probleem is.
WP Rocket en LiteSpeed Cache sluiten die drie pagina’s automatisch uit bij een WooCommerce-installatie. Maar “automatisch” betekent niet “altijd”. Controleer het na elke update van WooCommerce of je cachingplugin. Ik doe het elke keer. Elke keer.
Alle andere pagina’s, de homepage, categoriepagina’s en productpagina’s, kun je gewoon cachen. Doe dat.
Dit is een van de makkelijkst te fixen snelheidslekken in een WooCommerce-shop, en toch zie ik het op bijna elke site die ik analyseer.
WooCommerce laadt cart-fragmenten en checkout-scripts standaard op élke pagina van je site. Op de homepage. Op een blogartikel. Op de over-pagina. Dat zijn honderd kilobyte aan JavaScript die een bezoeker downloadt die gewoon je homepage bekijkt en geen enkele intentie heeft om iets te kopen op die pagina. Die scripts rijden gewoon mee, als een extra persoon in een taxi die nergens uitstapt.
WP Rocket heeft een instelling om cart-fragmenten via AJAX uit te schakelen. LiteSpeed Cache ook. Schakel het in. Op een gemiddelde pagina scheelt dat 0,5 tot 1 seconde laadtijd.
Test daarna wel even of de winkelwagenteller in je header nog werkt. Op sommige thema’s geeft dit een conflict.
Een webshop heeft veel afbeeldingen: productfoto’s van alle kanten, categorie-banners, sfeerbeelden, upsellafbeeldingen. En die komen bijna altijd rechtstreeks van een fotograaf of leverancier, ongeoptimaliseerd, te groot en in het verkeerde formaat.
Ik zag onlangs een webshop waarbij elke productpagina zes JPEG-foto’s had van elk 2 MB. Dat is 12 MB per productpagina. Voor één product. Dan kijk je niet verder naar de WP Rocket-instellingen, want je weet genoeg.
De aanpak: Imagify of ShortPixel installeren, WebP-conversie inschakelen, bulkoptimalisatie draaien. Hetzelfde als bij elke WordPress-site, maar urgenter hier omdat de aantallen groter zijn.
Eén aandachtspunt specifiek voor webshops: stel lazy loading in voor productafbeeldingen in galerijen, maar niet voor de hoofdproductafbeelding die boven de vouw staat. Die moet direct laden. De rest kan wachten.
WooCommerce slaat een indrukwekkende hoeveelheid data op: bestellingen, klantgegevens, sessiedata, transient data, revisies van productbeschrijvingen. Na een jaar actieve webshop kan de database honderden megabytes groot zijn, gevuld met data die je nooit meer gaat gebruiken maar die bij elke bezoeker gewoon meelaadt.
Een volle database is trager dan een opgeschoonde. Niet spectaculair trager, maar meetbaar trager. En bij WooCommerce zijn bijna alle pagina’s afhankelijk van databasequery’s.
Ik heb databases van 2 GB teruggebracht naar 180 MB. Dat is het gewicht van zes jaar opgestapelde data die dagelijks door elke paginabezoeker werd meegesleurd. Na opschoning was de laadtijdwinst direct meetbaar.
Gebruik WP-Optimize of Advanced DB Cleaner. Maak altijd een backup voor je begint. En plan het in als vast onderdeel van het maandelijkse onderhoud, zodat je het niet terugziet als een 2 GB-probleem over drie jaar.
Een WooCommerce-webshop op goedkope shared hosting is als een restaurant op een kampeergas-fornuis. Het werkt. Maar het is niet wat je wil als je 50 covers wil draaien op een zaterdagavond.
WooCommerce heeft meer serverrekenkracht nodig dan een gewone WordPress-site, en naarmate de webshop groeit, wordt dat verschil groter. Meer producten, meer bestellingen, meer bezoekers: elke stap in groei is een stap verder van wat goedkope shared hosting aankan.
Voor kleine tot middelgrote WooCommerce-webshops is Cloudways op DigitalOcean of Vultr de beste prijs-kwaliteitsverhouding. Kinsta en WP Engine zijn goede keuzes voor grotere shops of als er budget is voor betere support. Generieke shared hosting voor een actieve webshop vermijd je liever. Hoe je goede hosting kiest als webdesinger lees je in dit artikel.
Soms is de eerlijkste optimalisatie niet een plugin of een instelling, maar dit gesprek met je klant.
Wil je weten wat jouw WooCommerce-webshop vertraagt en een concreet actieplan krijgen? De Speed Boost Service is een done-for-you analyse inclusief implementatie. Ik heb elke maand 3 plekjes.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
