Drie screenshots, dezelfde URL, drie verschillende cijfers. PageSpeed Insights mobiel: 31, met een LCP van 5,2 seconde in het rood. GTmetrix: Grade C, Performance 68. En de Lighthouse-run in Chrome DevTools op een snelle laptop: 94.
Alle drie hebben gelijk. Ze beantwoorden alleen een andere vraag. PageSpeed vertelt wat Google ziet bij je echte bezoekers. GTmetrix laat zien wat er technisch misgaat op een specifieke locatie met een specifiek throttling-profiel. En die 94 uit DevTools is een meting op een machine zonder netwerklatency en zonder de retargeting-pixel die marketing er vorige week in heeft gezet.
Wie dat onderscheid niet kent, gaat optimaliseren op het verkeerde getal. Dus: welke meting zegt wat, en wanneer is een score echt slecht?
Labdata en velddata: het onderscheid dat alles verklaart
Elke snelheidstool valt in één van twee categorieën, en sommige doen beide.
Labdata is een synthtische meting: één browser, één server, één profiel, reproduceerbaar. Nadeel: het zegt niets over je bezoekers. Labdata is er om oorzaken te vinden — welke request blokkeert de render, welke third-party kost 800 milliseconden.
Velddata komt van echte gebruikers met echte telefoons op echte 4G-verbindingen. Google verzamelt dit in de Chrome User Experience Report (CrUX) en publiceert het per maand, per URL en per origin. Dit is de data die Google daadwerkelijk gebruikt voor Core Web Vitals.
De verdeling is simpel: Lighthouse is puur lab. GTmetrix is puur lab. PageSpeed Insights is de enige van de drie die beide toont — velddata bovenaan, labmeting eronder.
Waarom het 75e percentiel je enige eerlijke cijfer is
Google rapporteert velddata op het 75e percentiel. Dat betekent: 25% van je bezoeken was slechter dan dat getal. Niet het gemiddelde, niet de beste run. Als je LCP op het 75e percentiel 3,8 seconde is, dan wacht een kwart van je bezoekers bijna vier seconden op je grootste beeld.
Dat is de reden dat een sprint waarin je de labscore van 62 naar 91 tilt soms niets doet voor je ranking: de vertraging zat bij een kwart van je gebruikers op een oudere telefoon met een slechte verbinding, en die groep raak je niet met een geoptimaliseerd hero-image alleen.
Wat throttling met je score doet
Lighthouse mobiel simuleert ongeveer 1,6 Mbps down, 750 kbps up, 150 ms latency en 4x CPU-vertraging. GTmetrix gebruikt presets die daarop lijken maar niet identiek zijn, en standaard staat vaak een desktopprofiel met lichtere throttling.
Zet je GTmetrix op desktop zonder throttling en vergelijk je dat met PageSpeed mobiel, dan vergelijk je een racefiets met een bakfiets. Zelfde bestuurder, ander verhaal.
GTmetrix: de debugger van de drie
GTmetrix draait intern op de Lighthouse-engine, maar plakt er een eigen laag bovenop. Je krijgt een Grade (A–F) die is opgebouwd uit twee delen: een Performance-score en een Structure-score. Die laatste kijkt naar technische hygiëne — compressie, caching-headers, HTTPS, render-blocking resources.
Het echte werk zit in de waterfall. Je ziet elke request met timing, grootte en initiator, gegroepeerd per domein. Bij een trage pagina zie je binnen dertig seconden of het probleem bij je eigen server zit, bij een script van een marketingtool, of bij het laden van een font van een extern CDN.
Waar GTmetrix sterker is dan de rest
- Testlocatie kiezen. Een server in Frankfurt of Londen geeft een reëler beeld voor Nederlandse bezoekers dan de standaard Amerikaanse locatie.
- Herhaalde runs met gemiddelde. Eén meting is ruis; GTmetrix kan drie runs doen en middelen.
- Filmstrip en video. Je ziet visueel wanneer het eerste beeld verschijnt en wanneer de pagina eindelijk stilvalt. Dat overtuigt stakeholders sneller dan een tabel.
- Rapporten vergelijken. Voor en na een fix naast elkaar, met dezelfde instellingen.
Waar GTmetrix je misleidt
De Grade voelt objectiever dan hij is. Een B kan het gevolg zijn van één ontbrekende cache-header op een klein bestand, terwijl je LCP allang in orde is. En omdat GTmetrix geen velddata heeft, kun je een prachtige A hebben terwijl je CrUX-data rood is — bijvoorbeeld omdat een kwart van je verkeer uit een regio komt waar je CDN niet dekt.
Gebruik GTmetrix dus als antwoord op "waarom is het traag", niet op "ben ik snel genoeg".
PageSpeed Insights: het oordeel van Google, met context
PageSpeed Insights is de enige tool in dit rijtje die laat zien wat Google zelf meet. Bovenaan staat de velddata uit CrUX, met de kerncijfers LCP, INP en CLS en een oordeel per metric. Daaronder een Lighthouse-run met de bekende 0–100 score en een lijst met verbeterkansen.
Twee dingen om in het oog te houden. Ten eerste: CrUX is alleen beschikbaar als een URL of origin genoeg verkeer heeft. Bij een nieuwe site of een pagina met weinig bezoekers zie je alleen labdata — en dan is de verleiding groot om die labscore te behandelen als het eindoordeel.
Ten tweede: de lijst met "kansen" is geen prioriteitenlijst. Een suggestie als "defer offscreen images" kan een halve seconde opleveren maar je score nauwelijks raken, terwijl een niet-gebruikte 300 kB JavaScript-bundle je TBT verdubbelt en amper als kans wordt uitgelicht. Kijk naar de metrics, niet naar het aantal rode bolletjes.
Lighthouse: de meter die je zelf in de hand hebt
Lighthouse is de engine onder PageSpeed Insights, maar je kunt hem ook zelf draaien: in Chrome DevTools, via de CLI, of in een CI-pipeline met Lighthouse CI. Dat laatste is waar het interessant wordt.
De Performance-score weegt vijf metrics: TBT voor 30%, LCP voor 25%, CLS voor 25%, FCP voor 10% en Speed Index voor 10%. Wat opvalt: er zit geen INP in. Interactiviteit wordt in het lab benaderd met Total Blocking Time, en dat is een proxy — geen vervanging. Een pagina kan in het lab een TBT van 150 ms hebben en in het veld toch een INP van 400 ms, simpelweg omdat jouw bezoekers andere taken uitvoeren dan de gesimuleerde test.
Waarom je Lighthouse-score per run verschilt
Draai Lighthouse vijf keer op dezelfde pagina op je eigen laptop en je krijgt vaak 78, 86, 81, 91, 84. Oorzaken: CPU-belasting van andere tabs, browserextensies, een A/B-testtool die随机 een variant serveert, advertenties die per request verschillen. De mediaan van vijf runs is bruikbaar; één run is een anekdote.
In CI verdwijnt die ruis grotendeels. Vaste machine, vaste throttling, vaste viewport. Dan kun je budgetten afdwingen — bijvoorbeeld falen boven de 2,5 seconde LCP of boven de 300 ms TBT — en voorkom je dat een feature-team ongemerkt 200 kB JavaScript toevoegt.
Wanneer is een score echt slecht?
Cijfers, geen gevoel. Dit zijn de grenzen die Google hanteert:
- LCP: ≤ 2,5 s goed, 2,5–4,0 s aandacht, > 4,0 s slecht
- INP: ≤ 200 ms goed, 200–500 ms aandacht, > 500 ms slecht
- CLS: ≤ 0,1 goed, 0,1–0,25 aandacht, > 0,25 slecht
- TTFB: ≤ 0,8 s goed, > 1,8 s slecht
- TBT (lab): < 200 ms gezond, > 600 ms een echt probleem
Maar een getal is pas een probleem als het aan vier voorwaarden voldoet.
- Het komt uit velddata op het 75e percentiel. Niet uit een labrun op je MacBook.
- Het is structureel. Drie metingen, mediaan, niet één uitschieter tijdens een deploy.
- Het is mobiel. Desktopcijfers zijn voor de meeste Nederlandse sites irrelevant; het merendeel van je verkeer is mobiel.
- Het raakt een pagina die ertoe doet. Homepage, categorie, productdetail, checkout. Een trage blogpagina uit 2019 mag je negeren.
Een Lighthouse-score onder de 50 op mobiel met echte throttling is vrijwel altijd een terechte alarmbel. Een score tussen 75 en 89 met gezonde velddata is meestal geen probleem — daar win je geen ranking mee, en de uren zijn beter besteed aan content. En een score van 100 met een LCP van 4 seconden in CrUX bestaat echt. Dan is je labomgeving simpelweg niet representatief.
Een meetroutine die tien minuten kost
Begin bij het einde, niet bij de tool.
- PageSpeed Insights op je tien belangrijkste URL's, mobiel. Noteer alleen de veldmetrics. Geen score, geen kansen. Dit is je waarheid.
- Zit er een URL in het rood? Ga naar GTmetrix met een Europese testlocatie en drie runs. Open de waterfall en kijk naar drie dingen: TTFB, het zwaarste third-party domein, en render-blocking CSS of JS in de head.
- Fix, en zet een slot op de deur. Lighthouse CI in je pipeline met een budget per metric. Zo niet terugvallen.
Die volgorde is niet toevallig. PageSpeed vertelt je of je een probleem hebt, GTmetrix vertelt je waar, en Lighthouse CI voorkomt dat je het over drie maanden opnieuw uitzoekt.
Waarom dit zwaarder weegt dan drie jaar geleden
Snelheid was lang een rankingsignaal met een kleine marge. Nu is het ook een toegangspoort voor AI-systemen. Crawlers als GPTBot, OAI-SearchBot en PerplexityBot werken met een crawl budget en timeouts; een server die traag reageert levert minder opgehaalde pagina's op, en de pagina's die wel worden opgehaald komen met minder context binnen. In hoe ChatGPT jouw website vindt staat precies hoe dat proces verloopt.
Daar komt bij dat antwoordmachines pagina's liever citeren als de kerninhoud snel beschikbaar is. Als je LCP boven de vier seconden ligt door een render-blocking script van een chatwidget, betaal je daar dubbel voor: slechtere Core Web Vitals én minder kans om geciteerd te worden in AI Overviews. De technische details staan in Core Web Vitals en AI-crawlers.
Praktisch advies voor wie nu een site laat bouwen: zet performance budgetten in het contract in plaats van in een wenslijst. Concrete grenzen — LCP onder 2,5 seconde op mobiel, maximaal 200 kB JavaScript op de eerste load, geen third-party scripts zonder eigenaar en einddatum. Wat je bij oplevering niet hebt afgedwongen, betaal je later terug in een optimalisatietraject. Meer daarover in AI-native website laten maken.
De drie tools zijn geen jury. Het zijn meetinstrumenten. Gebruik PageSpeed om te bepalen of er iets aan de hand is, GTmetrix om te zien wat, en Lighthouse om te voorkomen dat het terugkomt.