Hoe snel moet mijn website laden?

Snelheid wordt vaak verkocht als een SEO-onderwerp. Dat klopt maar half. Google gebruikt drie meetwaarden, de Core Web Vitals, en die tellen mee in de rangschikking. Ze wegen alleen licht: tussen twee gelijkwaardige pagina’s kan het schelen, tegen een inhoudelijk sterkere concurrent niet. Waar snelheid wel hard doorwerkt, is in gedrag. Wie op een telefoon in de trein staat te wachten, gaat terug naar de zoekresultaten. Dat kost je aanvragen, en dat zie je terug in je eigen cijfers.

De drie getallen die Google meet, in gewone woorden

De namen zijn afkortingen, de betekenis is simpel. Alle drie beschrijven ze iets wat een bezoeker echt merkt.

• LCP, Largest Contentful Paint: hoe lang het duurt voordat het grootste element in beeld staat, meestal je koptekst of hoofdafbeelding. Streef onder 2,5 seconden.
• INP, Interaction to Next Paint: hoe snel de pagina zichtbaar reageert nadat iemand klikt of tikt. Streef onder 200 milliseconden. INP verving in maart 2024 de oudere maat FID.
• CLS, Cumulative Layout Shift: hoeveel de pagina verspringt tijdens het laden, bijvoorbeeld doordat een afbeelding zonder opgegeven afmetingen later inschuift. Streef onder 0,1.

CLS is de goedkoopste om op te lossen en wordt het vaakst genegeerd. Afmetingen meegeven aan afbeeldingen en ruimte reserveren voor een cookiebanner kost een uur en haalt de meeste verspringingen weg.

Waarom een score van honderd niet je doel is

PageSpeed Insights geeft bovenaan een cijfer. Dat cijfer komt uit een labtest: een gesimuleerde telefoon op een gesimuleerde verbinding, een keer. Voor de rangschikking gebruikt Google geen labtest maar veldgegevens van echte bezoeken, en dan het 75e percentiel over 28 dagen. Vrij vertaald: driekwart van je bezoekers moet onder de drempel blijven, ook die ene met een oude Android op 4G.

Daarom is jagen op honderd punten zonde van je geld. We zien sites met een score van 95 die in het veld een LCP van 4 seconden halen, en sites met 62 die ruim binnen de drempels blijven. Kijk in Search Console naar het rapport over Core Web Vitals of naar je eigen veldmeting, niet naar het gekleurde bolletje van een losse test.

Wat snelheid oplevert, met een rekensom

Stel: 8.000 bezoekers per maand, waarvan 2 procent het contactformulier invult. Dat zijn 160 aanvragen. Verschuift dat naar 2,2 procent omdat de pagina anderhalve seconde eerder bruikbaar is, dan komen er 16 aanvragen per maand bij. Bij een gemiddelde opdracht van 500 euro en een score van een op vijf is dat 1.600 euro per maand. Wij beloven die verschuiving niet, maar dit is wel de som die je zelf moet maken voordat je aan een snelheidstraject begint.

De omgekeerde som is net zo nuttig. Kost een optimalisatietraject 2.000 euro en verdien je gemiddeld 100 euro per aanvraag, dan heb je 20 extra aanvragen nodig om quitte te spelen. Op een site met 300 bezoekers per maand ga je die niet halen. Dan is wat er op je homepage staat een stuk belangrijker dan een halve seconde laadtijd.

Waar de winst meestal zit

In bijna elk project dat wij openmaken, zit de traagheid op drie plekken: te grote afbeeldingen, scripts van derden en plugins die overal meeladen. Een foto van 3.000 pixels breed die op 600 pixels wordt getoond, is zo 1,5 megabyte verspilling. Een chatwidget, een cookiebanner en drie trackers samen kosten al snel een seconde voordat je eigen code aan de beurt is.

Verouderde plugins zijn dubbel vervelend: ze remmen en ze zijn de meest voorkomende reden waarom een WordPress-site gehackt wordt. Het platform zelf is zelden de boosdoener. Of je nu WordPress, Wix of maatwerk kiest, met 4 megabyte aan beeld op de homepage is elke site traag. Bij een webshop telt dat dubbel, want daar staat de laadtijd tussen de bezoeker en de kassa; zie ook wat een webshop kost en wat erin zit. Snelheidsbewaking zit standaard in de websites die wij ontwikkelen en beheren, omdat een site die niemand bijhoudt vanzelf weer trager wordt.

Zo doen wij dit

We meten eerst het veld, niet het lab. Search Console laat zien wat echte bezoekers meemaken, opgesplitst naar mobiel en desktop en naar groepen pagina’s. Pas daarna draaien we een labtest, om te zien waar de tijd blijft. Die volgorde scheelt werk: het lost geen enkel probleem op als je een pagina optimaliseert die vier bezoekers per maand krijgt.

Daarna werken we een vaste volgorde af. Beeld eerst, want daar zit meestal de helft van de winst: goede afmetingen, moderne formaten, afmetingen in de HTML zodat er niets verspringt. Dan de scripts van derden, waarbij we per script vragen wat het oplevert. Dan de plugins en het thema. De hosting komt als laatste, omdat een snellere server er in ons werk zo’n 100 tot 300 milliseconden afhaalt en niet meer.

Wat we rapporteren spreken we per klant af, meestal met dezelfde meting, zodat je verbetering ziet in seconden en niet in een cijfer. Zit snelheidswerk niet in je pakket, dan is het meerwerk en hoor je vooraf hoeveel uur we denken nodig te hebben.

De fout die we het vaakst zien

Een cachingplugin installeren en denken dat het klaar is. Caching bewaart een kant-en-klare versie van de pagina en helpt echt voor je LCP, maar doet niets voor INP. Die meet hoe snel de pagina reageert op een klik, en dat wordt bepaald door JavaScript dat toch draait. We zien sites met drie cachingplugins naast elkaar die elkaar in de weg zitten en samen trager zijn dan zonder.

Bronnen

• web.dev, documentatie over Core Web Vitals (LCP, INP en CLS)
• Google Search Central, documentatie over de page experience-signalen en het Core Web Vitals-rapport
• Eigen praktijkcijfers aiplusmarketing, augustus 2026

Hier helpen we mee: Website ontwikkelen