Website snelheid en conversie: een meting van twee bureausites

Website snelheid raakt je conversie op twee plekken: bezoekers haken af voordat je aanbod in beeld staat, en aanvragers haken af halverwege het formulier. Deloitte mat in 2020 dat 0,1 seconde snellere mobiele laadtijd op leadgeneratiesites 21,6 procent meer doorstroom naar de formulierpagina opleverde. Portent zag in 2022 dat een B2B-site die in 1 seconde laadt ongeveer drie keer beter converteert dan een site die er 5 seconden over doet.

Dat zijn cijfers van anderen. Hieronder staat een meting die wij zelf hebben gedaan, met de methode erbij zodat je hem kunt narekenen, en met de nuance die in de meeste snelheidsartikelen ontbreekt.

Wat snelheid volgens Google precies betekent

Google praat al jaren niet meer over laadtijd in seconden, maar over Core Web Vitals: drie metingen die de beleving van een echte bezoeker beschrijven. Ze worden vastgesteld op het 75e percentiel van je bezoekers, dus driekwart van je bezoeken moet binnen de norm vallen voordat een pagina slaagt.

De drie Core Web Vitals met de drempelwaarden van Google

Metriek	Wat het meet	Goed	Matig	Slecht
LCP	Hoe snel het grootste element in beeld staat, meestal je kop of hero-afbeelding	2,5 s of minder	2,5 tot 4 s	meer dan 4 s
INP	Hoe snel de pagina reageert op een klik, tik of toetsaanslag	200 ms of minder	200 tot 500 ms	meer dan 500 ms
CLS	Hoeveel de opmaak verspringt terwijl de pagina laadt	0,1 of minder	0,1 tot 0,25	meer dan 0,25

Google is in zijn eigen documentatie over paginabeleving opvallend nuchter. Daar staat dat Core Web Vitals door de rankingsystemen worden gebruikt, dat er meer bij een goede paginabeleving komt kijken dan die drie scores alleen, en dat goede scores in Search Console geen garantie zijn dat je pagina bovenaan komt. Met andere woorden: snelheid opent de deur, inhoud wint de zaak.

Wat het onderzoek zegt over snelheid en conversie

Er zijn drie onderzoeken die in dit vakgebied telkens terugkomen, en het is de moeite waard om ze precies te lezen in plaats van de samenvatting van de samenvatting over te nemen.

Deloitte, 2020. Deloitte Digital analyseerde met Google mobiele sessiedata van 37 merken uit retail, reizen, luxe en leadgeneratie, over een periode van vier weken. De uitkomst voor leadgeneratiesites, wat het dichtst bij een MKB-dienstverlener staat: bij 0,1 seconde snellere laadtijd daalde het bouncepercentage met 8,3 procent, steeg het aantal paginaweergaven met 7 procent en steeg de doorstroom naar de formulierpagina met 21,6 procent. In retail leverde diezelfde 0,1 seconde 8,4 procent meer conversie op.

Portent, 2022. Portent keek naar ruim 100 miljoen paginaweergaven over 20 sites, waarvan 14 zakelijke leadgeneratiesites, verspreid over meer dan 27.000 landingspagina's. Een site die in 1 seconde laadt converteerde ongeveer drie keer beter dan een site van 5 seconden, en ongeveer vijf keer beter dan een site van 10 seconden. De steilste winst zit tussen 1 en 4 seconden; daarna vlakt de curve af.

Think with Google. Het bekendste cijfer uit dit veld: 53 procent van de mobiele bezoekers verlaat een pagina die er langer dan 3 seconden over doet. Het is oud, het wordt eindeloos herhaald zonder bron, en het blijft bruikbaar als grove ondergrens.

En nu de nuance die je zelden leest in een artikel van een bureau. Dit zijn correlaties, geen bewijs van oorzaak en gevolg. Snelle sites zijn bijna altijd ook beter gebouwd, beter gehost, minder volgeladen met scripts van derden en overzichtelijker ingericht. Als een snelle site beter converteert, is snelheid daar deels een symptoom van vakmanschap en niet de enige oorzaak. Reken dus niet voor jezelf uit dat 200 kilobyte minder gewicht automatisch drie keer zoveel offerteaanvragen betekent. Wat je wel mag concluderen: traagheid kost je bezoekers voordat je boodschap een kans heeft gehad, en dat is een verlies dat je niet terugziet in je statistieken omdat die mensen nooit een pagina hebben bekeken.

