Lighthouse Scores: een misleidend beeld van gebruikerservaring?

Wat is de PageSpeed Score precies? #

De PageSpeed Score is de uitkomst van een test die draait in een gecontroleerde laboratoriumomgeving. Tools zoals Google PageSpeed Insights of Lighthouse simuleren websurfen onder vaste, vooraf ingestelde omstandigheden — dat noemen we synthetisch testen.

Synthetisch testen verzamelt labdata over hoe een potentiële gebruiker — dus geen echte gebruiker — de website ervaart op het gebied van webprestaties.

Dit type testen heeft een aantal voordelen:

• Het maakt consistente benchmarking mogelijk doordat variabelen als apparaatcapaciteit en netwerksnelheid worden geëlimineerd.
• Het helpt technische problemen op te sporen die via code-optimalisatie op te lossen zijn.
• Het geeft concrete aanbevelingen om laadsnelheid en algehele prestaties te verbeteren.

Voor veel mensen werkt dat praktisch: pas de aanbevelingen toe en controleer direct of het gewenste resultaat bereikt is.

Toch heeft labdata ook beperkingen:

• Er is geen ruimte voor variaties in werkelijk gebruiksgedrag of de context van individuele gebruikers.
• De score geeft niet altijd een nauwkeurig beeld van hoe gebruikers de snelheid of bruikbaarheid van een site daadwerkelijk ervaren.
• Alleen de eerste paginalading wordt gemeten; gebruikersinteracties daarna vallen buiten beeld.
• Tests stuiten vaak op cookiemuren, waardoor third-party resources die normaal laden worden genegeerd.

Een Google PageSpeed-gebruiker bezoekt jouw website nooit #

Het grootste probleem van synthetisch testen: je kunt er niet mee beoordelen of jouw echte bezoekers een goede ervaring hebben. Toch gebruiken talloze mensen de PageSpeed Score precies daarvoor.

Of een bezoeker jouw site thuis bezoekt via Wi-Fi of onderweg via mobiel, maakt een groot verschil. Een thuisnetwerk is doorgaans stabiel, een laptop of desktop is krachtig. Mobiele netwerken zijn grilliger — ook bij 4G of 5G varieert de kwaliteit flink. De bandbreedte wisselt, en de latency ligt aanzienlijk hoger dan thuis of op kantoor.

Ook gemoedstoestand speelt mee: iemand onderweg heeft misschien haast, iemand thuis alle tijd. En dan is er het apparaat zelf: er zijn enorm veel verschillende mobiele toestellen in omloop, die allemaal anders presteren.

Google PageSpeed Insights houdt hier geen rekening mee. Er zijn twee profielen: een mobiele gebruiker en een desktopgebruiker, elk met vaste kenmerken. De kans is groot dat dit profiel niets gemeen heeft met jouw werkelijke bezoekers.

Welke meetmethode is geschikt? #

Field data op basis van Real User Monitoring (RUM) is de juiste manier om te beoordelen of jouw website goed presteert op het gebied van laadsnelheid, responsiviteit en visuele stabiliteit.

Field data verzamel je met gespecialiseerde tools. Google biedt zelf ook field data via het Chrome UX Report (CrUX). Die data heeft twee dagen vertraging en het effect van wijzigingen wordt pas na 28 dagen zichtbaar — maar de aansluiting op de praktijk is veel beter. De beperkingen van labdata verdwijnen:

• Het weerspiegelt de werkelijke ervaring van gebruikers op diverse apparaten, met verschillende verbindingen en vanuit uiteenlopende locaties.
• Het geeft inzicht in hoe echte bezoekers prestaties ervaren via (Core) Web Vitals, inclusief interacties na de eerste lading.
• Alleen op synthetische tests vertrouwen schept een vals gevoel van zekerheid: problemen die echte gebruikers wel merken, blijven onzichtbaar.

Een kanttekening: field data vereist voldoende verkeer voor betrouwbare resultaten. Google CrUX heeft een minimumdrempel. Bij lage bezoekersaantallen, of na een recente lancering of grote wijziging, duurt het even voordat er genoeg data beschikbaar is. Bovendien beperkt CrUX zich tot Chrome-gebruikers die bij installatie toestemming hebben gegeven voor datadeling.

Metingen kunnen ook verschuiven door veranderingen onder je bezoekers zelf — andere apparaten, netwerken of browsers. Dat zijn dynamische factoren, net als in het echte leven.

Field data geeft me geen score, hoe nu verder? #

Marketeers zijn dol op scores. Een score biedt een gestandaardiseerde manier om succes of effectiviteit te beoordelen — en in het geval van de Google PageSpeed Score ook webprestaties. Scores helpen bij het evalueren van voortgang, het vergelijken van aanpakken en het communiceren naar stakeholders.

