Monitoring 5 min. leestijd

Synthetische monitoring vs real user monitoring: wat heb je nodig?

Synthetische checks testen je site volgens een vast schema; real user monitoring meet echte bezoeken. Hoe ze werken, wat ze missen en waar je begint.

Synthetische monitoring test je website of API met gescripte verzoeken volgens een vast schema, of er nu bezoekers zijn of niet. Real user monitoring (RUM) meet wat echte bezoekers ervaren, via een script in hun browser, maar alleen wanneer ze je site bezoeken. Synthetische checks vertellen je dat er iets kapot is, vaak voordat klanten het merken. RUM vertelt je hoe snel en soepel de site is voor de mensen die hem gebruiken, op hun eigen apparaten en netwerken. Begin met synthetische checks voor beschikbaarheid, en voeg RUM toe zodra je wilt weten hoe de site presteert voor echte bezoekers.

Hoe synthetische monitoring werkt

Een monitoringdienst speelt de bezoeker. Vanaf een bekende locatie en volgens een vast schema stuurt hij een verzoek of voert hij een script uit en beoordeelt hij het resultaat. Omdat hij elke keer hetzelfde doet, zijn de resultaten van check tot check vergelijkbaar, en een storing om 03:00 wordt om 03:00 gevonden, zonder dat er verkeer nodig is. Synthetische monitoring bestaat in verschillende vormen:

Uptime checks: één verzoek naar een URL, host of poort, gecontroleerd op de statuscode, de responstijd en vaak de inhoud. Dit is de eenvoudigste vorm; zie wat uptime monitoring is.

API-checks: een verzoek met een methode, headers en body, en controles op de JSON die terugkomt.

Flows in meerdere stappen: een traject zoals inloggen of afrekenen, stap voor stap uitgevoerd, als gewone HTTP-verzoeken of in een echte browser die JavaScript uitvoert.

Prestatietests in het lab: een tool zoals Lighthouse laadt een pagina op een gesimuleerd apparaat en netwerk en geeft er een score aan.

Hoe real user monitoring werkt

Real user monitoring voegt een script toe aan je pagina’s. In de browser van elke bezoeker leest het timings uit die browsers via standaard-API’s beschikbaar stellen, zoals Navigation Timing, en stuurt die naar een collector. Opgeteld over alle bezoeken krijg je verdelingen: hoe lang pagina’s nodig hebben om te laden, hoe snel ze reageren op klikken en welke pagina’s JavaScript-fouten geven, uitgesplitst naar land, apparaat en browser.

Omdat de resultaten verdelingen zijn, rapporteert RUM percentielen in plaats van losse getallen. De Core Web Vitals van Google worden gemeten op het 75e percentiel van de paginaladingen, met deze drempels voor een goede ervaring:

Largest Contentful Paint (laden): 2,5 seconden of minder.

Interaction to Next Paint (reactiesnelheid): 200 milliseconden of minder.

Cumulative Layout Shift (visuele stabiliteit): 0,1 of minder.

Er bestaat ook RUM-data die je niet zelf verzamelt. Het Chrome UX Report (CrUX) van Google publiceert velddata van Chrome-gebruikers die daar toestemming voor geven, per pagina en per site, zodra er genoeg verkeer is. Het zijn de gegevens die Google gebruikt voor Core Web Vitals in de zoekresultaten.

Naast elkaar

Synthetische monitoringReal user monitoringWie de data genereertEen monitoringdienst, volgens een schemaJe bezoekers, wanneer ze langskomenVerkeer nodigNeeJaScript in je pagina’s nodigNeeJaDetecteert een storingJa, bij de volgende checkIndirect, wanneer de data stoptDektDe pagina’s en trajecten die je scripttElke pagina die mensen bezoekenApparaten en netwerkenEen paar bekendeDie van al je bezoekersResultatenGeslaagd of mislukt, een timing per checkVerdelingen en percentielenHet meest geschikt voorBeschikbaarheid, alerts, regressies na deploys opsporenEchte prestaties, Core Web Vitals, fouten in de browser