Onze eigen meting: methode en verantwoording

Op 30 juli 2026 hebben wij twee Nederlandse sites naast elkaar gemeten. Site A is een handgebouwde statische site zonder bouwsysteem of plugins. Site B is de site van een Nederlands marketingbureau, gebouwd op een bekend CMS met een pagebuilder erbovenop. Wij noemen die partij niet bij naam: het gaat om het patroon, niet om de persoon, en het patroon vind je bij honderden vergelijkbare sites terug.

Belangrijk voor je oordeel: Site A is onze eigen site. Dat is een belang, en daarom staat de methode er hieronder volledig bij, met de zwakke plekken van onze kant erbij.

• Beide sites gemeten in dezelfde browser, vanaf dezelfde verbinding, binnen hetzelfde tijdvenster.
• Resourcegegevens opgehaald met de standaard resource-timing van de browser, dus zonder externe testdienst die zijn eigen weging toevoegt.
• Vier onafhankelijke metingen per site, op de homepage en op een dienstpagina.
• Gerapporteerd worden uitsluitend de structurele cijfers: aantal verzoeken, gedecodeerd gewicht, hoeveelheid JavaScript, aantal stylesheets, aantal externe hosts en het aantal knooppunten in de DOM.
• Niet als hoofdcijfer gerapporteerd: losse laadtijden. Bij Site B varieerde de eerste weergave over vier metingen van 352 milliseconden tot 3.576 milliseconden, afhankelijk van een volle of een lege cache. Eén cijfer daaruit plukken is geen meting maar een selectie.

De uitkomst in cijfers

Structurele meetwaarden van twee Nederlandse sites, gemeten op 30 juli 2026

Meetpunt	Site A · handgebouwd, statisch	Site B · CMS met pagebuilder	Verhouding
Verzoeken per pagina	12	106 tot 114	circa 9 keer meer
Totaal gewicht (gedecodeerd)	1.704 KB	3.407 tot 3.635 KB	circa 2 keer meer
JavaScript	106 KB in 2 bestanden	1.632 tot 1.768 KB in 26 tot 28 bestanden	circa 16 keer meer
Stylesheets	1	11 tot 15	circa 12 keer meer
HTML over de lijn (gecomprimeerd)	16.649 bytes	84.517 bytes	circa 5 keer meer
Knooppunten in de DOM	933	1.760 tot 1.962	circa 2 keer meer
Externe hosts	1	28	28 keer meer
Lettertypen	self-hosted	8 bestanden, samen 568 KB	niet vergelijkbaar
Layoutverschuiving (CLS)	0,002 bij 2 verschuivingen	0,017 tot 0,862 bij 1 tot 60 verschuivingen	zie hieronder
Reactietijd server (TTFB)	13 tot 28 ms via een edge-netwerk	27 tot 97 ms uit cache · 624 tot 2.056 ms bij een cachemisser	zie hieronder

Voor context: het HTTP Archive mat in juli 2025 een mediane mobiele pagina van 2.164 KB, waarvan 646 KB JavaScript. Site B zit daar ruim boven, Site A eronder. De middenmoot van het web is dus zelf ook zwaar; goed presteren betekent niet gemiddeld zijn.

Het opvallendste getal is niet het totale gewicht maar de verdeling ervan. Site B laadt ongeveer zestien keer zoveel JavaScript. JavaScript is de duurste soort gewicht die er is: een afbeelding kost bandbreedte, maar JavaScript kost bandbreedte plus ontleedtijd plus uitvoertijd, en die laatste twee vallen precies op het moment dat de bezoeker de pagina wil gebruiken. Dat is ook de reden waarom een zware site op een telefoon van drie jaar oud zoveel slechter voelt dan in de test op een laptop.

Waar dat gewicht vandaan komt

De pagebuilder-laag