Een score is begrijpelijk zonder dat je alle technische details over webprestatie-metrics of (Core) Web Vitals hoeft te kennen. Marketeers en andere betrokkenen kunnen resultaten helder presenteren aan directie of operationele teams die er verder niet mee bezig zijn.

Scores maken ook benchmarking mogelijk ten opzichte van concurrenten of branchestandaarden. Door scores te vergelijken binnen hetzelfde marktsegment, ontdek je verbeterpunten of kansen voor differentiatie.

Kortom: scores stroomlijnen het analyseproces en geven teams een gemeenschappelijke taal.

Introductie van de UX Score #

Met Googles (Core) Web Vitals beschikken we over metrics om de gebruikerservaring te beoordelen. Elke metric belicht een ander aspect van de UX dat bijdraagt aan de algehele ervaring van een pagina, template of website.

Per metric zijn evaluatiecriteria beschikbaar: streefdrempels waarmee je kunt beoordelen of de ervaring "goed" is, "verbetering nodig heeft" of "slecht" is.

En er is al een evaluatiemethode: Google verzamelt gebruikerservaringen via Chrome en Web Vitals. Geaggregeerde, geanonimiseerde data is beschikbaar via Google BigQuery, de CrUX API en diverse webtools.

De volgende stap — die enige discussie vereist — is een scoresysteem ontwikkelen dat gewichten toekent aan de verschillende evaluatiecriteria op basis van hun belang voor een optimale gebruikerservaring.

Zo ontstaat een UX Score waarmee je het succes van webprestaties kunt beoordelen. Maar belangrijker: hij is begrijpelijk voor een breed scala aan stakeholders. En hij stelt je in staat te beoordelen of een pagina, template of website — of die van een concurrent — goed presteert op laadsnelheid, responsiviteit en visuele stabiliteit. Simpelweg omdat de score is gebaseerd op ervaringen van echte gebruikers.

De UX Score toegelicht #

Er zijn verschillende manieren om een scoresysteem op te zetten. Onze aanpak is geen geheim — we delen hem graag. We hopen zelfs dat je nu overtuigd bent waarom een UX Score op basis van echte gebruikersdata beter is dan de Google Lighthouse Score, en dat je overweegt hem zelf te gebruiken of input te leveren voor een betere berekening.

Ons scoresysteem begint met een basisberekening. Elke Web Vital-metric krijgt een score op basis van de huidige prestaties ten opzichte van de min- en maxwaarden (afgeleid van de streefdrempels per metric). Hoe goed of slecht de prestaties ook zijn: de score blijft altijd tussen 0 en 100 punten.

Vervolgens passen we gewichten toe. De Core Web Vitals (hoofdmetrics) staan centraal: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) en Interaction to Next Paint (INP) leveren elk 25 punten bij. We hebben afscheid genomen van First Input Delay (FID); Interaction to Next Paint (INP) meet nu de responsiviteit. De ondersteunende metrics tellen minder zwaar mee: Time to First Byte (TTFB) draagt 10 punten bij, First Contentful Paint (FCP) 15 punten.

Net als bij de PageSpeed Score streven we naar 100 punten. Een totaalscore van 100 duidt op uitstekende laadsnelheid, visuele stabiliteit en responsiviteit. Een hoge score bevestigt dat de server snel reageert (TTFB) en dat initiële content snel verschijnt (FCP).

Een score van 90 of hoger geeft aan dat de gebruikerservaring als "goed" wordt ervaren. Het logisch gevolg: Core Web Vitals staan centraal. Ze weerspiegelen aspecten die gebruikers direct opvallen en moedigen aan om met iets extra inspanning een ervaring te creëren die op alle belangrijke UX-onderdelen optimaal is.

Slotgedachten #

We hopen feedback te ontvangen over onze UX-scoremethodologie — het evaluatieproces en, hopelijk, het succesvolle gebruik ervan. Dat helpt ons de aanpak continu te verfijnen. Een UX Score is sowieso een doorlopend traject: gebruikersverwachtingen evolueren en nieuwe technologieën komen op. Door evaluatiecriteria regelmatig bij te werken, blijft het scoresysteem relevant. Gelukkig doet Google het zware werk met (Core) Web Vitals. Waarschijnlijk hoeven we het systeem alleen bij te stellen als Google zelf aanpassingen doorvoert.

In een ideale wereld zou Google PageSpeed Insights geen score geven die uitsluitend op synthetisch testen is gebaseerd, maar ook RUM-data meenemen. Door die integratie zouden developers een veel realistischer beeld krijgen van prestaties voor echte gebruikers — in plaats van uitsluitend te vertrouwen op een labomgeving.

Wil je alvast zien welke UX Score jouw pagina's halen? Probeer dan https://pagespeed.compare. Die tool gebruikt field data (CrUX) om de hierboven besproken UX Score te berekenen.