Een trage website blijft niet altijd lang wit in beeld. Soms zie je de pagina al, maar verschijnt de belangrijkste foto pas veel later. Je tikt op het menu en er gebeurt even niets. Of je wilt op een knop drukken, waarna de hele pagina verspringt omdat er bovenaan nog iets wordt geladen.
Core Web Vitals meten precies zulke momenten. Ze vertellen hoe snel de belangrijkste inhoud verschijnt, hoe vlot de pagina op een actie reageert en of onderdelen tijdens het laden op hun plaats blijven staan.
Die metingen zijn nuttig, maar 100/100 is geen bedrijfsdoel op zichzelf. Een bezoeker wil je aanbod zien, je menu openen en een formulier versturen. Dat moet vooral op een gewone telefoon goed gaan.
PageSpeed en Core Web Vitals zijn twee verschillende metingen
Veel ondernemers openen PageSpeed Insights, zien een cijfer van 0 tot 100 en noemen dat hun Core Web Vitals. In hetzelfde rapport staan echter twee soorten gegevens.
De PageSpeed-score van 0 tot 100 komt uit een afzonderlijke Lighthouse-test. Google voert die test uit onder nagebootste omstandigheden. Zo’n meting is handig om technische problemen te vinden. Een score van 90 tot 100 is groen. Van 50 tot en met 89 is de score oranje en volgens Lighthouse voor verbetering vatbaar. Alles onder 50 is rood.
Core Web Vitals gebruiken, wanneer die gegevens beschikbaar zijn, metingen van echte Chrome-gebruikers uit de afgelopen 28 dagen. Een nieuwe pagina of een website met weinig verkeer heeft soms te weinig metingen. PageSpeed toont dan gegevens op domeinniveau of meldt dat er geen gebruikersdata beschikbaar zijn.
Google legt het verschil tussen een laboratoriumtest en gebruikersdata uit in de documentatie van PageSpeed Insights. De laboratoriumtest helpt bij het opsporen van een probleem. De gebruikersdata laten zien wat bezoekers met verschillende telefoons en verbindingen in de praktijk hebben meegemaakt.
Vraag daarom niet alleen: “Wat is onze PageSpeed?” Vraag ook:
- is dit de mobiele of de desktoptest;
- gaat het om een losse test of gegevens van echte bezoekers;
- welke URL is gemeten;
- welk probleem merkt een bezoeker op die pagina;
- wat veranderde er na de aanpassing?
Drie Core Web Vitals, zonder technisch woordenboek
De afkortingen klinken ingewikkelder dan de problemen die ze beschrijven.
LCP: wanneer verschijnt de belangrijkste inhoud?
Largest Contentful Paint meet hoe lang het duurt voordat het grootste zichtbare onderdeel in beeld staat. Dat is vaak de grote foto of het belangrijkste tekstblok bovenaan de pagina.
Een LCP van maximaal 2,5 seconden geldt als goed. Boven 4 seconden valt de meting in de slechte categorie. Niet ieder bestand van de website hoeft binnen 2,5 seconden klaar te zijn. Het gaat om het moment waarop de bezoeker de belangrijkste inhoud waarschijnlijk kan zien.
INP: hoe snel reageert de pagina?
Interaction to Next Paint meet de reactie op een klik, tik of toetsaanslag. Denk aan een mobiel menu dat pas na een korte pauze opent, of een calculator die traag reageert wanneer je een optie kiest.
Een INP van maximaal 200 milliseconden geldt als goed. Boven 500 milliseconden is de score slecht.
CLS: blijft alles op zijn plaats?
Cumulative Layout Shift meet onverwachte verschuivingen. Je wilt bijvoorbeeld een knop aanraken, maar vlak daarvoor verschijnt er nog een afbeelding. De knop schuift omlaag en je tikt op iets anders.
Een CLS van maximaal 0,1 geldt als goed. Boven 0,25 is de score slecht.
Google beoordeelt deze waarden op het 75ste percentiel. Simpel gezegd: minstens drie van de vier bezoeken moeten binnen de goede grens vallen. De actuele grenzen voor LCP, INP en CLS staan in de officiële uitleg op web.dev.
Waardoor wordt een website traag?
In mijn ervaring ligt het zelden aan één regel code. Een site wordt meestal langzaam doordat er in de loop van de jaren steeds iets bijkomt.
De eerste bouwer installeert een thema en een pagebuilder. Een tweede voegt nieuwe blokken en plugins toe. Later komen er een chat, boekingssysteem, advertentiepixels en meerdere analysetools bij. Oude onderdelen blijven staan, omdat niemand meer zeker weet of ze nog worden gebruikt.
Zo ontstaat een Frankenstein-site. Ieder onderdeel had ooit een functie, maar niemand bewaakt nog wat de combinatie doet.
Dit zijn problemen die ik vaak tegenkom:
- foto’s en video’s die veel groter worden geladen dan nodig;
- pagina’s die uit verschillende thema’s, builders of blokkensets bestaan;
- oude stijlen en scripts die na een redesign zijn blijven staan;
- plugins zonder duidelijke taak;
- analysetools en advertentietags waarvan niemand de resultaten nog bekijkt;
- veel lettertypen en varianten van hetzelfde lettertype;
- video’s, kaarten, chats en boekingswidgets die direct bij het openen laden;
- nieuwe functies die zijn toegevoegd zonder de oude oplossing op te ruimen.
WordPress of een pagebuilder maakt een website niet automatisch langzaam. Het probleem begint wanneer een site jarenlang nieuwe lagen krijgt zonder dat iemand opruimt. Andersom kan ook een moderne website traag worden door een enorm achtergrondfilmpje en tien externe diensten.
PNG en JPEG zijn evenmin per definitie verkeerde bestandsformaten. Een foto van enkele megabytes is vooral een probleem als hij op een telefoon maar 400 pixels breed wordt getoond. WebP of AVIF kan het bestand vaak kleiner maken. Met verschillende beeldformaten voor verschillende schermen hoeft een telefoon ook geen desktopafbeelding te downloaden. Web.dev beschrijft die aanpak in de uitleg over responsive images.
Lettertypen en externe scripts verdienen dezelfde controle. Grote lettertypebestanden vertragen de weergave van tekst. Een chat, analysetool of advertentietag kan de pagina bezighouden terwijl de bezoeker al probeert te klikken. Google adviseert om de waarde van externe code regelmatig te controleren en ongebruikte code weg te halen. Zie hiervoor de uitleg over webfonts en externe scripts.
Praktijkvoorbeeld: een WordPress-site ging op mobiel van 43 naar 85
Bij een WordPress-project begon ik met een mobiele Lighthouse-score van 43. In de eerste meting verscheen het grootste zichtbare onderdeel na 9,6 seconden. De Total Blocking Time, de totale tijd waarin de pagina tijdens het laden nauwelijks kan reageren, was 620 milliseconden.
Na de optimalisatie kwam de mobiele score uit op 85. De eerste zichtbare inhoud verscheen na 1,5 in plaats van 3,3 seconden. LCP ging van 9,6 naar 3,2 seconden, Total Blocking Time van 620 naar 130 milliseconden en CLS van 0,059 naar 0,002. De pagina reageerde sneller en bleef tijdens het laden veel rustiger staan.
Voor de optimalisatie: mobiele Lighthouse-test met Performance 43. De websitepreview is onherkenbaar gemaakt.
Na de optimalisatie: mobiele Lighthouse-test met Performance 85. De websitepreview is onherkenbaar gemaakt.
De screenshots zijn op verschillende momenten gemaakt. Het is dus geen gecontroleerde proef onder identieke omstandigheden. Ze laten het verloop van dit project zien, niet wat ik bij iedere website kan beloven. Lighthouse-scores kunnen iets schommelen door de testomgeving en de gebruikte versie van Lighthouse.
Is 100 punten nodig?
Bij OROS gebruik ik 80 of hoger op mobiel en 90 of hoger op desktop als praktisch richtpunt. Het is geen officiële Google-norm en ook geen vaste garantie voor ieder project. Een mobiele score van 80 valt in Lighthouse nog steeds in de oranje categorie. Groen begint bij 90.
Toch kan 85 na een beginscore van 43 een goed moment zijn om te stoppen. De grootste vertragingen zijn dan opgelost en de website werkt merkbaar beter. De laatste punten kunnen bij een oude pagebuilder zoveel tijd kosten dat opnieuw bouwen de enige logische volgende stap wordt.
Een score van 100 is mogelijk. Vooral een compacte statische website zonder veel externe diensten kan dat halen. Lighthouse zegt zelf dat 100 bijzonder moeilijk is en niet van iedere website wordt verwacht. Na ongeveer 96 punten wordt het steeds lastiger om de score nog verder te verhogen. De documentatie over de Lighthouse-score legt uit hoe dat werkt.
Ik kijk daarom verder dan de gekleurde cirkel:
- Ziet een mobiele bezoeker het aanbod snel?
- Reageren het menu, de knoppen, formulieren en calculators zonder merkbare pauze?
- Blijft de pagina tijdens het lezen en tikken op zijn plaats?
- Blijft de website ook werkbaar nadat analytics, content en noodzakelijke functies zijn toegevoegd?
Wanneer kun je de bestaande website optimaliseren?
Een rode of oranje score is geen automatische reden voor een nieuwe website. Eerst moet duidelijk worden waar de vertraging vandaan komt.
Vaak kun je een bestaande site al flink verbeteren door afbeeldingen in het juiste formaat te laden, ongebruikte plugins en scripts te verwijderen en externe diensten opnieuw te beoordelen. Minder lettertypevarianten helpt ook. Hetzelfde geldt voor video’s die pas laden wanneer de bezoeker ze wil bekijken.
Een reparatie past goed als de structuur van de website nog klopt, medewerkers ermee kunnen werken en de grootste problemen aanwijsbaar zijn. Dan hoef je geen bruikbare website weg te gooien om een PageSpeed-cijfer op te poetsen.
Controleer na iedere ingreep wel of formulieren, boekingen, analytics en advertentiemetingen nog werken. Een hoge snelheidsscore is weinig waard als aanvragen nergens meer aankomen.
Wanneer is opnieuw bouwen verstandiger?
Een nieuwe bouw wordt interessant als meerdere mensen jarenlang aan dezelfde site hebben gewerkt, verschillende builders door elkaar lopen en iedere correctie een ander onderdeel beschadigt. Eindeloos schoonmaken kan dan meer kosten dan de inhoud gecontroleerd overzetten naar een nieuwe basis.
Voor websites met diensten, landingspagina’s en andere inhoud die niet dagelijks door de klant wordt aangepast, gebruik ik vaak Astro. Astro kan pagina’s vooraf als statische bestanden opbouwen. De browser van de bezoeker krijgt daardoor een eenvoudige basis, zonder dat voor iedere tekst of afbeelding een zware beheerlaag nodig is. Dit is de standaardwerkwijze die in de documentatie van Astro wordt beschreven.
Ook Astro is geen snelheidsknop. Een te groot filmpje, tien lettertypen en veel externe scripts maken iedere website traag. Een goed gebouwde WordPress-site kan juist prima presteren.
Een afzonderlijk Astro-project behaalde in een Lighthouse-test 95 op mobiel en 100 op desktop. De mobiele LCP was 2,4 seconden. Op desktop was dat 0,6 seconden.
Astro-project: mobiele Lighthouse-test met Performance 95. De websitepreview is onherkenbaar gemaakt.
Hetzelfde Astro-project: desktoptest met Performance 100. De URL en websitepreview zijn onherkenbaar gemaakt.
Deze screenshots laten zien dat een score van 95 of 100 haalbaar is. Ze zeggen niet dat iedere Astro-site die score krijgt. Op het desktopscherm staat ook No Data. Voor die URL waren onvoldoende gegevens van echte gebruikers beschikbaar. De 100 is dus een laboratoriumscore, geen bevestiging dat de Core Web Vitals in de praktijk zijn geslaagd.
Voor een besluit over repareren of opnieuw bouwen wil ik eerst weten:
- welke onderdelen de vertraging veroorzaken;
- welke inhoud en functies moeten blijven;
- of de klant zelf pagina’s moet kunnen aanpassen;
- of oude code en plugins veilig kunnen worden verwijderd;
- hoeveel onderhoud de bestaande opbouw blijft vragen;
- hoe formulieren, analytics en bestaande URL’s bij een verhuizing worden behouden.
Lees ook WordPress, websitebuilder of maatwerk: wat past bij jouw bedrijf? als je de technische basis van een nieuwe website vergelijkt.
Zo controleer je zelf of je website te traag is
Voor een eerste controle heb je geen technische kennis nodig.
Open de website op een gewone telefoon
Gebruik ook eens mobiel internet in plaats van je snelle wifi. Open de site in een privévenster, zodat de browser niet terugvalt op bestanden die eerder zijn opgeslagen.
Kijk wanneer het belangrijkste aanbod verschijnt. Open het menu, tik op de belangrijkste knop en vul een formulier in. Verspringt de pagina? Moet je wachten voordat een keuze wordt verwerkt? Dat zijn bruikbare signalen, ook zonder meetrapport.
Loop de route van een klant na
Test niet alleen de homepage. Bezoek de belangrijkste dienstenpagina, tarieven, contactpagina en het aanvraagformulier. Heb je een boeking, betaling of calculator, probeer die dan helemaal af te ronden op mobiel.
Test meerdere URL’s in PageSpeed Insights
PageSpeed test één URL per keer. Een lichte homepage zegt weinig over een dienstenpagina met video, een productoverzicht of een boekingsformulier.
Voer de mobiele en desktoptest afzonderlijk uit. Kijk eerst of PageSpeed gegevens van echte bezoekers toont. Lees daarna de laboratoriumscore en de lijst met problemen.
Trek geen conclusie uit één meting
Voer de test nog een keer uit en vergelijk resultaten onder dezelfde omstandigheden. Controleer na wijzigingen niet alleen het cijfer. Menu’s, formulieren, analytics en andere functies moeten nog steeds doen wat ze moeten doen.
Wat vraag je aan een ontwikkelaar?
Een ontwikkelaar moet een slecht rapport in gewone taal kunnen uitleggen. Deze vragen helpen:
- Waar wacht een bezoeker nu het langst op?
- Welke afbeeldingen, lettertypen of scripts zorgen voor de grootste vertraging?
- Welke externe diensten gebruikt het bedrijf nog echt?
- Kijken we naar gebruikersdata of naar een losse laboratoriumtest?
- Kunnen we de belangrijkste problemen oplossen zonder de site opnieuw te bouwen?
- Wat wordt verwijderd of aangepast, en welke functies testen we daarna opnieuw?
- Waarom wordt een nieuwe bouw geadviseerd?
- Hoe wordt de mobiele versie na de aanpassingen gecontroleerd?
“We installeren een snelheidsplugin” is geen volledige diagnose. De ontwikkelaar moet de oorzaak kennen, de risico’s van de wijziging uitleggen en aangeven wat binnen de bestaande website haalbaar is.
Helpt een snelle website bij Google?
Google gebruikt Core Web Vitals in zijn systemen voor de beoordeling van de pagina-ervaring. Goede scores garanderen geen hoge positie. Een snelle pagina met zwakke of niet-relevante inhoud blijft een zwakke pagina.
In de officiële documentatie over page experience zegt Google dat goede Core Web Vitals op zichzelf geen toppositie garanderen. De zoekmachine weegt meer signalen mee en probeert eerst het meest relevante antwoord te tonen.
Snelheid verbeteren is daarom geen truc voor direct meer SEO-verkeer. Het hoort bij goed onderhoud. Een bezoeker moet de informatie snel kunnen zien en zonder gedoe de volgende stap kunnen zetten.
Eerst onderzoeken, daarna pas opnieuw bouwen
Een trage website hoeft niet meteen vervangen te worden. Begin met de mobiele versie, de belangrijkste pagina’s, afbeeldingen, externe scripts en de beperkingen van het huidige systeem.
Beschrijf je website en het probleem in het aanvraagformulier. Ik kijk wat er binnen de bestaande site te verbeteren is en wanneer opnieuw bouwen wel verstandig wordt. Plan je een nieuw project, lees dan ook wat een website in Nederland in 2026 kost of gebruik de websitecalculator voor een eerste prijsindicatie.
De auteur
Daniel Orosz
Daniel bouwt websites en digitale systemen vanuit Kerkrade. Hij werkt al meer dan 16 jaar met webtechniek en vertaalt complexe keuzes naar gewone taal.
Meer over Daniel →