Een pagebuilder bouwt elk blok op uit geneste wrappers, omdat hij van tevoren niet weet wat je er later in zet. Dat verklaart het verschil in DOM-knooppunten: 933 tegenover 1.760 tot 1.962 bij een vergelijkbaar lange pagina. Elk extra knooppunt kost geheugen, opmaakberekening en scrollprestaties. Voor de bezoeker is het onzichtbaar, tot hij op een goedkope telefoon gaat scrollen.

JavaScript dat je niet nodig hebt

Op Site B staat nog een klassieke JavaScript-bibliotheek uit het CMS-tijdperk: 87.553 bytes onbewerkt, 30.412 bytes gecomprimeerd. Ter vergelijking: de complete frontend-logica van Site A weegt 106.977 bytes onbewerkt en 30.372 bytes gecomprimeerd. De hele werking van de ene site past dus in de ruimte die de andere kwijt is aan één bibliotheek die er alleen staat omdat het thema en de plugins hem verwachten.

Scripts van derden

Site B laadt van 28 externe hosts: tagbeheer, twee analysepakketten, twee advertentiepixels, twee losse sessieopname-containers tegelijk, een cookiebanner, bezoekersherkenning, klikfraudebescherming en een captcha. Eén van die scripts laadde tijdens onze meting helemaal niet en gaf een blokkeerfout. Elke externe host kost een DNS-opzoeking, een verbinding en een TLS-onderhandeling voordat er ook maar één byte inhoud binnenkomt. Er zit ook een privacykant aan: hoe meer partijen meekijken, hoe meer je moet kunnen uitleggen in je cookieverklaring.

Lettertypen en afbeeldingen

Acht lettertypebestanden, samen 568 KB. Vier daarvan staan nog in het oude woff-formaat in plaats van woff2, en één gewicht wordt zowel als woff als als woff2 geladen: alleen die dubbeling kost circa 191 KB voor niets. Daarnaast wordt de afbeelding die het grootste element in beeld vormt niet vooraf geladen, terwijl juist dat het element is waar de LCP-meting op valt. Dat zijn geen exotische fouten, dat zijn de eerste drie punten van elke prestatiechecklist.

Layoutverschuiving: het lek dat je voelt maar niet meet

Van alle metingen is de layoutverschuiving de meest onderschatte, omdat bezoekers hem wel voelen en bijna nooit benoemen. Je kent het: je wilt op een knop tikken, de pagina schuift een stukje, en je tikt op iets anders.

Op Site B mat onze vier runs een CLS van 0,017 · 0,049 · 0,31 en 0,862, bij 1 tot 60 losse verschuivingen. Twee van de vier metingen zitten daarmee ver boven de grens van 0,25 waar Google de score als slecht bestempelt. De oorzaak is structureel: de HTML levert eerst één stylesheet, waarna JavaScript er nog 11 tot 15 bij injecteert, zodat de pagina zich na de eerste weergave herhaaldelijk opnieuw moet indelen. Site A mat in dezelfde omgeving 0,002 bij 2 verschuivingen.

Wij rapporteren hier bewust de hele reeks en niet alleen de 0,862. Een claim die op één uitschieter rust, ligt met één hermeting op straat. De reeks zelf is het punt: de instabiliteit is niet toevallig, hij is ingebakken in de manier waarop de pagina wordt opgebouwd.

Voor conversie is dit de meest directe schade van allemaal. Een offerteformulier dat verspringt terwijl iemand zijn telefoonnummer intypt, kost je die aanvraag. Niet met een foutmelding, maar met een gesloten tabblad.

Wat wij zelf nog niet goed doen

Een snelheidsartikel van een bureau dat alleen de fouten van anderen laat zien, is een reclamefolder. Dus hier staan de drie punten waarop onze eigen meting tegenviel.

• Beeldformaten. Onze mediamap bevat circa 652 KB aan png- en jpg-bestanden en nul webp. Op dat punt deed Site B het aantoonbaar beter, met het merendeel van de afbeeldingen al in een modern formaat.
• Lazy loading. Slechts 3 van de 7 afbeeldingen op onze homepage droegen bij de meting een lazy-attribuut, terwijl alles onder de vouw dat hoort te hebben.
• Externe host. Onze enige externe verbinding kwam van een lettertypedienst. Zelf hosten haalt dat laatste externe verzoek weg en maakt de rest van het verhaal pas waterdicht.

