Real User Monitoring: inzicht in de snelheid van websites in de praktijk en in het laboratorium

Echte gebruikers en laboratoriumtests

Monitoring van echte gebruikers (RUM) registreert hoe een website functioneert bij daadwerkelijke bezoeken. Een bezoek via een oudere smartphone met een mobiele verbinding kan aanzienlijk verschillen van een bezoek op een desktop met een snelle verbinding. Ook de bezochte pagina’s en interacties worden meegenomen in het geobserveerde beeld.

A Laboratoriumtest onderzoekt daarentegen een welbepaalde aanroep onder gecontroleerde omstandigheden. Het type apparaat, de netwerkomstandigheden en de testprocedure kunnen voor een onderzoek worden vastgelegd. Dit maakt het gemakkelijker om een afwijking opnieuw te reproduceren en mogelijke wijzigingen onder vergelijkbare omstandigheden te toetsen.

Deze twee invalshoeken geven antwoord op verschillende vragen: veldgegevens kunnen aantonen dat mobiele productpagina’s vaak traag laden. Ze bewijzen echter niet of bijvoorbeeld de productafbeelding, het renderpad of een trage documentrespons hiervoor verantwoordelijk is. Om de oorzaak te achterhalen, zijn aanvullende diagnoses en toetsbare hypothesen nodig.

PageSpeed Insights combineert beide perspectieven: het vergelijkt beschikbare veldgegevens uit het Chrome User Experience Report met laboratoriumdiagnoses op basis van Lighthouse. De resultaten hoeven niet overeen te komen, omdat echte bezoeken verschillende omstandigheden en gebruikspatronen omvatten, terwijl het laboratorium een vastgestelde testcase onderzoekt.

RUM is daarom geen vervanging voor het laboratorium. Omgekeerd kan een enkele laboratoriumtest niet aantonen hoe vaak een probleem zich bij daadwerkelijke bezoekers voordoet. Bovendien ontbreken er mogelijk voldoende veldgegevens vóór een publicatie of bij een website die nauwelijks wordt bezocht; zonder echte bezoeken ontstaan er helemaal geen eigen RUM-meetwaarden.

Zo ontstaan RUM-meetwaarden

Voor een eigen meting zijn drie onderdelen nodig: een registratie in de browser, een ontvanger voor de verzonden waarden en een analyse. Je bepaalt vooraf welke pagina’s en bezoekersgroepen je wilt bekijken en hoe de gegevens worden beschermd. Pas wanneer de afzonderlijke waarden op een zinvolle manier worden samengevat, vormen ze een basis voor beslissingen.

Browsers bieden hiervoor verschillende prestatie-interfaces aan. Navigatietijd beschrijft tijdstippen die verband houden met het navigeren naar het document, zoals het antwoord op de documentaanvraag. Resource Timing biedt tijdinformatie over afzonderlijke geladen bronnen, zoals afbeeldingen of scripts. Zo kunnen verschillende fasen van een laadproces nauwkeuriger worden afgebakend.

A PerformanceObserver houdt ondersteunde prestatiegegevens bij zodra deze beschikbaar komen. Voor Core Web Vitals kan de bibliotheek web-vitals de berekening en rapportage verzorgen. Welke gegevens en kengetallen beschikbaar zijn, hangt onder andere af van de browser; een meetscript registreert daarom niet automatisch elk bezoek volledig.

Niet elke waarde wordt direct bij het laden gegenereerd. Voor INP moet er bijvoorbeeld een geschikte interactie plaatsvinden: wie een pagina alleen leest en vervolgens weer verlaat, levert daarvoor mogelijk geen waarde op. Een ontbrekende meetwaarde is daarom noch nul, noch een bewijs van een snelle reactie.

Een RUM-dienst kan het vastleggen, ontvangen en analyseren als één pakket aanbieden. Bij een eigen ontwikkeling moet je daarnaast ook de exploitatie, opslag en kwaliteitsborging regelen. Daar hoort ook bij dat herhaalde meldingen in de levenscyclus van een pagina correct worden verwerkt, in plaats van elke melding ongecontroleerd als een afzonderlijk bezoek te tellen.

