Website-snelheid en Core Web Vitals 2026: hoe seconden uw verkoop beïnvloeden
Een gebruiker beslist binnen de eerste 2–3 seconden of hij op een site blijft. Elke extra seconde laadtijd is een deel van de bezoekers dat vertrekt zonder te wachten. Snelheid is geen "leuke bonus voor ontwikkelaars" — het is een directe hefboom op conversie en zoekrankings. We leggen de Core Web Vitals-metrieken in begrijpelijke taal uit en geven een checklist voor wat u ermee kunt doen.
Waarom snelheid geld is, geen esthetiek
Het patroon wordt bevestigd door onderzoek op grote platforms: hoe langer een pagina laadt, hoe kleiner de kans op een aankoop. De laadtijd van 1 naar 3 seconden verschuiven vergroot het aandeel mensen dat het tabblad sluit merkbaar; op mobiel is het effect nog sterker. De logica is eenvoudig: een trage site vermoeit mensen, wekt wantrouwen ("als hier alles hapert, komt mijn bestelling dan wel aan?") en drijft ze naar de concurrent die één klik verderop zit.
Een andere reden is de zoekmachine. Google telt Core Web Vitals officieel mee als een van de rankingsignalen. Bij verder gelijke omstandigheden staat een snellere site hoger. En zoals we schreven in het artikel over GEO-optimalisatie, komen trage pagina's ook slechter naar voren in de antwoorden van AI-zoekmachines.
De drie Core Web Vitals-metrieken in eenvoudige woorden
Core Web Vitals is een set indicatoren van Google die het werkelijke gevoel van een pagina beschrijven. In 2026 zijn er drie:
- LCP (Largest Contentful Paint) — hoe snel het belangrijkste verschijnt. De tijd die nodig is voordat het grootste element op het scherm (meestal de hoofdafbeelding of de kop) zichtbaar wordt. Goed — onder 2,5 seconden. Het beantwoordt de vraag "wanneer ziet de gebruiker dat de pagina geladen is".
- INP (Interaction to Next Paint) — hoe snel het reageert. Hoe snel de site op acties reageert: u drukt op een knop — hoe lang duurt het voordat er iets gebeurt. Goed — onder 200 milliseconden. In 2024 verving INP officieel de oude FID-metriek en meet het de responsiviteit nauwkeuriger.
- CLS (Cumulative Layout Shift) — stabiliteit van de lay-out. Hoeveel elementen "verspringen" tijdens het laden. Iedereen kent de ergernis: u mikt op een knop, en er springt een banner op die plek. Goed — een waarde onder 0,1.
U kunt uw eigen waarden gratis controleren in PageSpeed Insights of in het Core Web Vitals-rapport in Google Search Console — daar ziet u echte gegevens van live gebruikers, niet alleen een labtest.
Checklist om sneller te worden: wat het grootste effect geeft
- Afbeeldingen. De meest voorkomende oorzaak van een trage LCP. Moderne formaten (WebP/AVIF), de juiste maat voor het scherm, lazy loading van wat onder de vouw zit, en
width/heightzodat de lay-out niet verspringt. - Lettertypen. Lettertypen zelf hosten in plaats van via een derde partij,
font-display: swapen het preloaden van het belangrijkste gewicht — tekst verschijnt meteen, zonder "flikkeren". - Scripts. Minder zware JavaScript, uitgesteld laden van analytics en widgets, verwijderen van wat niemand gebruikt. Het is overladen JS die de INP het vaakst bederft.
- Caching en compressie. Gzip/Brotli, browsercaching van statische bestanden, een CDN waar nodig. Herhaalbezoeken worden direct.
- Hosting. Een trage serverreactie sleept al het andere mee omlaag. Soms is een site verhuizen de snelste manier om hem te versnellen: we schreven over die keuze in het artikel VPS versus shared hosting.
- Schone code in plaats van "maaidorsers". Een site op een zwaar buildersjabloon met een tiental plugins verliest het bijna altijd van een nette maatwerk-opmaak. Daarom bouwen we kant-en-klare websites met een snelheid van 90+ als standaard.
Een veelgemaakte fout: "we maken het later wel sneller"
Snelheid is het goedkoopst om aan het begin in te bouwen, in de architectuur. Zodra een site al is opgebouwd op een zwaar sjabloon met een tiental uitbreidingen, verandert elke optimalisatie in het bestrijden van de gevolgen en kost het meer dan de ontwikkeling zelf. Is uw site al traag — dan is dat geen doodvonnis: in de meeste gevallen is het realistisch om hem merkbaar te versnellen als onderdeel van ondersteuning, zonder een herbouw vanaf nul. Maar een nieuw project wordt eerlijker vanaf het begin snel gebouwd.
Conclusie
Core Web Vitals is geen gril van Google — het is een poging om te meten wat de klant toch al voelt: snel, responsief, geen verspringingen. Houd LCP onder 2,5 s, INP onder 200 ms en CLS onder 0,1 — en u krijgt meer aanvragen uit hetzelfde verkeer. Wilt u weten waar uw knelpunten zitten? Wij voeren een gratis snelheidsaudit uit en laten zien wat de grootste winst oplevert.