Een marketingbureau mailt je ongevraagd: “Uw website scoort maar 38 op Google PageSpeed — u verliest dagelijks klanten!” Je doet de test zelf op pagespeed.web.dev en ja hoor: een oranje 38, met daaronder een waslijst aan rode driehoekjes en onbegrijpelijke termen. Tijd voor paniek?
Nee. Een PageSpeed-rapport is een nuttig instrument, maar het wordt vaker verkeerd gelezen dan goed. Als je drie dingen snapt — het verschil tussen veld- en labdata, wat de drie Core Web Vitals betekenen, en welke meldingen je mag relativeren — haal je er in vijf minuten uit wat er écht toe doet.
Eerst: wat test je eigenlijk?
PageSpeed Insights test één pagina per keer, niet je hele site. Je homepage kan prima scoren terwijl je dienstenpagina traag is (of andersom). En je krijgt twee tabbladen: mobiel en desktop. Mobiel scoort vrijwel altijd flink lager — de test simuleert daar bewust een middenklasse-telefoon op een matige verbinding. Kijk vooral naar mobiel: zo bezoeken de meeste mensen je site.
Velddata vs labdata: waarom de cijfers elkaar tegenspreken
Het rapport bestaat uit twee delen die vaak iets anders zeggen, en dát is de grootste bron van verwarring.
Bovenaan staan de velddata: metingen van échte Chrome-gebruikers die je site de afgelopen 28 dagen bezochten. Dit is de werkelijkheid. Kanttekening: deze data verschijnt alleen als je site genoeg bezoekers heeft; bij kleine sites blijft dit blok leeg.
Daaronder staat het bekende cijfer van 0 tot 100: labdata. Dat is een simulatie (Lighthouse) die op het moment van de test wordt gedraaid, met die bewust trage telefoon. Handig om problemen op te sporen, maar het is een momentopname onder kunstmatig zware omstandigheden.
Daarom kan je site een matige labscore hebben terwijl je echte bezoekers groene velddata zien — of andersom. Welke telt? De velddata. Ook Google kijkt voor de zoekresultaten naar wat echte gebruikers ervaren, niet naar je labcijfer. Een 38 in het lab met groene velddata is geen crisis; rode velddata verdient wél actie.
De drie Core Web Vitals in mensentaal
In de velddata draait alles om drie metingen, de Core Web Vitals:
- LCP (Largest Contentful Paint) — hoe snel is het grootste element (meestal je hoofdafbeelding of kop) zichtbaar? Goed is binnen 2,5 seconden. Dit is de “voelt de site snel”-meting.
- INP (Interaction to Next Paint) — hoe snel reageert de pagina als iemand klikt of typt? Goed is binnen 200 milliseconden. Traag reageren op klikken frustreert misschien nog wel meer dan traag laden; we schreven er een apart stuk over: INP uitgelegd en gefixt.
- CLS (Cumulative Layout Shift) — verspringt de pagina tijdens het laden? Je kent het: je wilt op een knop drukken en er schuift nét een banner tussen. Goed is een score onder 0,1.
Alle drie groen? Dan doet je site het voor echte bezoekers gewoon goed — wat het labcijfer ook beweert.
Welke meldingen je mag relativeren
Onder “Diagnostiek” somt het rapport verbeterpunten op, met geschatte besparingen. Een paar nuances die de meeste bureau-mails weglaten:
- “Verminder ongebruikt JavaScript / CSS”: dat zit meestal in je thema of pagebuilder. Zonder ontwikkelaar valt hier weinig te halen — en het slopen van de verkeerde regels breekt je site.
- Google’s eigen scripts staan er ook tussen. Analytics, Maps, fonts van Google: het rapport rekent ze vrolijk aan. Weghalen is zelden een optie; zwaar tillen hoef je er dus ook niet aan.
- De “geschatte besparingen” zijn theoretisch. Al die milliseconden bij elkaar optellen mag niet; veel verbeteringen overlappen.
- Een score van 100 is geen doel. De laatste tien punten kosten onevenredig veel moeite en leveren je bezoekers vrijwel niets op.
Wat je zelf kunt doen — en wat hosterwerk is
Zelf (grootste winst eerst):
- Afbeeldingen verkleinen. De klassieker: een foto van 4000 pixels breed in een vak van 400. Verklein en comprimeer vóór het uploaden, of gebruik een plugin die dat automatisch doet.
- Caching aanzetten. Eén goede cache-oplossing serveert kant-en-klare pagina’s in plaats van alles per bezoek op te bouwen.
- Opruimen. Elke plugin, slider en embed laadt mee. Weg met wat je niet gebruikt.
Hosterwerk: meldingen als “verkort de initiële reactietijd van de server” gaan over hoe snel de server het éérste antwoord geeft. Dat hangt af van je hostingpakket, de serverconfiguratie en je PHP-versie — dingen die jij hooguit via het hostingpaneel aanraakt. Blijft de reactietijd traag ondanks caching, dan is dat een gesprek met je hoster.
Waarom die snelheid commercieel de moeite waard is, lees je in waarom je website binnen 3 seconden moet laden.
Samengevat
- PageSpeed test één pagina; kijk vooral naar het mobiele tabblad.
- Velddata (echte gebruikers) telt; het labcijfer is een hulpmiddel, geen rapportcijfer voor je bedrijf.
- Groene Core Web Vitals (LCP, INP, CLS) = je site doet het goed, wat de score ook zegt.
- Grootste zelf-te-pakken winst: afbeeldingen verkleinen, caching aan, plugins opruimen.
- Servermeldingen zijn hosterwerk; en laat je niet bang maken door verkoopmails met alleen een labscore.
Wanneer schakel je hulp in?
Zijn je velddata rood en kom je met afbeeldingen, caching en opruimen niet ver genoeg? Dan zit het dieper — in je thema, een trage server of een plugin die uit de bocht vliegt. Dat is uitzoekwerk voor je webbouwer of hoster. Stuur ze gerust de PageSpeed-link mee; wie er verstand van heeft, ziet in het rapport meteen waar het knelt.