Core Web Vitals correct interpreteren

De Kernwaarden Web Vitals beschrijven drie verschillende aspecten van de gebruikerservaring. Largest Contentful Paint (LCP) meet wanneer het grootste relevante inhoudselement zichtbaar wordt. Op een productpagina kan dat bijvoorbeeld een grote productafbeelding zijn: als deze pas laat verschijnt, kan de pagina, ondanks dat de navigatie al eerder zichtbaar is, de indruk wekken dat deze nog niet volledig is geladen.

Interaction to Next Paint (INP) meet de vertraging tussen interacties en de volgende zichtbare verversing. Als een productfilter pas merkbaar reageert na een klik, kan INP op dit probleem wijzen. Cumulative Layout Shift (CLS) beschrijft daarentegen onverwachte verschuivingen van zichtbare inhoud, bijvoorbeeld wanneer een element dat achteraf wordt weergegeven een knop verplaatst.

Voor de beoordeling in PageSpeed Insights worden een LCP tot en met 2,5 seconden, een INP tot en met 200 milliseconden en een CLS tot en met 0,1 als goed beschouwd. CLS is een waarde zonder eenheden. De drempelwaarden gelden voor de betreffende indicator en mogen niet worden verward met de duur van een enkele paginabezoek.

Bepalend voor de veldbeoordeling is het 75e percentiel (p75): Ten minste ongeveer 75 procent van de meegenomen ervaringen ligt niet boven de betreffende waarde. Een goed gemiddelde alleen kan daarentegen verhullen dat een aanzienlijk deel van de bezoeken traag verloopt. Bekijk mobiel en desktop afzonderlijk, zodat verschillen tussen de apparaatgroepen zichtbaar blijven.

Time to First Byte (TTFB) vult deze statistieken aan bij het opsporen van een trage documentweergave. De waarde geeft echter niet uitsluitend de rekentijd van de server weer: ook het netwerk en andere tussenstations tot het moment dat de eerste antwoordbyte binnenkomt, spelen een rol. Navigation Timing en eventueel beschikbare Server Timing-gegevens helpen om de betrokken onderdelen nauwkeuriger te onderzoeken.

CrUX, eigen RUM en laboratorium

Om te beginnen hoef je niet meteen een eigen meetsysteem te gebruiken. PageSpeed Insights combineert veldgegevens uit de Chrome-rapport over de gebruikerservaring (CrUX) met een Lighthouse-laboratoriumdiagnose. De twee weergaven geven antwoord op verschillende vragen: de ene beschrijft geregistreerde ervaringen, de andere onderzoekt een pagina onder gecontroleerde omstandigheden.

De CrUX-veldgegevens in PageSpeed Insights hebben betrekking op een periode van 28 dagen in het verleden. Als er onvoldoende gegevens voor een specifieke URL beschikbaar zijn, kan het rapport in plaats daarvan gegevens van de ‘origin’ weergeven. Deze gegevens hebben betrekking op de bijbehorende website-origin en zijn niet gelijk te stellen aan de ervaringen op de exact ingevoerde pagina. Let daarom goed op welk niveau het rapport daadwerkelijk weergeeft.

CrUX houdt alleen rekening met Chrome-gebruikers die aan de betreffende voorwaarden voldoen; andere browsers en niet-gerechtigde gebruikers worden niet meegeteld. Op een kleine of niet-openbare website kunnen CrUX-gegevens ontbreken. Een eigen, juridisch en technisch verantwoorde gegevensverzameling kan daar niettemin inzichten opleveren, maar blijft bij een gering aantal bezoeken statistisch beperkt.

Synthetische monitoring herhaalt vooraf gedefinieerde tests, ook als er op dat moment niemand de website bezoekt. Dit is geschikt om een proces regelmatig onder vergelijkbare omstandigheden te observeren. Of gebruikers met andere apparaten of via andere netwerken dezelfde ervaring hebben, moet worden vastgesteld door middel van een veldmeting; een enkele synthetische test kan dit inzicht niet vervangen.

