Wat een trage website je aan omzet kost (en hoe je het meet)
Een halve seconde extra laadtijd kost meetbaar conversie en ranking. Zo meet je wat jouw site werkelijk doet bij bezoekers, wat de oorzaken zijn, en wat het oplevert om het te repareren.
Je website ziet er goed uit. Op jouw laptop, op kantoor, met glasvezel, opent hij direct. Dus is hij snel.
Alleen: jouw bezoeker zit in de trein met twee streepjes 4G, op een telefoon van drie jaar oud. Voor hem duurt het vier seconden voordat er iets zinnigs op het scherm staat. En een deel van die bezoekers is dan al weg — niet boos, gewoon weg, zonder dat je het ooit merkt.
Dit artikel gaat over hoe je meet wat er werkelijk gebeurt, wat het je kost, en wat je eraan doet.
Wat traagheid kost, in cijfers
Er circuleren veel losse cijfers over dit onderwerp, en niet allemaal even goed onderbouwd. Twee bevindingen zijn wél degelijk gemeten op grote schaal:
Portent analyseerde miljarden paginaweergaven en vond dat een webshop die binnen 2 seconden laadt gemiddeld 3,05 procent conversie haalt, tegenover 1,94 procent bij een laadtijd van 3 tot 4 seconden. Dat is ruwweg de helft meer omzet uit hetzelfde verkeer — puur door snelheid.
De BBC rapporteerde dat zij voor elke extra seconde laadtijd ongeveer 10 procent van hun bezoekers verloren.
Dat zijn geen wetten, maar ordes van grootte. Belangrijker is dat je de som voor jezelf maakt.
Stel je hebt 2.000 bezoekers per maand en 2 procent daarvan vraagt iets aan: 40 aanvragen. Zit je nu op 4 seconden en breng je dat terug naar onder de 2, dan is een verbetering van tientallen procenten in conversie realistisch. Ook een voorzichtige 20 procent betekent 8 extra aanvragen per maand — bijna honderd per jaar.
Wat is een klant je waard? Vermenigvuldig. Dát is het bedrag waar je een optimalisatieslag tegen afzet.
En dan is er nog Google. Laadsnelheid weegt mee in de ranking. Niet als hoofdfactor, maar wel als het verschil tussen twee inhoudelijk vergelijkbare pagina's — en dat verschil bepaalt of je op plek 4 of plek 9 staat.
Meet het goed, niet op je eigen laptop
Dit is waar bijna iedereen de fout in gaat. Je eigen ervaring is geen meting: jouw browser heeft de site in de cache, je zit op een snelle verbinding, en je apparaat is nieuwer dan dat van je gemiddelde bezoeker.
Er zijn twee soorten metingen, en je hebt ze allebei nodig.
Labdata: PageSpeed Insights
Ga naar pagespeed.web.dev, vul je URL in, en kijk alleen naar het mobiele tabblad. Daar zit je publiek.
Je krijgt een score van 0 tot 100. Maar die score is niet het punt — de onderliggende getallen zijn dat wel. Let op deze drie (de zogeheten Core Web Vitals):
| Meting | Wat het betekent | Goed |
|---|---|---|
| LCP | Hoe lang tot het grootste element (meestal je headerafbeelding of titel) zichtbaar is | onder 2,5 s |
| INP | Hoe snel de pagina reageert als je ergens op klikt | onder 200 ms |
| CLS | Hoeveel de pagina verspringt tijdens het laden | onder 0,1 |
Eén nuance die vaak wordt overgeslagen: Google beoordeelt deze waarden op het 75e percentiel van je bezoekers. Je hoeft dus niet iedereen binnen 2,5 seconde te bedienen, maar wel drie van de vier. Je gemiddelde zegt daarbij weinig — het zijn juist de trage staarten die je score bepalen.
LCP is doorgaans je grootste probleem, en die wordt in de praktijk bijna altijd veroorzaakt door één ding: te grote afbeeldingen.
Velddata: wat echte bezoekers meten
Labdata is een simulatie. Velddata is de werkelijkheid. Google verzamelt via Chrome de echte laadtijden van je bezoekers en toont die in Search Console onder "Core Web Vitals".
Dit is de meting die telt — en de enige die Google zelf gebruikt. Staat je site in de simulatie op 95 maar in het veld op rood, dan is het veld de waarheid.
De vijf oorzaken, in volgorde van hoe vaak ik ze tegenkom
1. Afbeeldingen die veel te groot zijn
Iemand heeft een foto van 4 MB rechtstreeks uit de camera geüpload, en de browser schaalt hem terug naar 800 pixels breed. Je bezoeker downloadt dan 4 MB om 200 kB te zien.
Wat het oplevert: dit is verreweg de goedkoopste winst die er is. Afbeeldingen comprimeren en in modern formaat (WebP of AVIF) aanbieden halveert vaak de totale paginagrootte. Een middag werk, direct meetbaar.
2. Te veel scripts van derden
Een cookiebanner, een chatwidget, twee analytics-pakketten, een heatmap-tool, een reviewwidget, een pixel van Facebook en een van LinkedIn. Elk daarvan haalt code op van een andere server, en elk daarvan kan traag zijn — buiten jouw controle.
Wat het oplevert: loop de lijst langs en vraag bij elk: gebruiken we dit werkelijk? In de praktijk kan er meestal de helft af. Wat overblijft, laad je pas ná de pagina zelf.
3. Een plug-in-stapel die opgestapeld is
Vooral bij WordPress. Elke plug-in laadt zijn eigen CSS en JavaScript op elke pagina, ook op pagina's waar hij niets doet. Twintig plug-ins betekent twintig keer overhead, op elk bezoek.
Wat het oplevert: snoeien helpt, maar er zit een bodem in. Op enig moment is dit een architectuurprobleem, geen optimalisatieprobleem.
4. Geen caching, of caching die niet werkt
Elke pagina wordt bij elk bezoek opnieuw opgebouwd — database bevraagd, HTML samengesteld, alles opnieuw. Terwijl de pagina voor 99 procent van je bezoekers identiek is.
Wat het oplevert: goede caching is vaak het verschil tussen 1,5 en 0,3 seconde serverresponstijd.
5. Trage hosting
De goedkoopste shared hosting deelt één server met honderden andere sites. Als de buurman een piek heeft, heb jij een trage site.
Wat het oplevert: een betere hostingpartij kost een paar euro per maand meer en is soms de hele oplossing. Maar controleer eerst de vier punten hierboven — hosting is vaak de schuldige die het niet is.
Waarom ik met Next.js bouw
Bij de meeste bouwmethoden is snelheid iets wat je achteraf moet repareren. Je bouwt een site, hij is traag, en dan ga je optimaliseren.
Bij een moderne aanpak is snelheid wat je krijgt als je niets bijzonders doet. Pagina's worden vooraf gegenereerd en als kant-en-klare HTML geserveerd — er hoeft bij een bezoek geen database geraadpleegd te worden en geen pagina samengesteld. Afbeeldingen worden automatisch in de juiste maat en het juiste formaat geleverd. Code die op een pagina niet nodig is, wordt er niet naartoe gestuurd.
Dat is geen magie, het is een andere volgorde: je optimaliseert niet achteraf, je begint met een fundament dat geen optimalisatie nodig heeft.
Wat je maandag kunt doen
Als je één ding doet uit dit hele artikel, doe dan dit:
- Ga naar
pagespeed.web.deven test je belangrijkste pagina op mobiel. - Kijk naar je LCP-tijd.
- Staat die boven de 2,5 seconde, klik dan door naar "Opportunities" en kijk of "Properly size images" of "Serve images in next-gen formats" erbij staat.
- Zo ja: daar zit je winst, en die is goedkoop te halen.
Dat kost je tien minuten en het vertelt je of je een probleem hebt dat geld kost.
Veelgestelde vragen
Is een PageSpeed-score van 100 het doel? Nee. De score is een gemiddelde van gewogen metingen en je kunt hem opjagen zonder dat je bezoeker er iets van merkt. Kijk naar LCP, INP en CLS, en vooral naar de velddata in Search Console. Een site met een score van 80 die in het veld overal groen scoort, is beter dan een site met 98 in de simulatie en rood in de praktijk.
Hoeveel sneller moet mijn site zijn? Onder de 2,5 seconde LCP op mobiel, gemeten in het veld. Dat is Google's grens tussen "goed" en "verbetering nodig", en het komt aardig overeen met het punt waarop bezoekers gaan afhaken.
Kost optimaliseren veel? Dat hangt af van de oorzaak. Afbeeldingen comprimeren en overbodige scripts weghalen is vaak een dagdeel werk met een direct meetbaar effect. Zit het probleem in de architectuur — een dichtgeslibde plug-in-stapel — dan repareer je symptomen en is opnieuw bouwen op enig moment goedkoper.
Merkt Google het als ik het repareer? Ja, maar niet direct. De velddata in Search Console loopt over een periode van 28 dagen, dus het duurt een maand voordat een verbetering volledig doorwerkt in wat Google ziet.
Geldt dit ook als ik weinig bezoekers heb? Juist dan. Bij 200 bezoekers per maand is elke bezoeker die afhaakt relatief duur. En traagheid weegt mee in je ranking, dus het houdt de bezoekers weg die je nog niet hebt.
De korte versie: test je belangrijkste pagina op mobiel via PageSpeed Insights, kijk naar je LCP, en controleer je Core Web Vitals in Search Console — dat is wat Google werkelijk meet. Staat het rood, dan zit de oorzaak in negen van de tien gevallen in te grote afbeeldingen of te veel scripts van derden, en dat is goedkoop te repareren. Zit het in de architectuur, dan is dat een gesprek over wat het je jaarlijks kost.
Wil je weten waar jouw site staat? Stuur me de URL — ik kijk ernaar en zeg eerlijk of er iets te halen valt.