Die drie punten staan op onze eigen lijst en worden aangepakt. We vermelden ze omdat een meting die alleen in je eigen voordeel wordt gerapporteerd geen meting is.

Snelheid telt op de plek waar de aanvraag valt

Voor een webshop is conversie een aankoop. Voor een installateur, een aannemer of een adviseur is conversie een aanvraag, en die valt op één specifieke pagina met één specifiek formulier. Dat is de pagina die je moet meten, niet je homepage.

Vier dingen die op zo'n pagina het meeste opleveren, in volgorde van effect:

1. Laad het grootste element vooraf. De kop of de afbeelding waar de LCP-meting op valt, hoort in een preload-regel te staan. Dit is een aanpassing van één regel met een direct meetbaar effect.
2. Reserveer ruimte voor alles wat later inlaadt. Geef afbeeldingen een breedte en hoogte mee en laat geen banner of chatvenster boven het formulier verschijnen nadat de pagina al staat.
3. Haal derde partijen van het conversiepad. Een captcha of een chatwidget die eerst 200 KB moet ophalen voordat iemand kan verzenden, kost je aanvragen die je nooit registreert.
4. Vraag minder. Elk verplicht veld is een reden om te stoppen. Naam, telefoonnummer en de vraag zelf zijn genoeg om terug te bellen.

Hoe wij dit aanpakken staat op de pagina over website en CRM: de site wordt handgebouwd, zonder pagebuilder, en het formulier schrijft rechtstreeks door naar het systeem dat de opvolging doet. Wil je weten hoe jouw huidige site het doet, dan geeft de gratis AI-Groeicheck je binnen een minuut een eerste beeld.

Het grootste lek zit na de klik

Stel dat je alles hierboven doet en je aanvragen groeien met een kwart. Dan begint het echte werk pas, want de meeste MKB-bedrijven verliezen niet de meeste omzet op hun laadtijd maar op hun opvolgtijd. Een pagina die 400 milliseconden sneller is, wint van de concurrent. Een aanvraag die drie uur blijft liggen, verliest van de concurrent die binnen 5 minuten belde. In dat licht is een halve seconde winst op de pagina een rondingsfout.

Wij hebben daarom de volledige keten aan elkaar geknoopt: de site vangt de aanvraag, ons eigen CRM registreert hem meteen, en een mens belt binnen 5 minuten om te kwalificeren en een afspraak in te plannen. Hoe die keten in zijn geheel werkt staat op de pagina over de complete salesmachine.

Wat dat oplevert, in cijfers van één klant. Bij NIBA, een installatiebedrijf, leverde dit systeem 47 leads in 30 dagen op, 18 afspraken, 32 procent minder no-shows, 18.000 euro pipeline en 22 offerteaanvragen in 45 dagen. Dat zijn de cijfers van één traject in één branche en geen belofte voor het jouwe; de context staat bij de cases. Waarom die 5 minuten zo hard telt, staat uitgewerkt in waarom je binnen 5 minuten moet bellen.

Wat je deze maand kunt doen

Je hoeft je site niet opnieuw te laten bouwen om vooruitgang te boeken. Deze volgorde levert de meeste winst per uur werk.

Prioriteitenlijst van snelheidsmaatregelen met effect en benodigde moeite

Maatregel	Waar het op ingrijpt	Moeite	Waarom het conversie raakt
Meet je aanvraagpagina, niet je homepage	Prioritering	een uur	Je optimaliseert anders de pagina waar geen aanvraag valt
Scripts van derden opruimen	Verzoeken, JavaScript, INP	een dagdeel	Elke verwijderde tracker is een verbinding minder voor het formulier laadt
Grootste element vooraf laden	LCP	een regel code	De bezoeker ziet je aanbod voordat hij besluit weg te gaan
Afmetingen op alle afbeeldingen	CLS	een dagdeel	Het formulier verspringt niet meer tijdens het invullen
Afbeeldingen naar een modern formaat	Gewicht	een dagdeel	Zichtbaar sneller op 4G, waar het meeste mobiele verkeer zit
Lettertypen zelf hosten en beperken	Externe hosts, CLS	een dag	Geen tekst die halverwege van vorm verandert
Ongebruikte plugins en blokken weghalen	DOM, stylesheets	een dag	Minder opmaakberekening op goedkope telefoons