Wat elk van beide mist

Blinde vlekken van synthetische monitoring

Paden die je niet hebt gescript. Test de checkoutflow één product, dan valt een kapotte pagina in een andere categorie niet op.

Waar je bezoekers zijn. Een check vanuit één stad ziet de route van die stad naar je server, niet die van een bezoeker op een mobiel netwerk op een ander continent.

Echte apparaten. Een trage telefoon, een browserextensie of een oude browserversie kan een pagina breken of vertragen die elke check doorstaat.

Blinde vlekken van RUM

Geen bezoekers, geen data. ’s Nachts, op een nieuwe pagina of op een site met weinig verkeer heeft RUM weinig of niets te melden.

Storingen. Ligt de site eruit, dan laadt het script nooit en wordt er niets gemeld. Een gat in een grafiek zie je makkelijk over het hoofd, en het maakt niemand wakker.

Bezoekers die je niet kunt meten. Adblockers en cookiekeuzes kunnen het script tegenhouden, dus de data beschrijft de bezoekers die het toestaan.

Gewicht. Het script zelf is extra werk voor de pagina. Laad het asynchroon en controleer de omvang.

Labdata vs velddata

Dezelfde tweedeling zie je in prestatietools, waar het labdata en velddata heet. Een Lighthouse-score is labdata: één synthetische paginalading op een gesimuleerde middenklassetelefoon en een gesimuleerd netwerk. CrUX en je eigen RUM zijn velddata: wat echte bezoeken hebben gemeten. Ze spreken elkaar vaak tegen. Een pagina kan in het lab slecht scoren en in het veld toch slagen voor Core Web Vitals, omdat de meeste bezoekers snelle apparaten hebben, of andersom. Gebruik labdata om problemen te vinden en op te lossen en om de ene release met de volgende te vergelijken, en velddata om te beoordelen wat bezoekers echt krijgen. De tips voor een snellere website helpen bij allebei, en wat een goede responstijd is behandelt de serverkant.

Waar je mee begint

Elke site: synthetische uptime checks op de homepage en de pagina’s die geld opleveren. Een storing kost meer dan een trage pagina, en alleen synthetische checks waarschuwen je er betrouwbaar voor. De checklist van wat je moet monitoren somt de URL’s op die het waard zijn.

Webshops en SaaS-producten: voeg flows in meerdere stappen toe voor afrekenen of inloggen, zodat een kapot traject wordt opgemerkt, ook als elke afzonderlijke pagina 200 terugstuurt.

Sites waar zoekverkeer belangrijk is: houd Core Web Vitals uit CrUX en een dagelijkse labtest in de gaten, zodat je een trage release opmerkt voordat die in je posities zichtbaar wordt.

Groot of internationaal publiek, complexe front-ends: voeg RUM toe om prestaties en JavaScript-fouten per land, apparaat en pagina te zien.

Hoe ze samenwerken

Neem een webshop die op dinsdagmiddag een nieuwe checkout uitrolt. Woensdag om 03:12 begint de betaalstap te time-outen. Niemand is aan het winkelen, dus RUM toont niets bijzonders, maar de synthetische checkoutflow faalt, een tweede check bevestigt het en de developer van dienst krijgt een alert. Om 03:30 is het opgelost. Op donderdag laat RUM zien dat Interaction to Next Paint op de nieuwe checkout is verdubbeld voor Android-bezoekers, iets wat geen synthetische check vanaf een snelle server had opgemerkt. De ene tool ving de storing op, de andere de trage ervaring. Dat is de gebruikelijke taakverdeling.

Wat Uptimecheck wel en niet dekt

Uptimecheck is een dienst voor synthetische monitoring. Het voegt geen RUM-script aan je pagina’s toe, dus voor de timings en JavaScript-fouten van je eigen bezoekers gebruik je er een aparte RUM-tool naast. Wat het wel doet:

