Een site die op mobiel drie seconden nodig heeft om te laden, verliest circa 53% van de mobiele bezoekers voordat de productcontent zichtbaar is (op basis van gepubliceerde Google-data over mobiele afhaakdrempels).
Van de bezoekers die wél blijven, daalt de conversie per extra seconde laadtijd met circa 7%, een patroon dat terugkeert in meerdere commerce-onderzoeken (Akamai, Google, Portent). Voor een webshop met €10.000 per maand omzet betekent elke extra seconde €700 per maand aan gemiste inkomsten.
Geen enkel type website heeft zoveel te verliezen door slechte prestaties, en zoveel te winnen bij verbetering, als een ecommerce-winkel.
De cijfers achter snelheid
Het verband tussen paginasnelheid en omzet is uitvoerig onderzocht. De uitkomsten zijn consistent over sectoren en perioden heen:
| Onderzoek / Bron | Bevinding |
|---|---|
| Google / Deloitte (2019) | 0,1 seconde sneller → 8% hogere conversie op mobiel |
| Amazon (intern) | Elke 100ms vertraging = 1% omzetverlies |
| Walmart (intern) | 1 seconde sneller → 2% meer conversies |
| Portent (2019) | Sites die in 1 seconde laden, converteren 3× beter dan sites die 5 seconden nodig hebben |
Dit zijn geen uitschieters uit gunstige testomstandigheden. Ze komen uit grootschalige, real-world data over miljoenen transacties. De richting is altijd dezelfde: sneller is meer omzet.
Waarom mobiele ecommerce anders is
Meer dan 70% van het ecommerce-verkeer komt inmiddels van mobiele apparaten. Toch converteert mobiel op slechts circa 2%, tegenover circa 4% op desktop. Dat verschil, goed voor miljarden aan niet-gerealiseerde omzet in de sector, is grotendeels terug te voeren op snelheid en gebruiksgemak op mobiel.
Mobiele verbindingen zijn niet uniform. 4G-dekking is wisselend, zeker in landelijke gebieden. Budgetandroid-toestellen, die een aanzienlijk marktaandeel vormen, hebben tragere processors die moeite hebben met JavaScript-zware pagina's. Een productpagina die op een nieuwe iPhone in een stadscentrum acceptabel laadt, kan voor een groot deel van uw werkelijke klanten onbruikbaar zijn.
Het interactiemodel verschilt ook. Duimzone-navigatie, kleine taptargets en afrekenpagina's die voor desktop zijn ontworpen voegen wrijving toe. Wanneer die wrijving bovenop een trage laadtijd komt, loopt het uitvalpercentage snel op.
- 70%+ van het ecommerce-verkeer is mobiel, maar mobiel converteert op circa de helft van het desktoptempo
- 4G-verbindingen variëren sterk per locatie en toestelkwaliteit
- Budgettoestellen vertegenwoordigen een groot deel van de werkelijke gebruikers, geen randgevallen
- Afrekeningswrijving op mobiel versterkt zich wanneer de pagina traag reageert
Core Web Vitals en wat ze betekenen voor uw webshop
Google meet siteprestaties aan de hand van een set statistieken genaamd Core Web Vitals. Elke maatstaf correspondeert direct met iets wat uw klanten ervaren tijdens het winkelen:
| Maatstaf | Wat wordt gemeten | Ecommerce-relevantie | Goed | Verbetering nodig | Slecht |
|---|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Hoe lang duurt het voordat de hoofdinhoud zichtbaar is | Uw hero-productafbeelding of uitgelichte banner | Onder 2,5s | 2,5s tot 4s | Boven 4s |
| INP (Interaction to Next Paint) | Hoe snel de pagina reageert op klikken en tikken | Toevoegen aan winkelwagen, filterinstelling, aantalwijziging | Onder 200ms | 200ms tot 500ms | Boven 500ms |
| CLS (Cumulative Layout Shift) | Hoeveel de pagina verspringt tijdens het laden | Productlijsten die verschuiven terwijl afbeeldingen laden | Onder 0,1 | 0,1 tot 0,25 | Boven 0,25 |
Sites die op alle drie de Core Web Vitals groen scoren, ontvangen een rangschikkingsboost in de zoekresultaten van Google. Sites die zakken, worden naar beneden geduwd. Een trage webshop wordt daarmee dubbel bestraft: minder organische zichtbaarheid én een lagere conversie van het verkeer dat toch binnenkomt.
Een slechte INP-score is voor een ecommerce-site bijzonder schadelijk. Tikt een klant op "Toevoegen aan winkelwagen" en gebeurt er een halve seconde niets, dan tikken velen nogmaals of concluderen dat de site stuk is en vertrekken.
WooCommerce en het pluginprobleem
WooCommerce drijft een groot deel van de ecommerce-winkels, en is tegelijk een van de meest prestatiebeperkende platforms op schaal. Een functionerende WooCommerce-winkel draait doorgaans 50 tot 80 plugins. Elke plugin voegt HTTP-verzoeken, JavaScript-uitvoeringstijd en CSS-overhead toe.
Het resultaat op paginaniveau:
- Productpagina's verplaatsen bij eerste laden doorgaans 4 tot 8 MB aan data
- Een standaard WooCommerce-productpagina kan meer dan 100 databasequery's uitlokken
- JavaScript-bundels van meerdere plugins blokkeren vaak het renderen
- Scripts van derden (recensies, live chat, analytics) voegen extra aanvraagketens toe
- WooCommerce LCP op mobiel ligt in webvise-audits doorgaans tussen de 4 en 6 seconden; resultaten variëren per thema en pluginselectie.
Het bereik van 4 tot 6 seconden LCP valt ruim in de categorie "slecht" op de schaal van Google en ligt ruim voorbij de afhaakdrempel voor de meeste mobiele gebruikers. Cachingplugins verminderen het symptoom, maar veranderen niets aan de onderliggende architectuur die het probleem veroorzaakt.
Het databasequery-probleem is structureel. WooCommerce bouwt productpagina's dynamisch op bij elk verzoek: productdata, prijsregels, voorraadstatus, gerelateerde producten en winkelwageninhoud worden elke keer uit de database opgehaald. Met meer dan 100 query's per paginaoproep stuit zelfs snelle hosting op een plafond.
Hoe een prestatie-geoptimaliseerde ecommerce-stack eruitziet
Een headless commerce-architectuur scheidt de frontend, wat uw klanten zien en waarmee ze interacteren, van de commerce-backend die producten, voorraad en bestellingen beheert. De frontend is gebouwd in Next.js en vooraf gerenderd tijdens het bouwproces. De backend (Shopify, BigCommerce of WooCommerce headless) verwerkt transacties via een API.
Het prestatieverschil is structureel, niet cosmetisch:
- Statische/ISR-productpagina's: vooraf gerenderd tijdens het bouwproces en rechtstreeks geserveerd vanaf een CDN-edge, zonder PHP of databasequery's bij het laden
- Lazy-loaded productafbeeldingen: afbeeldingen buiten het scherm laden alleen wanneer nodig, in moderne formaten (WebP, AVIF) die 30 tot 50% kleiner zijn dan vergelijkbare JPEG's bij vergelijkbare kwaliteit (metingen van Cloudinary en Web.dev)
- Minimale JavaScript: geen jQuery, geen volledig Bootstrap, tree-shaken bundels die alleen de code meeleveren die elke pagina werkelijk nodig heeft
- Incremental Static Regeneration: productpagina's worden automatisch bijgewerkt wanneer voorraad of prijzen wijzigen, zonder volledig herbuilden
| Maatstaf | WooCommerce (typisch) | Next.js Headless (typisch) |
|---|---|---|
| LCP (mobiel) | 4-6 seconden | Onder 1,5 seconden |
| Time to Interactive | 6-10 seconden | Onder 2 seconden |
| Paginagewicht (productpagina) | 4-8 MB | Onder 500 KB |
| Lighthouse-score (mobiel) | 25-45 | 90-98 |
Deze bandbreedten zijn gebaseerd op typische resultaten uit webvise-audits; uitkomsten hangen af van thema, pluginset, afbeeldingsgewicht en scripts van derden.
De conversierekening voor uw webshop
Voer de berekening uit voor uw eigen winkel.
Het kader is eenvoudig:
- Neem uw huidige maandelijkse omzet
- Schat uw huidige conversieratio (bestellingen gedeeld door sessies)
- Pas de verwachte verbetering toe bij een snelheidsverhoging
- Bereken de resulterende omzetstijging
Illustratief scenario: een prestatie-rebuild die de conversie bij dezelfde hoeveelheid verkeer verhoogt van 1,5% naar 2,1% op een winkel met €15.000/maand omzet, levert bij een AOV van €100 circa €6.000/maand aan extra omzet op. Werkelijke uitkomsten zijn afhankelijk van de uitgangspositie.
Zelfs een conservatievere verbetering kan de kosten van de rebuild betekenisvol terugverdienen; de terugverdientijd hangt af van verkeersvolume en AOV.
De berekening werkt op elk omzetniveau. Een winkel met €5.000/maand die 0,5 procentpunt conversie wint, voegt €1.667/maand toe. Een winkel met €50.000/maand die hetzelfde wint, realiseert €16.667/maand extra.
Wat u het eerst moet meten
Stel uw nulmeting vast voordat u wijzigingen doorvoert. Vier tools dekken het terrein:
- Google PageSpeed Insights: voer de URL van uw productpagina in (niet alleen de homepage) en ontvang een score van 0 tot 100 op mobiel. Onder 50 is urgent. Onder 30 betekent dat klanten de site actief verlaten vanwege snelheid.
- Google Search Console → Core Web Vitals: toont real-user data van werkelijke bezoekers, geen labomstandigheden. Rode URL's hier zijn directe omzetverliezen.
- Lighthouse (Chrome DevTools): voer uit in incognitomodus op uw productpagina. Controleer het LCP-element: is het uw hoofdproductafbeelding? Is het gemarkeerd als lazy-loaded? Dat zou het niet moeten zijn.
- Netwerktabblad (Chrome DevTools): sorteer verzoeken op grootte. Let op grote ongecomprimeerde afbeeldingen, renderblokkeerende scripts en verzoeken van derden die de laadtijd verlengen.
Besteed extra aandacht aan uw LCP-element. Als uw hero-productafbeelding lazy-loaded is, wat gebruikelijk is bij op thema's gebaseerde WooCommerce-installaties, kan die ene aanpassing, het verwijderen van het lazy-load-attribuut van de eerste zichtbare afbeelding, de LCP direct met 1 tot 2 seconden verbeteren.
Snelle winsten vóór een volledige rebuild
Als een volledige rebuild niet onmiddellijk op de agenda staat, kunnen deze aanpassingen de prestaties binnen uw huidige setup verbeteren:
- Afbeeldingscompressie en WebP-conversie: productafbeeldingen omzetten naar WebP kan de afbeeldingspayload met 40 tot 60% verminderen. Tools zoals Imagify of ShortPixel doen dit automatisch.
- Verwijder ongebruikte plugins: voer een plugin-audit uit. Elke geïnstalleerde plugin, ook gedeactiveerde, voegt overhead toe. Verwijder alles wat niet actief nodig is.
- Schakel paginacaching in: WP Rocket of W3 Total Cache vermindert de kosten van dynamische paginageneratie. Dit lost de architectuur niet op, maar beperkt de impact bij terugkerende bezoeken.
- Upgrade uw hosting: gedeelde hosting legt een hard plafond op aan prestaties. Overstappen naar beheerde WordPress-hosting (Kinsta, WP Engine, Cloudways) levert doorgaans 10 tot 20 Lighthouse-punten op.
- Stel niet-kritieke JavaScript uit: de meeste thema's laden alle scripts op elke pagina. Het uitstellen van scripts die niet nodig zijn bij de eerste rendering, vermindert de renderblokkeringstijd.
Deze aanpassingen verlengen de houdbaarheidsdatum van een site en kunnen een score van 35 naar 55 brengen. Ze veranderen het structurele plafond niet. Een WooCommerce-winkel met volledige pluginstack, dynamische paginageneratie en gedeelde database zal op mobiel nooit de 85+ bereiken, hoeveel configuratiewerk er ook wordt gedaan.
Voor winkels met serieuze maandelijkse omzet zijn dit uitstelmaatregelen. De structurele oplossing, een headless rebuild, is wat het verschil blijvend maakt.
Wanneer een prestatie-rebuild financieel zinvol is
De vuistregel: doet uw winkel meer dan €5.000/maand en staat uw mobiele PageSpeed-score onder de 60, dan verdient een prestatie-rebuild zichzelf bij dit verkeersvolume doorgaans terug binnen 6 maanden; dit is een richtlijn, geen garantie.
Bij €10.000/maand en een typische conversieverbetering van 0,4 tot 0,6 procentpunt na de rebuild bedraagt de maandelijkse opbrengststijging €400 tot €600. Een rebuildkostprijs van €3.000 tot €5.000 is in 6 tot 10 maanden terugverdiend, nog zonder rekening te houden met verbetering in organische zoekposities dankzij betere Core Web Vitals-scores.
Winkels boven de €20.000/maand met slechte prestatiescores laten elke maand een betekenisvolle niet-gerealiseerde conversiekans liggen. De terugverdientijd is dan vaak minder dan 3 maanden.
Bekijk precies waar uw winkel staat via een gratis website-gezondheidsrapport op webvise.io/wp-health-report. Daarin worden uw Core Web Vitals geanalyseerd, uw zwaarst wegende prestatieproblemen geïdentificeerd en een helder beeld gegeven van wat een rebuild werkelijk zou veranderen. Geen aanmelding vereist.