Meet daarna opnieuw, minstens drie keer en met een lege cache. Een site die alleen snel is zolang de cache warm is, is niet snel gebouwd maar geleend snel. Precies dat zagen wij bij Site B: 27 tot 97 milliseconden reactietijd uit cache, maar 624 tot 2.056 milliseconden zodra de cache leeg was. En de cache is leeg op precies het verkeerde moment: vlak nadat je een pagina hebt aangepast of een nieuwe landingspagina hebt gepubliceerd.

Veelgestelde vragen

Hoeveel conversie kost een trage website?

Dat verschilt per site, maar de richting is consistent. Portent mat in 2022 over ruim 27.000 landingspagina's dat een B2B-site die in 1 seconde laadt ongeveer drie keer beter converteert dan een site die er 5 seconden over doet. Deloitte zag in 2020 dat 0,1 seconde winst op leadgeneratiesites al 21,6 procent meer doorstroom naar de formulierpagina opleverde.

Wat is een goede laadtijd voor een zakelijke website?

Google hanteert geen laadtijd maar Core Web Vitals. Goed is een Largest Contentful Paint van 2,5 seconden of minder, een Interaction to Next Paint van 200 milliseconden of minder en een Cumulative Layout Shift van 0,1 of minder, gemeten op het 75e percentiel van je echte bezoekers. Voor een dienstverlener is dat een werkbare ondergrens, geen ambitie.

Is website snelheid een rankingfactor bij Google?

Ja, maar met een kanttekening. Google schrijft in zijn documentatie over paginabeleving dat Core Web Vitals door de rankingsystemen worden gebruikt, dat er meer bij komt kijken dan die drie scores alleen, en dat goede scores geen garantie zijn op een hoge positie. Snelheid is dus een randvoorwaarde en geen vervanging van relevante inhoud.

Waarom is mijn WordPress-site zo traag?

Meestal niet door het CMS zelf, maar door de lagen eromheen. In onze meting kwam het gewicht vooral uit een pagebuilder die extra wrappers genereert, uit legacy JavaScript dat mee moet, uit tientallen externe tracking- en marketingscripts en uit lettertypen die dubbel worden geladen. Dat is een keuzeprobleem in de opbouw, geen platformprobleem.

Hoe meet ik de snelheid van mijn eigen website betrouwbaar?

Meet minstens drie keer, met lege cache, op een gesimuleerde mobiele verbinding, en meet de pagina waar je aanvragen vandaan komen in plaats van je homepage. Stuur op structurele cijfers die per meting stabiel blijven: aantal verzoeken, totaal gewicht, hoeveelheid JavaScript en het aantal externe hosts. Losse laadtijden schommelen te sterk om een besluit op te bouwen.

Maakt snelheid nog uit als mijn opvolging niet op orde is?

Dan is snelheid je kleinste probleem. Een snelle pagina levert meer aanvragen op, maar een aanvraag die uren blijft liggen is nog steeds verloren. Zorg dus dat elke aanvraag automatisch in een CRM landt en binnen 5 minuten wordt opgevolgd, en optimaliseer daarna pas de laatste tienden van seconden op de pagina zelf.

Gebruikte bronnen

• web.dev · Web Vitals, drempelwaarden voor LCP, INP en CLS, geraadpleegd juli 2026.
• Google Search Central · Understanding page experience, over Core Web Vitals in de rankingsystemen, geraadpleegd juli 2026.
• Deloitte Digital · Milliseconds Make Millions, 2020, 37 merken uit retail, reizen, luxe en leadgeneratie.
• Portent · Site speed is (still) impacting your conversion rate, bijgewerkt 2022, 20 sites en ruim 27.000 landingspagina's.
• Think with Google · The need for mobile speed, over 53 procent afhakers boven 3 seconden op mobiel.
• HTTP Archive · Web Almanac 2025, hoofdstuk Page Weight, mediane mobiele pagina 2.164 KB waarvan 646 KB JavaScript, meting juli 2025.