Bij de keuze is het daarom van belang welke vraag je wilt beantwoorden: een openbaar rapport is snel beschikbaar, terwijl een eigen systeem een meer gerichte registratie mogelijk maakt. Een dienst kan operationele taken uit handen nemen, terwijl laboratorium- en synthetische tests gecontroleerde onderzoeken mogelijk maken. Maar ook een dienst vereist een weloverwogen selectie van gegevens en evaluatiegroepen.

Zelf metingen goed voorbereiden

Bepaal eerst een concrete vraag, bijvoorbeeld of mobiele productpagina’s vaker een hoge LCP hebben dan andere soorten pagina’s. Bepaal vervolgens welke pagina’s en apparaatcategorieën je wilt onderscheiden, welke statistieken daarvoor nodig zijn en hoe lang je gegevens wilt verzamelen. Pas daarna beslis je over het meetscript, de ontvanger en de analyse.

Als eerste technische stap kun je de bibliotheek web-vitals lokaal in een browserproject integreren en de uitvoer in de ontwikkelaarstools bekijken. De volgende JavaScript-code maakt gebruik van de gepubliceerde pakketversie 6.2.3. Hierbij wordt ervan uitgegaan dat deze versie in het project is geïnstalleerd en dat de build de module-imports verwerkt. Het voorbeeld verstuurt geen gegevens naar een server en activeert geen afzonderlijke meting van softnavigatie.

import {onCLS, onINP, onLCP} from 'web-vitals';

onCLS(console.log);
onINP(console.log);
onLCP(console.log);

De console-uitvoer is een manier om de integratie te controleren, geen bewijs van de snelheid van je bezoekers. Open de projectpagina en voer bijvoorbeeld een actie uit met een filter. Een INP-waarde vereist een geschikte interactie en hoeft niet onmiddellijk te verschijnen; zonder geschikte interactie kan deze zelfs helemaal ontbreken. Ook browserondersteuning en de levenscyclus van de pagina beïnvloeden de weergave.

Maak een plan voor een latere evaluatie van de Levenscyclus van een pagina een: Er kunnen meerdere meldingen binnenkomen, bijvoorbeeld wanneer een pagina wordt verborgen en later weer wordt weergegeven. Tel deze meldingen niet zonder meer mee als afzonderlijke bezoeken. De bibliotheek biedt metriek-ID’s waarmee meldingen aan dezelfde metriek kunnen worden toegewezen.

Ook het terugzetten vanuit de Back/Forward-cache vereist een specifieke aanpak. Dit kan een nieuwe metriekmelding activeren, hoewel het document uit de cache terugkeert. Bepaal hoe je dergelijke herstelacties in je rapport onderscheidt van gewone navigaties, en raadpleeg de specifieke bibliotheekinstructies voordat je een productieve registratie instelt.

Meetwaarden per segment analyseren

Een totaalcijfer voor de webshop kan verhullen dat juist mobiele productpagina’s trager zijn. Splits de meetresultaten daarom ten minste uit naar paginatype en apparaatklasse en bekijk voor elke statistiek een vastgestelde periode. Zo vergelijk je bijvoorbeeld mobiele productpagina’s met mobiele categoriepagina’s, in plaats van verschillende gebruikssituaties ongemerkt door elkaar te halen.

Voor elk segment is dat 75e percentiel veelzeggender dan een louter gemiddelde: het geeft de waarde weer die door ten minste ongeveer 75 procent van de meegenomen ervaringen niet wordt overschreden. Een laag gemiddelde kan daarentegen verhullen dat een relevante groep lang moet wachten. Vergelijk p75 alleen binnen dezelfde maatstaf en met de juiste eenheid.

Het aantal geldige waarden maakt direct deel uit van het resultaat. Als een segment slechts uit enkele metingen bestaat, kunnen afzonderlijke waarnemingen het percentiel sterk beïnvloeden; een verandering hoeft dan niet te wijzen op een algemeen probleem. Kies indien nodig een langere periode of voeg inhoudelijk vergelijkbare pagina’s samen, zonder dat dit ten koste gaat van de vergelijkbaarheid.

