De checklist noemt zes oorzaken en niet welke van jou is
Zoek “waarom is mijn website traag” en je krijgt overal dezelfde zes boosdoeners: te grote afbeeldingen, geen cachingplugin, trage hosting, te veel plugins, externe scripts en een opgeblazen thema. Geen van die stukken zet een volgorde neer, en geen ervan geeft je een manier om te bepalen welke van die zes bij jouw site speelt. Dus comprimeer je afbeeldingen, installeer je een cachingplugin, en voelt de site daarna precies zo traag als voorheen — want je hebt gefixt op goed geluk, niet op wat er bij jou daadwerkelijk misgaat.
Dit stuk geeft geen elfde trucje. Het geeft de volgorde die de checklist overslaat: eerst meten waar je bezoekers vastlopen, dan die oorzaak aanwijzen, en pas daarna ingrijpen. Zonder cijfers over eigen projecten — geen laadtijden, geen scores die ik ooit voor een klant terugbracht. Alleen de drempelwaarden en metingen die de bronnen hieronder officieel vastleggen.
“Traag” is drie klachten, en de checklist lost er meestal één op
“Traag” is geen enkel probleem maar drie losse klachten, en de gangbare checklist raakt er meestal maar één.
| Klacht | Metriek | Drempel |
|---|---|---|
| Het duurt lang voor je iets ziet | LCP, largest contentful paint — de tijd tot het grootste zichtbare element op het scherm staat | binnen 2,5 seconden |
| De site reageert niet als je klikt | INP, interaction to next paint — de tijd tussen je klik en het moment dat het beeld daarop reageert | 200 milliseconden of lager |
| De pagina schuift onder je vinger weg terwijl hij nog laadt | CLS, cumulative layout shift — de optelsom van onverwachte verspringingen | 0,1 of lager |
Dat wordt gemeten op het 75e percentiel van je paginaweergaven, apart voor mobiel en desktop. INP is pas sinds 2024 een officiële Core Web Vital en verving toen FID; wie nog een artikel uit 2022 volgt, optimaliseert voor een metriek die niet meer meetelt.
Afbeeldingen comprimeren en een cachingplugin installeren richten zich bijna allemaal op die eerste klacht, het zien. Voor de tweede en derde klacht doen ze weinig tot niets, en die blijven dus gewoon staan — ook nadat je de hele checklist hebt afgewerkt.
De score die je test is niet de score waarop je beoordeeld wordt
De Lighthouse-prestatiescore die je bij het testen ziet, is labdata: één gesimuleerde laadbeurt onder gecontroleerde omstandigheden. Die score is een gewogen gemiddelde van:
| Metriek | Weging |
|---|---|
| First Contentful Paint | 10% |
| Speed Index | 10% |
| LCP | 25% |
| Total Blocking Time | 30% |
| CLS | 25% |
INP zit daar niet in.
Search Console laat iets anders zien: velddata, metingen van echte Chrome-bezoekers uit de Chrome UX Report-dataset, verzameld over de laatste 28 dagen en gegroepeerd per set pagina’s met een vergelijkbare ervaring. Google’s eigen advies is helder: prioriteer op velddata waar die beschikbaar is, en gebruik labdata alleen om kansen te ontdekken.
Hier zit de kern van waarom je vastloopt.
Waarom je site in de test sneller is dan bij je bezoekers
Lab en veld lopen om meerdere concrete redenen uit elkaar. De test start altijd met een koude cache; je bezoekers meestal niet. De terug-knop levert bij een echte bezoeker vaak een bijna directe pagina op dankzij bfcache — de browser bewaart de vorige pagina compleet in geheugen zodat terug- en vooruitgaan geen nieuwe laadbeurt vergt — en dat simuleert geen test. Welk element geldt als het LCP-element verschilt bovendien per schermformaat, per personalisatie en per A/B-test die op dat moment loopt.
CLS wordt in het lab alleen boven de vouw gemeten, en alleen tijdens het laden. In het veld tellen alle onverwachte verschuivingen mee, over de hele levensduur van de pagina — dus ook die knop die verspringt nadat je al bent gaan scrollen. Dat is precies het “hij schuift onder mijn vinger weg”-gevoel dat in geen enkele test naar boven komt. INP is synthetisch simpelweg niet te meten, omdat een test niet weet wanneer en waarop een echte bezoeker klikt. En de labscore zelf schommelt van meting tot meting door omstandigheden buiten je site om; twee verschillende scores zijn dus geen bewijs dat je laatste aanpassing iets deed.
Zo vind je in twintig minuten welke oorzaak van jou is
- 1 Search Console begin bij het Core Web Vitals-rapport, en kijk welke URL-groep rood staat en welke van de drie metrieken die kleur veroorzaakt. Dat is de enige stap die je vertelt welk probleem je daadwerkelijk hebt, in plaats van welk probleem een generieke lijst je aanpraat.
- 2 Voorbeeld-URL pak vervolgens één voorbeeld-URL uit die rode groep, niet je homepage, tenzij die zelf in die groep zit.
- 3 PageSpeed Insights zet die URL in PageSpeed Insights, en lees dan eerst het veldblok bovenaan en pas daarna het labgedeelte eronder; dat is precies de omgekeerde volgorde van hoe de meeste mensen die tool gebruiken.
- 4 LCP splitsen als LCP de boosdoener blijkt, splits hem in vier stukken: TTFB (time to first byte, de tijd tot de eerste byte van de serverreactie binnenkomt), de wachttijd voordat het belangrijkste element wordt opgehaald, de tijd die het ophalen zelf duurt, en de vertraging voordat het element daadwerkelijk gerenderd wordt. De richtverhouding volgens web.dev is ongeveer 40% TTFB, minder dan 10% wachttijd, ongeveer 40% ophaaltijd en minder dan 10% rendervertraging. Het stuk dat daaruit springt wijst je oorzaak aan: trage hosting bij een hoge TTFB, een te laat opgehaalde afbeelding bij een lange wachttijd, of iets dat de weergave blokkeert bij een lange rendervertraging.
Pas na deze vier stappen pak je de checklist erbij, en dan alleen het punt dat bij jouw uitslag past.
Als het probleem niet het laden is maar het reageren
Wijst de meting niet naar het laden maar naar het reageren, dan speelt zich iets anders af. INP valt uiteen in drie fasen: input delay, de tijd vanaf je klik tot de code van de site begint te draaien; processing duration, de tijd die die eigen code nodig heeft; en presentation delay, de tijd tot het beeld daadwerkelijk verandert. Scriptevaluatie tijdens het laden — parsen, compileren, uitvoeren — legt lange taken op de main thread, waardoor de browser even niet kan reageren op een klik. Dat een pagina er staat, betekent dus niet dat hij klaar is met laden.
Afbeeldingen comprimeren en een cachingplugin installeren doen hier vrijwel niets. Externe scripts en de hoeveelheid JavaScript wel. Dit is precies de klacht die de standaardchecklist structureel mist, en de reden dat een site met een keurige score toch traag aanvoelt zodra iemand erop klikt.
Waarom je pas over vier weken ziet of het werkte
Het Core Web Vitals-rapport draait op een venster van 28 dagen, en als je “Start tracking” gebruikt na een aanpassing, begint er een nieuwe monitoringperiode van vier weken. Een fix van vandaag is dus morgen niet zichtbaar, hoe graag je ook wilt weten of hij hielp.
URL-groepen zonder genoeg meetdata vallen bovendien helemaal uit het rapport. Een pagina komt alleen in de dataset als hij publiek vindbaar is en voldoende bezoekers trekt, en die data komt alleen van Chrome-gebruikers die hun statistieken delen. Voor een kleinere site kan “geen data” dus gewoon “te weinig bezoekers” betekenen, niet “probleem opgelost”.
Over wat snelheid met je positie in Google doet, is de officiële lijn voorzichtig: Google gebruikt Core Web Vitals in de rankingsystemen, maar zegt zelf ook dat er geen enkel signaal is en dat goede scores geen toppositie garanderen — relevantie gaat voor. De “1 seconde vertraging is 7% minder conversie”-cijfers die elders in deze zoekresultaten rondgaan, laat ik bewust liggen; daar staat geen officiële bron onder.
Snelheid zit in wat de pagina is, niet in wat je er achteraf overheen legt
Als de diagnose eenmaal klaar is, wijst de uitkomst vaak naar iets dat je niet kunt wegcomprimeren: hoeveel er opgehaald moet worden voordat er iets te zien is, en hoeveel scripts er draaien voordat een klik ergens aankomt. Dat is geen instelling die je omzet, maar een bouwkeuze.
Ik heb dat zelf twee keer bewust als startpunt genomen in plaats van als reparatie achteraf. Voor een restaurant in Bergen op Zoom is de site bewust mobiel- en tabletgericht gebouwd, en op snelheid geoptimaliseerd voor bezoekers met een matige verbinding, omdat de gasten daar vandaan komen. Bij een parketbedrijf waarvan de site bewust zonder CMS is gebouwd verviel een hele laag scripts en database-aanroepen simpelweg door de keuze om ze niet toe te voegen.
Of jouw site, eenmaal gediagnosticeerd, gebaat is bij aanpassingen of bij een andere aanpak vanaf de bouwtekening, is een andere vraag dan waar dit artikel over gaat — die beantwoord ik apart. Hier stopt het bij de diagnose: weten wat er bij jou speelt, voordat er weer iemand een trucje op loslaat.
Wil je even meekijken waar jouw site vastloopt voordat je weer iets fixt dat net zo min helpt als de vorige tien? Neem contact op.