Blog
Een score, geen snelheidsmeting.
Waarom je PageSpeed-cijfer weinig zegt over wat je bezoekers echt ervaren, en waar je wel op moet letten.
Je PageSpeed-score is geen snelheidsmeting.
Het is een samengesteld cijfer uit een gesimuleerde test, op een pagina, op een moment, op een nagebootst toestel.
Wat je bezoekers werkelijk ondervinden staat in een ander blok van hetzelfde rapport, dat minder aandacht krijgt dan het gekleurde cijfer.
Labdata en velddata zijn twee verschillende metingen
Labdata komt uit een test, velddata komt uit je bezoekers.
Lighthouse voert een enkele laadbeurt uit in een gecontroleerde omgeving, met een nagebootst middenklassetoestel en een afgeknepen verbinding en rekent dat om naar een cijfer van 0 tot 100.
Het Chrome User Experience Report, kortweg CrUX, verzamelt metingen bij echte Chrome-gebruikers en rapporteert het 75e percentiel over een voortschrijdend venster van 28 dagen, dagelijks bijgewerkt.
PageSpeed Insights toont beide naast elkaar, maar de meeste rapporten citeren alleen het cijfer.
De Lighthouse-score zelf is geen rankingfactor.
De Core Web Vitals zijn dat wel en die worden bij echte bezoekers gemeten, dus in de velddata.
Je kunt je score dus flink verbeteren zonder dat er voor Google of voor je bezoeker iets verandert.
Waarom een score van 100 niets garandeert
Een 100 zegt dat een enkele laadbeurt van een enkele URL goed verliep.
Drie dingen vallen daarbuiten: de test start met een leeg cache terwijl een deel van je bezoekers terugkeert, hij meet meestal je homepage terwijl je verkeer op overzichten en detailpagina's landt en hij klikt nergens, dus alles wat pas na interactie gebeurt blijft ongemeten.
Dat laatste is de grootste blinde vlek.
Interaction to Next Paint zit niet in de Lighthouse-score, want een standaardrun klikt nergens: zonder interactie valt er geen INP te berekenen.
Betrouwbare INP-cijfers komen daarom uit je velddata.
In het lab staat Total Blocking Time in de plaats en dat meet iets anders: hoe lang de hoofdthread bezet is tijdens het laden, niet hoe traag je facetfilter reageert op de derde klik.
Een Drupal-site met zware Views-facetten, een autocomplete-zoekveld en een kaartwidget kan 100 halen en bij echte bezoekers toch boven de 200 milliseconden INP uitkomen.
Je cookiebanner vertekent het beeld op dezelfde manier, want scripts die pas na toestemming laden komen in een labtest niet aan bod.
Waarom 70 prima kan zijn
Een 70 valt in de oranje band en zegt op zich niets over je bezoekers.
De score is een gewogen gemiddelde van vijf labmetingen en die gewichten liggen vast:
| Labmeting | Gewicht in de score |
|---|---|
| Total Blocking Time | 30 procent |
| Largest Contentful Paint | 25 procent |
| Cumulative Layout Shift | 25 procent |
| First Contentful Paint | 10 procent |
| Speed Index | 10 procent |
De banden zijn 0 tot 49 rood, 50 tot 89 oranje en 90 tot 100 groen.
Omdat Total Blocking Time dertig procent weegt, trekt een zwaar maar noodzakelijk script je cijfer stevig omlaag terwijl de pagina visueel snel klaar staat.
Blijkt uit je velddata dat je op het 75e percentiel onder 2,5 seconden LCP, onder 200 milliseconden INP en onder 0,1 CLS blijft, dan hebben je bezoekers een goede ervaring.
Dan is 70 gewoon 70 en heb je van mij geen optimalisatietraject nodig.
Waar je wel op stuurt
Op de drie velddata-metingen, per paginatype, op het 75e percentiel.
- Per template meten: homepage, overzicht, detail en zoekresultaat gedragen zich anders, dus een sitegemiddelde verbergt waar het fout gaat.
- Mobiel en desktop apart houden: de drempels worden gesegmenteerd beoordeeld en dat verschil is meestal groter dan tussen twee templates.
- Een eigen meting toevoegen: CrUX neemt alleen publiek vindbare pagina's met voldoende bezoekers op, dus kleinere sites meten zelf bij hun bezoekers.
- Geduld inbouwen: door het venster van 28 dagen werkt een ingreep pas na weken volledig door, dus beoordeel een fix niet na twee dagen.
Wanneer een lage score toch een signaal is
Zonder velddata is de labscore het enige dat je hebt.
Dat geldt voor nieuwe sites en voor pagina's met weinig verkeer.
Gebruik het cijfer niet als doel, maar lees de diagnostiek eronder: renderblokkerende bronnen, afbeeldingen zonder vaste afmetingen, ongebruikte JavaScript.
Wijzen lab en veld dezelfde richting aan, bijvoorbeeld rode velddata bij een score van 35, dan is er werkelijk iets stuk en is de score een bevestiging in plaats van een mythe.
Welke ingrepen in een Drupal-site dan het meeste opleveren, zet ik op een rij in mijn artikel over Core Web Vitals voor Drupal en waar de winst echt zit.
Mijn aanpak: meten bij bezoekers, herstellen in de code, vastleggen
Ik begin bij je velddata en niet bij de tool.
Ik breng in kaart welke templates op het 75e percentiel onder de drempels zakken, zoek de oorzaak in de frontend en in de Drupal-configuratie en leg vast wat er verandert zodat je het na elke release opnieuw kunt controleren.
Drupal 11 levert met Dynamic Page Cache en BigPipe een stevige basis, maar geen automatisme: verkeerd ingestelde cachecontexten halen die winst er weer uit.
Tools voor de basis, handwerk voor de rest.
Wil je weten waar je site staat bij echte bezoekers, bekijk dan mijn dienst technische SEO en frontend performance.
Zit het knelpunt dieper in de architectuur, dan hoort het bij Drupal architectuur en ontwikkeling.
Stuur me je URL via het contactformulier en ik geef je binnen 24 uur een eerlijk beeld van wat er te winnen valt.
Veelgestelde vragen
Hoe kan ik mijn website snelheid testen?
Met PageSpeed Insights, want dat toont in een rapport zowel de velddata uit CrUX als de labscore uit Lighthouse.
Kijk eerst naar het veldblok met LCP, INP en CLS op het 75e percentiel over 28 dagen en gebruik de labscore daaronder alleen om oorzaken te zoeken.
Er is geen beste tool, er is een juiste combinatie: Lighthouse in Chrome DevTools laat je zelf toestel en throttling kiezen en een eigen meting bij je bezoekers vult aan wat CrUX niet dekt.
Voor sites met weinig verkeer is die eigen meting geen luxe, want CrUX vraagt een minimumaantal bezoekers voordat een pagina in de dataset komt.
Test in elk geval meer dan je homepage, want een overzichtspagina gedraagt zich anders dan je startpagina.
Waarom is mijn website traag?
Meestal door te veel JavaScript, te zware afbeeldingen en caching die niet op de juiste laag staat.
Welke van de drie bij jou doorweegt verschilt per site, dus begin met meten in plaats van optimaliseren.
In Drupal zie ik het vaak bij views zonder de juiste cachecontexten, bij te veel losse blokken op een pagina en bij scripts van derden die na de cookiebanner alsnog binnenkomen.
Traagheid is zelden een enkele oorzaak, dus een audit die alleen naar de score kijkt mist doorgaans de helft.
Hoe kan ik de performance van mijn website meten?
Op twee niveaus: bij echte bezoekers en in een test.
Velddata uit CrUX of uit je eigen meetscript geven je LCP, INP en CLS zoals bezoekers ze meemaken, gesegmenteerd naar mobiel en desktop.
Een labtest in Lighthouse levert daarna de diagnostiek waarmee je ziet waar die tijd heen gaat.
De velddata bepalen of je een probleem hebt, de labtest helpt je het vinden.
Is een PageSpeed-score van 100 nodig voor goede SEO?
Nee.
De Lighthouse-score is geen rankingfactor, de Core Web Vitals zijn dat wel en die worden bij echte bezoekers gemeten.
Blijf je op het 75e percentiel onder 2,5 seconden LCP, onder 200 milliseconden INP en onder 0,1 CLS, dan zit je goed, of het cijfer in de tool nu 72 of 98 is.
De laatste punten najagen kost meestal meer dan het opbrengt, dus stop wanneer de velddata groen staan.
Wat is het verschil tussen labdata en velddata?
Labdata komt uit een test, velddata komt uit je bezoekers.
Lighthouse doet een enkele laadbeurt in een gecontroleerde omgeving, met een nagebootst middenklassetoestel en een afgeknepen verbinding en rekent dat om naar een cijfer van 0 tot 100.
CrUX verzamelt metingen bij echte Chrome-gebruikers en rapporteert het 75e percentiel over een voortschrijdend venster van 28 dagen.
De velddata zeggen dus of je bezoekers een goede ervaring hebben, de labdata helpen je vooral om de oorzaak te vinden.
Zit Interaction to Next Paint in mijn PageSpeed-score?
Nee.
Een standaardrun van Lighthouse klikt nergens en zonder interactie valt er geen INP te berekenen.
In het lab staat Total Blocking Time in de plaats en dat meet hoe lang de hoofdthread bezet is tijdens het laden, niet hoe traag je filter reageert op de derde klik.
Betrouwbare INP-cijfers komen daarom uit je velddata, waar je op het 75e percentiel onder 200 milliseconden wilt blijven.
Een vraag over dit onderwerp?
Beschrijf kort je situatie, dan laat ik weten wat er speelt en wat het zou kosten. Zonder offertetraject.