Een ontbrekende INP is geen snelle INP en mag niet als nul in de verdeling worden meegenomen. Geef in plaats daarvan het aantal geldige INP-waarden afzonderlijk op. Als veel bezoeken geen geschikte interactie opleveren, beschrijft de INP-analyse alleen de geregistreerde interactie-ervaringen en niet automatisch alle paginaweergaven.

Groepeer herhaalde meldingen op de juiste manier op basis van de metriek-ID, in plaats van elke melding als een nieuwe, onafhankelijke waarneming te behandelen. Documenteer bovendien hoe herstelacties vanuit de back/forward-cache worden geteld. Zo blijft het traceerbaar welke waarnemingen daadwerkelijk in de p75 en in het opgegeven aantal zijn opgenomen.

Van het veldprobleem naar de diagnose

Als uit de veldgegevens blijkt dat mobiele productpagina’s traag laden, baken dan eerst het betreffende segment af: heeft de slechte LCP betrekking op veel producten of slechts op één type pagina? Controleer tegelijkertijd de periode en het aantal geldige waarden. Zo krijg je een aanknopingspunt voor het onderzoek, maar nog geen bewijs voor welk element de vertraging veroorzaakt.

Vul vervolgens in de Laboratoriumtest Probeer zo veel mogelijk vergelijkbare omstandigheden na te bootsen, bijvoorbeeld met een mobiele apparaatconfiguratie en een beperkte netwerksnelheid. Onderzoek welk element als LCP verschijnt en wanneer het wordt geladen en weergegeven. Een grote productafbeelding, een late afbeeldingsaanvraag of een geblokkeerd renderpad zijn mogelijke hypothesen die je aan de hand van de diagnose moet controleren.

Als er aanwijzingen zijn dat er afbeeldingen worden geleverd, kun je de bestandsgrootte, formaten en beschikbaarheid controleren. Een Content Delivery Network is een mogelijke maatregel, maar biedt geen garantie voor een betere LCP. Als het antwoord op het document daarentegen wijst op een knelpunt, helpt een aanvullende Serverbenchmark voor PHP-workloads, om de toepassing onder bepaalde voorwaarden te onderzoeken.

Bij een vertraagde productfilter is de interactie doorslaggevend, in plaats van het laadproces. Simuleer een klik op de filter en ga na welke bewerkingen er nodig zijn totdat de update zichtbaar wordt. Waar de browser dit ondersteunt, kun je Lange animatieframes Ze geven aanwijzingen over langdurige rendering-updates en de betrokken scripts; ze verklaren niet automatisch elke trage interactie.

Voer een gerichte wijziging door en observeer vervolgens dezelfde groep pagina’s opnieuw in de praktijk. Een beter laboratoriumresultaat toont in eerste instantie alleen het effect onder de gekozen testomstandigheden. Pas de latere praktijkanalyse kan uitwijzen of ook de geregistreerde ervaringen van echte bezoekers zijn veranderd.

Gegevenskwaliteit en gegevensbescherming in de bedrijfsvoering

Bepaal vóór de productieve ingebruikname welke meetwaarden nodig zijn voor jouw vraagstelling en wie deze verwerkt. De planning omvat een veilige overdracht naar de ontvanger, toegangsbeperkingen, een beperkte bewaartermijn en een verwijderingsprocedure. Controleer de kwesties rond gegevensbescherming en toestemming voor de concrete implementatie en de geldende regels op vaktechnisch vlak, in plaats van uit te gaan van een algemene goedkeuring.

Met de Gegevensminimalisatie Het loont de moeite om naar de diagnosevelden te kijken: volledige URL’s kunnen gevoelige informatie bevatten in queryparameters; ook DOM-selectoren kunnen details over de inhoud van pagina’s of invoer onthullen. Leg indien mogelijk een algemeen paginatype vast en enkele zorgvuldig geselecteerde attributen. Controleer ook welke gegevens een geïntegreerde dienst bovendien verzamelt of opslaat.