Uptime monitoring: HTTP(S)-, ping- en poortchecks tot elke minuut vanuit Stockholm, Londen en New York, met controles op keywords, JSON en headers, en elke storing wordt vanaf een tweede locatie bevestigd voordat er een alert volgt. Responstijden worden uitgesplitst in DNS, connect, TLS, server en download.

Flowmonitoring: tot 10 stappen, zoals een pagina openen, inloggen, een formulier versturen of een API aanroepen, waarbij waarden van de ene stap naar de volgende worden meegenomen. Flows met gewone verzoeken kunnen elke minuut draaien; flows in een echte browser voeren JavaScript en klikken uit, hooguit elke 15 minuten, met een screenshot van de stap die mislukte.

Monitoring van paginasnelheid: een dagelijkse Lighthouse-test op mobiel en desktop voor de startpagina en tot 4 andere pagina’s, en voor pagina’s en sites met genoeg bezoeken wat echte Chrome-gebruikers over 28 dagen hebben ervaren, uit het Chrome UX Report. Je krijgt een alert wanneer de score van een pagina onder je grens zakt.

Wil je een traject instellen, lees dan hoe je een login of checkout monitort met een flow en hoe je de paginasnelheid controleert. Abonnementen beginnen bij € 9 per maand bij jaarlijkse betaling of € 12 bij maandelijkse betaling, excl. btw; zie de prijspagina.

Weet dat er iets kapot is voordat je bezoekers het je vertellen. Probeer Uptimecheck 14 dagen gratis, zonder creditcard.

Vragen

Wat is het verschil tussen synthetische monitoring en real user monitoring?

Synthetische monitoring test een site met gescripte verzoeken volgens een schema, vanaf bekende locaties. Real user monitoring verzamelt timings en fouten uit de browsers van echte bezoekers via een script in de pagina.

Heb ik zowel synthetische monitoring als RUM nodig?

De meeste sites beginnen met synthetische checks, omdat die je waarschuwen voor storingen en kapotte trajecten. Voeg RUM toe wanneer je wilt weten hoe snel de site is voor echte bezoekers op hun eigen apparaten en netwerken.

Kan real user monitoring downtime detecteren?

Niet betrouwbaar. Ligt de site eruit, dan kan het script niet laden en stopt de data gewoon. Gebruik uptime checks om gewaarschuwd te worden.

Biedt Uptimecheck real user monitoring?

Nee. Uptimecheck voert synthetische checks uit: uptime checks, flows in meerdere stappen en dagelijkse Lighthouse-tests. Monitors voor paginasnelheid tonen ook de Core Web Vitals van echte Chrome-gebruikers uit het Chrome UX Report van Google, wanneer een pagina of site genoeg verkeer heeft.

Lees verder

Monitoring 7 min. leestijd

Wat is een goede responstijd voor een website?

Responstijd is hoe lang je server nodig heeft om een verzoek te beantwoorden, niet hoe lang de pagina laadt. Wat goed is, waarom monitors en browsers anders meten en wat sites vertraagt.

Lezen

Guides 5 min. leestijd

429 Too Many Requests: rate limits, Retry-After en backoff

Een 429 betekent dat een client te veel verzoeken in te korte tijd heeft gestuurd. Hoe rate limits werken, wat Retry-After zegt, hoe je terugschakelt en waarom een uptime monitor er een kan krijgen.

Lezen

Guides 5 min. leestijd

403 Forbidden-fout: wat betekent het en hoe los je het op?

Een 403 betekent dat de server het verzoek begreep en het weigerde. De gebruikelijke oorzaken, wat bezoekers kunnen proberen, hoe site-eigenaren de blokkerende regel vinden en waarom monitors 403’s krijgen die browsers niet zien.

Lezen

Downtime is verleden tijd.

Stel je eerste monitor in binnen een minuut, of kijk eerst rond in de live demo.

14 dagen gratis proberen · Daarna gratis met 5 monitors · Geen creditcard