Een klant belde me laatst met een simpele vraag: haar nieuwe website zag er stukken mooier uit dan de oude, maar de omzet daalde. Na wat graafwerk bleek het antwoord niet in het design te zitten, maar in de statusbalk van de browser: 4,8 seconden laadtijd op mobiel. Dat voelt voor een bezoeker als een eeuwigheid, en Google denkt er hetzelfde over.
Het verschil tussen 1,9 en 4,8 seconden
Google gebruikt sinds de invoering van Core Web Vitals een concrete norm: de Largest Contentful Paint (het moment waarop het grootste zichtbare element laadt) hoort binnen 2,5 seconden te vallen. Alles daarboven wordt beoordeeld als ‘matig’ of ‘slecht’, en dat heeft direct invloed op je positie in de zoekresultaten. Maar het effect op conversie is minstens zo groot, en dat wordt vaak vergeten omdat het niet in een SEO-rapport staat.
Rekenvoorbeeld: wat trage hosting een webshop kost
Stel, een webshop trekt 1.000 unieke bezoekers per dag. Bij een laadtijd van 4,8 seconden meten we een conversieratio van 1,4%, wat in de praktijk een normaal cijfer is voor trage sites. Bij een gemiddelde orderwaarde van 68 euro levert dat op maandbasis dit op:
30.000 bezoekers × 1,4% = 420 orders × 68 euro = 28.560 euro omzet per maand.
Na een technische optimalisatieslag daalt de laadtijd naar 1,9 seconden. In vergelijkbare cases die ik heb begeleid, stijgt de conversieratio dan naar gemiddeld 2,3%. Met dezelfde bezoekersaantallen:
30.000 bezoekers × 2,3% = 690 orders × 68 euro = 46.920 euro omzet per maand.
Het verschil: 18.360 euro per maand, zonder dat er één euro extra aan advertenties is uitgegeven. Dit is geen uitzonderlijk voorbeeld; het is de meest onderschatte omzetlek die ik bij MKB-webshops tegenkom.
Waarom afbeeldingen comprimeren niet genoeg is
De meeste ondernemers pakken eerst de zichtbare oorzaak aan: grote afbeeldingen. Terecht, maar vaak niet voldoende. Het echte probleem zit meestal in de Time To First Byte (TTFB): de tijd tussen het opvragen van een pagina en het moment dat de server begint met antwoorden. Bij veel goedkope shared hostingpakketten staat een website op een server met 150 tot 300 andere sites, die allemaal om dezelfde CPU-cycli en databaseverbindingen vechten. Je afbeeldingen kunnen perfect geoptimaliseerd zijn, maar als de TTFB boven de 600 milliseconden zit, blijft de site traag aanvoelen.
Vijf technische knoppen die echt verschil maken
1. Meet de TTFB, niet alleen de totale laadtijd
Een TTFB onder de 200 milliseconden is het streefdoel. Alles daarboven wijst vrijwel altijd op een serverprobleem, niet op een frontendprobleem.
2. Zet object caching aan op serverniveau
Redis of Memcached zorgt dat veelgebruikte databasequery’s niet telkens opnieuw worden uitgevoerd. Bij WordPress-sites met veel plugins scheelt dit vaak 40 tot 60% in serverbelasting.
3. Gebruik OPcache voor PHP
Zonder OPcache compileert de server bij elke paginaweergave de PHP-code opnieuw. Met OPcache blijft de gecompileerde code in het geheugen staan, wat direct merkbaar is in de TTFB.
4. Converteer afbeeldingen naar WebP of AVIF
Dit levert gemiddeld 25 tot 35% kleinere bestanden op dan JPEG, zonder zichtbaar kwaliteitsverlies.
5. Leg statische content op een CDN
Een CDN haalt afbeeldingen en scripts dichter bij de bezoeker vandaan, wat vooral merkbaar is bij bezoekers buiten de Randstad of vanuit het buitenland.
Hoe je dit zelf checkt in tien minuten
Open PageSpeed Insights of GTmetrix en vul je URL in. Kijk niet alleen naar de score, maar specifiek naar twee cijfers: de TTFB en de LCP. Noteer beide waarden, voer één van bovenstaande vijf aanpassingen door, en meet opnieuw. Zo bouw je zelf een dossier op van wat daadwerkelijk verschil maakt op jouw site, in plaats van blind te vertrouwen op een algemene ‘snelheidsscore’.
De volgende keer dat iemand zegt dat de website ‘er goed uitziet’, vraag dan naar de TTFB. Dat cijfer vertelt meer over je omzet dan welk designoordeel dan ook.