Meetwaarden zijn niet altijd direct beschikbaar. De bibliotheek web-vitals kan tijdens de levenscyclus van een pagina meerdere keren feedback geven; een latere melding mag daarom niet zomaar als een nieuw, onafhankelijk bezoek worden geteld. Bepaal hoe bij elkaar horende meldingen worden verwerkt en hoe herstelacties vanuit de back/forward-cache worden behandeld.

Voor kleine diagnosepakketten kan de overdracht plaatsvinden via sendBeacon tijdens het evenement visibilitychange geschikt zijn. Dit vergroot de kans dat gegevens worden verzonden wanneer een pagina wordt verborgen, maar garandeert geen bezorging. De ontvanger moet de gegevens bovendien veilig in ontvangst nemen en zo verwerken dat herhaalde berichten de analyse niet onopgemerkt vertekenen.

Houd ten slotte rekening met de Lacunes in de registratie: Geblokkeerde scripts, ontbrekende browserondersteuning of verloren gegane gegevensoverdracht kunnen ertoe leiden dat bepaalde bezoeken ontbreken. Schat het verliespercentage in, samen met de wijze van registratie. De overgebleven meetwaarden geven een beeld van de waargenomen groep en hoeven niet alle bezoekers in gelijke mate weer te geven.

Veranderingen beoordelen en een procedure kiezen

Om na een implementatie een vergelijking te maken, bepaal je van tevoren welke paginatypen, apparaatklassen en tijdsperioden in aanmerking worden genomen. Vergelijk voor elke metriek het 75e percentiel en het aantal geldige waarden vóór en na de wijziging. Tijdvensters van vergelijkbare lengte helpen bij de interpretatie; er ontstaan hierdoor echter niet automatisch voldoende vergelijkbare steekproeven.

Houd rekening met een veranderde samenstelling van het bezoekersverkeer. Als er na een implementatie meer gebruikers met trage mobiele verbindingen komen, kan de totale score verslechteren, ook al is de wijziging zelf niet trager. Ook seizoensgebonden gebruik of andere gelijktijdige veranderingen maken de toewijzing moeilijker. Een tijdsverband is daarom een hypothese, geen Bewijs van causaliteit.

CrUX en eigen RUM hoeven niet dezelfde resultaten op te leveren: ze kunnen verschillende gebruikersgroepen, tijdsperioden en meetvoorwaarden bestrijken. Bij CLS komt daar nog bij dat CrUX ook de bijdragen van ingesloten frames aan de ervaring van de bovenliggende pagina meeneemt. Een JavaScript-meting in het hoofddocument registreert deze bijdragen niet altijd volledig. Vergelijk daarom eerst de meetgrondslagen voordat je een afwijking als fout beschouwt.

Bij een single-page-applicatie moet je bepalen of je documentnavigatie of interne routewijzigingen wilt onderzoeken. Voor de afzonderlijke registratie van Zachte navigatie ondersteunt Web Vitals vanaf versie 6, mits de browser dit ondersteunt, de optie reportSoftNavs: true. Deze optie moet worden ingesteld bij de betreffende metriek-callbacks. In het vorige consolevoorbeeld zonder deze optie wordt geen afzonderlijke routemeting geactiveerd.

Wanneer de registratie van soft-navigatie is ingeschakeld, worden CLS en INP voor de nieuwe navigatie gereset en afzonderlijk beschouwd; de waarden van de vorige navigatie worden bij het wisselen van route afgesloten. Dergelijke waarden, die in de tijd anders zijn afgebakend, mag je niet zonder meer vergelijken met metingen over het gehele document. Zonder de juiste browserondersteuning leidt de optie niet tot een overeenkomstige afzonderlijke routemeting.

Bij het kiezen van een RUM-dienst controleer je, naast de browserdekking, of de benodigde paginagroepen en apparaatklassen kunnen worden geanalyseerd. Informeer naar steekproefmethoden, gegevensverwerking, opslag en exportmogelijkheden. Even belangrijk is welke effecten het meetscript zelf op de pagina kan hebben en of de gegevensverzameling kan worden beperkt tot wat voor jouw vraagstelling noodzakelijk is.