Waarom generieke sitesnelheid-tips uw WooCommerce-shop niet redden
Comprimeer uw afbeeldingen, installeer een cache-plugin, kies een licht thema. Dat advies staat overal en het klopt, maar het is ook precies het probleem. Het behandelt WooCommerce alsof het een standaard WordPress-site is, terwijl een webshop een heel andere belasting kent: productgalerijen, filters, reviews, voorraadstatussen, gerelateerde producten. Elk van die onderdelen draait op een plugin, en elke plugin voegt eigen JavaScript en CSS toe. Niet ergens verstopt, maar op elke productpagina, elke keer opnieuw.
Wie zijn PageSpeed-rapport opent en alleen naar afbeeldingsformaten en minificatie kijkt, mist waar de vertraging daadwerkelijk vandaan komt. Core Web Vitals zijn sinds juni 2021 een bevestigde rankingfactor van Google, als onderdeel van het Page Experience-signaal. Ze bepalen niet alles, maar geven bij vergelijkbare content de doorslag. Dat betekent dat een half opgeloste snelheidsklacht u alsnog achter concurrenten met dezelfde content laat eindigen.
De plugins die uw LCP stilletjes saboteren
In audits komen steeds dezelfde categorieën plugins terug als boosdoener voor een trage Largest Contentful Paint:
- Reviewplugins die op elke productpagina extern een script laden om sterrenbeoordelingen te tonen, ongeacht of er al reviews staan.
- Gerelateerde producten en upsell-widgets die bij het laden van de pagina eerst een query moeten draaien en dan pas hun eigen afbeeldingen en scripts inladen, wat de rest van de pagina ophoudt.
- Voorraad- en urgentiewidgets (“nog maar 3 op voorraad”) die met JavaScript renderen in plaats van server-side, waardoor de browser moet wachten voordat die tekst zichtbaar wordt.
- Currency switchers en wishlists die op elke pagina hun eigen stylesheet en script laden, ook als de bezoeker de functie nooit gebruikt.
Het patroon is steeds hetzelfde: de plugin is op zichzelf klein en onschuldig, maar hij wordt op elke productpagina geladen, ook wanneer hij niets zichtbaars toevoegt. Meerdere van dat soort plugins bij elkaar en uw LCP-element, meestal de hoofdafbeelding van het product, moet wachten tot alle render-blocking code is afgehandeld voordat de browser er ruimte voor maakt.
Een goede laadtijd (LCP) is 2,5 seconden of sneller. Tussen 2,5 en 4 seconden is voor verbetering vatbaar, boven de 4 seconden is slecht. Veel WooCommerce-shops zitten met een paar van deze plugins bij elkaar al ruim in het gele of rode gebied, zonder dat de eigenaar dat aan de buitenkant merkt: de site “voelt” niet traag omdat het beeld uiteindelijk wel verschijnt, maar Google meet het moment waarop dat gebeurt genadeloos exact.
Productafbeeldingen: niet het bestandsformaat, maar het gedrag
De standaardtip is: comprimeer uw afbeeldingen en gebruik moderne formaten. Terecht, maar onvolledig. Bij WooCommerce zit het echte CLS-probleem (Cumulative Layout Shift) vaak niet in de bestandsgrootte, maar in het gedrag van de galerij zelf.
Zoom- en lightbox-scripts op productafbeeldingen laden vaak een eigen stylesheet die pas na de hoofdpagina binnenkomt. Het gevolg: de afbeelding verschijnt eerst in de verkeerde afmeting en springt daarna naar zijn definitieve formaat zodra het zoom-script actief wordt. Datzelfde gebeurt bij variatiewissels: kiest een bezoeker een andere kleur of maat, dan wisselt de afbeelding vaak zonder vaste hoogte-breedteverhouding vooraf gedefinieerd te hebben, waardoor de rest van de pagina meeschuift. Voor een bezoeker die net op de knop “In winkelwagen” wilde klikken is dat een misser, en voor Google is het een directe CLS-boete.
Dit is precies het soort probleem dat generieke sitesnelheid-artikelen overslaan, omdat het niet in een compressietool op te lossen is. Het zit in de manier waarop de galerij-plugin en het thema samen de layout opbouwen, en dat vraagt om vaste dimensies vooraf, niet om een lichter plaatje.
Page builders en WooCommerce: een structureel conflict
Veelgebruikte page builders maken het bouwen van paginalayouts eenvoudig, maar WooCommerce heeft al zijn eigen templates voor productpagina’s, categoriepagina’s en de winkelwagen. Zet u daar een page builder overheen, dan laadt de pagina in feite twee lagen CSS en JavaScript: die van het thema en de WooCommerce-templates, plus die van de builder zelf. Dat conflict wordt in de meeste bronnen genoemd als vertragende factor, maar zelden concreet gemaakt: het gaat niet om “extra code”, het gaat om dubbele stylesheets die elkaar overschrijven en scripts die op elkaar wachten voordat de pagina interactief wordt.
Wie zijn shop op maat laat bouwen in plaats van op te stapelen met page builder plus tientallen plugins, voorkomt dat conflict aan de basis. Wij bouwen daarom eigen plugins voor vrijwel elke klantwens, van dropship-koppelingen met automatische voorraadsync tot maatwerk automatiseringen, precies om te voorkomen dat een shop met vijf generieke plugins moet werken die allemaal een stukje van dezelfde functionaliteit proberen te dekken.
Lab-data versus wat uw bezoekers echt meemaken
Een synthetische test (lab-data) meet uw site onder gecontroleerde omstandigheden: één locatie, één verbindingssnelheid, geen andere browsertabs. Real User Monitoring (RUM) meet wat uw daadwerkelijke bezoekers ervaren, met hun eigen telefoon, hun eigen verbinding, op een druk moment van de dag. Bij WooCommerce-shops zien we dat verschil scherper dan bij een gemiddelde contentsite, omdat het productaanbod en de laadlast per pagina sterk verschillen. Een categoriepagina met veel producten en bijbehorende galerij-thumbnails belast een mobiele verbinding heel anders dan de homepage die in de lab-test werd gemeten. Wie alleen op een lab-score stuurt, optimaliseert voor een scenario dat een fractie van de bezoekers meemaakt.
Waarom dit meer is dan een technisch detail
De meeste webshops onderschatten hoezeer laadsnelheid hun vindbaarheid bepaalt, en stoppen hun energie liever in content terwijl de technische basis rammelt. Content kan alleen ranken als de pagina snel genoeg laadt en Google die snelheid als onderdeel van de page experience meeweegt. Een productpagina met perfecte tekst maar een LCP van vijf seconden concurreert op achterstand met een pagina die inhoudelijk zwakker is maar wel binnen de norm laadt.
Het effect stopt niet bij Google. Pagina’s die in 1 seconde laden hebben ongeveer drie keer zo’n hoge conversie als pagina’s die er 5 seconden over doen. De winst zit vooral in de eerste paar seconden en vlakt daarna af. Met andere woorden: elke plugin die u schrapt en elke afbeelding die u van vaste dimensies voorziet, telt harder mee dan de volgende contentupdate. Wij beheren onze eigen dedicated servers, met maandelijkse migraties, juist omdat infrastructuur en pluginkeuzes samen bepalen of die eerste paar seconden voor of tegen u werken.
