Je website snelheid verbeteren komt in de praktijk neer op drie meetwaarden: LCP, INP en CLS, samen de Core Web Vitals. Die bepalen niet alleen hoe snel een pagina voelt, maar ook hoe Google jouw site rangschikt en hoeveel bezoekers afhaken voordat ze iets gekocht of aangevraagd hebben. In deze gids leggen wij die drie waarden uit in gewone taal, laten we zien waarom snelheid direct geld kost of oplevert, en geven we een concrete checklist om het op te lossen. Voor het complete plaatje over een site die vanaf de basis snel is gebouwd, lees onze gids over een maatwerk website laten maken.
Wat zijn Core Web Vitals eigenlijk?
Core Web Vitals zijn drie meetwaarden waarmee Google de gebruikerservaring van een pagina probeert te vangen in cijfers. Niet “voelt het snel”, maar harde getallen die je kunt meten en verbeteren. Sinds 2021 zijn ze een officieel ranking-signaal, en sinds 2024 is INP de derde waarde in plaats van het oude FID. De drie zijn:
- LCP (Largest Contentful Paint): hoe lang duurt het tot het grootste element in beeld geladen is? Meestal je hero-afbeelding, een grote kop of een video-thumbnail. Dit is je gevoelsmatige laadtijd.
- INP (Interaction to Next Paint): hoe snel reageert de pagina als een bezoeker klikt, tikt of typt? Dit meet of je site “hangt” bij interactie.
- CLS (Cumulative Layout Shift): hoeveel springt de layout tijdens het laden? Denk aan een knop die wegspringt op het moment dat je erop wilt klikken, omdat er een advertentie of afbeelding inschuift.
De officiele definities en meetmethodes staan op web.dev van Google, de canonieke bron voor deze meetwaarden. Goed om te weten: Google meet deze vitals met echte bezoekersdata uit Chrome, niet met een lab-test. Je eigen snelle laptop op kantoorinternet vertelt je dus weinig over wat je bezoekers op mobiel ervaren.
Welke waarden zijn goed, en wanneer zit je in de rode zone?
Google deelt elke meetwaarde in drie zones in: goed, moet beter, en slecht. Je wilt op alle drie de vitals in de groene zone zitten, gemeten op het 75e percentiel van je bezoekers (dus drie van de vier bezoekers ervaren minimaal deze waarde). Hieronder de drempels die in 2026 gelden.
| Meetwaarde | Goed | Moet beter | Slecht (rode zone) |
|---|---|---|---|
| LCP (laadsnelheid grootste element) | onder 2,5 sec | 2,5 tot 4,0 sec | boven 4,0 sec |
| INP (reactie op interactie) | onder 200 ms | 200 tot 500 ms | boven 500 ms |
| CLS (visuele stabiliteit) | onder 0,1 | 0,1 tot 0,25 | boven 0,25 |
Een paar dingen vallen op als je dit voor het eerst ziet. LCP is een tijd in seconden en doorgaans het lastigst om groen te krijgen, zeker op een trage mobiele verbinding. INP wordt in milliseconden gemeten en is vooral een probleem op sites met veel JavaScript. CLS is geen tijd maar een verhoudingsgetal: 0 is perfect stabiel, alles boven 0,25 voelt als een springerige pagina. Voor de meeste MKB-sites zien wij LCP als de grootste uitdaging, simpelweg omdat de hero-afbeelding te zwaar is of de hosting te traag.
Waarom kost een trage website je geld?
Snelheid is geen technisch nice-to-have, het is een directe knop op je omzet. Dat klinkt als verkooppraat, maar het is meetbaar en al jarenlang door grote partijen onderbouwd. De logica is simpel: hoe langer een pagina laadt, hoe meer mensen wegklikken voordat ze ook maar iets gezien hebben. En wie wegklikt, koopt niets en vraagt niets aan.
De cijfers die telkens terugkomen in onderzoek van Google en grote retailers:
- Een laadtijd die oploopt van 1 naar 3 seconden verhoogt de kans dat iemand wegklikt fors. Van 1 naar 5 seconden meer dan verdubbelt die kans.
- Voor webshops vertaalt elke 100 milliseconden snelheidswinst zich in meetbaar hogere conversie. Bij serieuze omzetvolumes loopt dat snel in de duizenden euro’s per maand.
- Trage sites scoren lager in Google, wat minder organisch verkeer betekent. Minder verkeer plus lagere conversie is een dubbele klap.
Er is nog een tweede effect dat ondernemers vaak vergeten: snelheid raakt je hele website, niet alleen de homepage. Elke productpagina, elke landingspagina en elk formulier telt mee. Een trage checkout is dodelijker dan een trage homepage, want daar zit de bezoeker met zijn portemonnee al in de hand.
Wat maakt een website traag?
Voordat je iets gaat optimaliseren, moet je weten waar de vertraging vandaan komt. In de praktijk komen 90 procent van de trage sites door vier oorzaken, vaak in combinatie. Hieronder de boosdoeners op volgorde van hoe vaak wij ze tegenkomen bij MKB-sites.
| Oorzaak | Wat het doet | Hoe vaak wij dit zien |
|---|---|---|
| Te zware afbeeldingen | Ongecomprimeerde foto’s van meerdere MB vertragen LCP enorm | Bijna altijd |
| JavaScript-bloat | Te veel scripts, trackers en libraries blokkeren INP en rendering | Heel vaak |
| Trage of goedkope hosting | Server reageert langzaam, hoge time-to-first-byte | Vaak |
| Te veel plugins (WordPress) | Elke plugin laadt eigen CSS en JS, ook ongebruikt | Vaak (op WordPress) |
| Geen caching | Elke bezoeker krijgt een vers opgebouwde pagina | Regelmatig |
| Render-blocking resources | CSS en fonts die het tekenen van de pagina ophouden | Regelmatig |
De grootste enkele winst zit bijna altijd bij afbeeldingen. Een ongeoptimaliseerde hero-foto van 4 MB die als 400 KB had gekund, is direct twee tot drie seconden LCP-winst op mobiel. Daarna komt JavaScript: trackers, chat-widgets, A/B-test-scripts en zware paginabuilders stapelen op tot een berg die de browser eerst moet verwerken voordat de pagina reageert. Volgens de HTTP Archive Web Almanac is de hoeveelheid JavaScript die een gemiddelde pagina meestuurt al jaren stijgend, en dat is precies waar INP-problemen vandaan komen.
Hoe verbeter ik mijn website snelheid? De checklist
Hieronder de aanpak die wij in praktijk volgen, van quick wins naar diepere ingrepen. De eerste vier punten kun je vaak zelf, de rest vraagt meestal een developer. Werk van boven naar beneden, want de bovenste punten leveren de meeste winst per uur werk.
- Comprimeer en converteer je afbeeldingen. Zet alles om naar modern formaat (WebP of AVIF), schaal naar de werkelijke weergavegrootte, en lui-laad alles onder de vouw. Dit alleen al haalt vaak een hele seconde van je LCP af.
- Zet caching aan. Een caching-laag serveert bezoekers een kant-en-klare pagina in plaats van die elke keer opnieuw op te bouwen. Op WordPress doe je dit met een plugin, op een statische site is het standaard.
- Ruim je plugins en scripts op. Schrap elke plugin die je niet actief gebruikt. Verwijder dubbele trackers. Vraag je af of die chat-widget en die drie analytics-scripts echt op elke pagina nodig zijn.
- Gebruik een CDN. Een Content Delivery Network serveert je site vanaf een server dicht bij de bezoeker. Voor Nederlandse bezoekers scheelt dat tientallen milliseconden, voor internationaal verkeer veel meer.
- Verklein render-blocking CSS en fonts. Laad alleen de CSS die de pagina direct nodig heeft, en laad fonts met
font-display: swapzodat tekst meteen zichtbaar is. - Reserveer ruimte voor dynamische elementen. Geef afbeeldingen en advertenties vaste afmetingen mee, zodat de layout niet springt. Dit is de directe fix voor een slechte CLS.
- Overweeg een snellere architectuur. Als je site structureel traag blijft, ligt het vaak aan het fundament. Een statische of server-rendered aanpak is dan de echte oplossing, niet weer een plugin.
Punt 7 is waar veel sites uiteindelijk vastlopen. Je kunt een trage WordPress-site met plugins en caching een heel eind krijgen, maar er zit een plafond aan. Een site die op moderne technieken zoals Astro is gebouwd, stuurt standaard nauwelijks JavaScript mee en scoort vrijwel automatisch groen op alle drie de vitals. De afweging tussen die fundamenten staat in onze vergelijking van Astro, Next.js en WordPress.
Waarom is een statische website bijna altijd sneller?
Een traditionele WordPress-site bouwt elke pagina opnieuw op het moment dat een bezoeker hem opvraagt: hij vraagt data op uit de database, voert PHP uit, verzamelt de plugins en stelt de HTML samen. Dat kost tijd, zeker op gedeelde hosting. Een statische site doet dat werk eenmalig vooraf, bij het bouwen, en serveert daarna een kant-en-klaar HTML-bestand. De server hoeft alleen een bestand op te sturen.
Het verschil is groot. Bij een statische aanpak is de time-to-first-byte vaak onder de 200 milliseconden, stuurt de pagina minimaal JavaScript mee (wat INP laag houdt), en is de hosting goedkoper omdat er geen zware server nodig is. Dit is precies waarom wij voor de meeste marketing-sites en webshops met overzichtelijke catalogi standaard kiezen voor Astro. De keerzijde: voor sterk interactieve, ingelogde applicaties met realtime data is een statische aanpak niet de juiste keuze, en kies je een server-rendered framework. De afweging hangt af van hoe dynamisch je site echt is, niet van de hype rond een tool.
Voor het visuele ontwerp dat hierbovenop komt, werken wij samen vanuit een webdesign dat snelheid niet in de weg zit. Een mooie site die traag is, is geen mooie site.
Hoe meet ik mijn Core Web Vitals het beste?
Er zijn twee soorten metingen, en het verschil is belangrijk. Lab-data komt van een gesimuleerde test (zoals Lighthouse) en is handig om snel te diagnosticeren. Field-data, ook wel echte bezoekersdata, komt van werkelijke gebruikers en is waar Google daadwerkelijk op rankt. Stuur op de field-data, gebruik de lab-data om problemen op te sporen.
| Tool | Type data | Waarvoor het beste |
|---|---|---|
| PageSpeed Insights | Lab plus field | Snelle diagnose per pagina, gratis, concrete tips |
| Google Search Console | Field (echte data) | Overzicht van alle pagina’s, dit telt voor ranking |
| Chrome DevTools (Lighthouse) | Lab | Diep graven tijdens ontwikkeling |
| web-vitals library | Field | Continu meten in je eigen analytics |
Voor de meeste ondernemers is de combinatie van PageSpeed Insights voor losse pagina’s en Google Search Console voor het totaalplaatje genoeg. Search Console laat per URL-groep zien welke pagina’s groen, oranje of rood scoren op echte bezoekersdata, en dat is precies het signaal waar je ranking aan hangt. De officiele meet-richtlijnen en de bijbehorende uitleg vind je op Google Search Central.
Wat als mijn site na alle optimalisatie nog traag blijft?
Soms loop je tegen een plafond. Je hebt afbeeldingen gecomprimeerd, caching aanstaan, plugins opgeschoond, en toch blijft LCP op 3,5 seconden hangen. Dat is het moment om eerlijk naar het fundament te kijken in plaats van naar de tiende plugin. Drie veelvoorkomende oorzaken die niet met een quick fix op te lossen zijn:
- De hosting is structureel te traag. Goedkope shared hosting deelt een server met honderden andere sites. Een betere hostingomgeving of een statische deploy lost dit op, niet nog een caching-plugin.
- Het thema of de paginabuilder is te zwaar. Sommige WordPress-thema’s en builders sturen zoveel CSS en JavaScript mee dat geen optimalisatie ze groen krijgt. Hier helpt alleen een lichter fundament.
- De architectuur past niet bij het doel. Een content-site die als zware applicatie is gebouwd, of andersom. Dit is een herbouw-vraag, geen optimalisatie-vraag.
Op dat punt is doorpolijsten zonde van je tijd en geld. Vaak is een herbouw op een snelle basis goedkoper dan twee jaar lang aan een traag fundament blijven sleutelen. Let bij die afweging op de stille kosten van een goedkope basis, want die staan zelden in de eerste offerte. Die rekensom maken wij in onze gids over de verborgen kosten van goedkope websites.
Wat is de eerste stap?
Snelheid verbeteren hoeft geen maandenproject te zijn. Begin klein en meet je vooruitgang.
- Stap 1: meet je drie belangrijkste pagina’s. Homepage, je belangrijkste landingspagina en je checkout of contactformulier. Draai ze door PageSpeed Insights en noteer LCP, INP en CLS.
- Stap 2: pak de quick wins. Comprimeer de zwaarste afbeeldingen, zet caching aan en schrap ongebruikte plugins. Meet opnieuw en zie het verschil.
- Stap 3: beslis over het fundament. Als je na de quick wins nog rood of oranje staat, ligt het probleem dieper. Dan is het tijd voor een eerlijk gesprek over de architectuur.
Plan een gratis intake-gesprek als je wilt dat wij even meekijken naar jouw scores. Geen verkoopdruk, wel een onderbouwd advies over waar de grootste winst zit. Voor het complete kader over een site die vanaf de basis snel is, lees onze gids over een maatwerk website laten maken en bekijk wat wij bouwen op onze development-pagina.
