Syntetisk overvåking tester nettstedet eller API-et ditt med skriptede forespørsler etter en fast plan, enten noen besøker det eller ikke. Real user monitoring (RUM) måler det faktiske besøkende opplever, via et skript i nettleseren deres, men bare når de er innom. Syntetiske sjekker forteller deg at noe er ødelagt, ofte før kundene merker det. RUM forteller deg hvor raskt og smidig nettstedet er for dem som bruker det, på deres enheter og nettverk. Begynn med syntetiske sjekker for tilgjengelighet, og legg til RUM når ytelsen for ekte besøkende blir et spørsmål du trenger svar på.
Slik virker syntetisk overvåking
En overvåkingstjeneste spiller rollen som besøkende. Fra et kjent sted, etter en fast plan, sender den en forespørsel eller kjører et skript og vurderer resultatet. Fordi den gjør det samme hver gang, kan resultatene sammenlignes fra én sjekk til den neste, og en feil klokken 03:00 blir oppdaget klokken 03:00, helt uten trafikk. Syntetisk overvåking finnes i flere former:
Oppetidssjekker: én forespørsel til en URL, vert eller port, der statuskoden, responstiden og ofte innholdet sjekkes. Dette er den enkleste varianten; se hva oppetidsovervåking er.
API-sjekker: en forespørsel med metode, headere og body, og sjekker av JSON-en som kommer tilbake.
Flyter i flere trinn: en brukerreise, for eksempel innlogging eller kassen, kjørt trinn for trinn, som vanlige HTTP-forespørsler eller i en ekte nettleser som kjører JavaScript.
Ytelsestester i lab: et verktøy som Lighthouse laster en side på en simulert enhet og et simulert nettverk og gir den en poengsum.
Slik virker real user monitoring
Real user monitoring legger til et skript på sidene dine. I hver besøkendes nettleser leser det tidsmålinger som nettlesere gjør tilgjengelige gjennom standard-API-er, for eksempel Navigation Timing, og sender dem til en innsamler. Samlet over mange besøk får du fordelinger: hvor lang tid sidene bruker på å laste, hvor raskt de reagerer på klikk, hvilke sider som gir JavaScript-feil, fordelt på land, enhet og nettleser.
Fordi resultatene er fordelinger, rapporterer RUM persentiler i stedet for enkelttall. Googles Core Web Vitals måles ved 75-persentilen av sidelastinger, med disse grenseverdiene for en god opplevelse:
Largest Contentful Paint (lasting): 2,5 sekunder eller mindre.
Interaction to Next Paint (respons): 200 millisekunder eller mindre.
Cumulative Layout Shift (visuell stabilitet): 0,1 eller mindre.
Det finnes også RUM-data du ikke samler inn selv. Googles Chrome UX Report (CrUX) publiserer feltdata fra Chrome-brukere som tillater det, per side og per nettsted, så snart det er nok trafikk. Det er disse dataene Google bruker for Core Web Vitals i søk.
Side om side
Syntetisk overvåkingReal user monitoringHvem som skaper dataeneEn overvåkingstjeneste, etter en fast planDe besøkende, når de er innomTrenger trafikkNeiJaTrenger et skript på sideneNeiJaOppdager nedetidJa, ved neste sjekkIndirekte, når dataene stopperDekkerSidene og brukerreisene du skripterAlle sider folk besøkerEnheter og nettverkNoen få kjenteAlle de besøkendesResultaterBestått eller feilet, én tidsmåling per sjekkFordelinger og persentilerBest forTilgjengelighet, varsler, å fange opp regresjoner etter deployFaktisk ytelse, Core Web Vitals, feil i nettleseren
Hva hver av dem går glipp av
Blindsoner i syntetisk overvåking
Veier du ikke har skriptet. Hvis kasseflyten tester ett produkt, blir en ødelagt side for en annen kategori ikke oppdaget.
Hvor de besøkende befinner seg. En sjekk fra én by ser den byens rute til serveren din, ikke ruten til en besøkende på et mobilnett på et annet kontinent.
Ekte enheter. En treg telefon, en nettleserutvidelse eller en gammel nettleserversjon kan ødelegge eller forsinke en side som består alle sjekker.
Blindsoner i RUM
Ingen besøkende, ingen data. Om natten, på en ny side eller på et nettsted med lite trafikk har RUM lite eller ingenting å fortelle.
Nedetid. Når nettstedet er nede, lastes skriptet aldri, så ingenting blir rapportert. Et hull i en graf er lett å overse og vekker ingen.
Besøkende du ikke kan måle. Annonseblokkere og samtykkevalg kan stoppe skriptet, så dataene beskriver de besøkende som tillater det.
Vekt. Selve skriptet er ekstra arbeid for siden. Last det asynkront og sjekk størrelsen.
Labdata vs. feltdata
Det samme skillet dukker opp i ytelsesverktøy, der det kalles lab- og feltdata. En Lighthouse-poengsum er labdata: én syntetisk sidelasting på en simulert mellomklassetelefon og et simulert nettverk. CrUX og din egen RUM er feltdata: det ekte besøk har målt. De er ofte uenige. En side kan få dårlig poengsum i lab og likevel bestå Core Web Vitals i felt fordi de fleste besøkende har raske enheter, eller omvendt. Bruk labdata til å finne og rette problemer og til å sammenligne én release med den neste, og feltdata til å vurdere hva de besøkende faktisk får. Tipsene for et raskere nettsted hjelper med begge, og hva en god responstid er tar for seg serversiden.
Hvilken du bør begynne med
Alle nettsteder: syntetiske oppetidssjekker på forsiden og sidene som tjener penger. Nedetid koster mer enn en treg side, og bare syntetiske sjekker varsler deg pålitelig om den. Sjekklisten over hva du bør overvåke lister opp URL-ene som er verdt å dekke.
Nettbutikker og SaaS-produkter: legg til flyter i flere trinn for kassen eller innloggingen, slik at en ødelagt brukerreise blir fanget opp selv når hver enkelt side svarer 200.
Nettsteder der søketrafikk betyr noe: følg med på Core Web Vitals fra CrUX og en daglig labtest, slik at en treg release blir oppdaget før den slår ut i rangeringene.
Store eller globale målgrupper, komplekse frontender: legg til RUM for å se ytelse og JavaScript-feil per land, enhet og side.
Slik utfyller de hverandre
Tenk deg en nettbutikk som deployer en ny kasse tirsdag ettermiddag. Klokken 03:12 onsdag begynner betalingstrinnet å få tidsavbrudd. Ingen handler, så RUM viser ingenting uvanlig, men den syntetiske kasseflyten feiler, en ny sjekk bekrefter det, og utvikleren med vakt får et varsel. Løst innen 03:30. Torsdag viser RUM at Interaction to Next Paint i den nye kassen er doblet for Android-besøkende, noe ingen syntetisk sjekk fra en rask server ville ha merket. Ett verktøy fanget opp nedetiden, det andre den trege opplevelsen. Det er den vanlige arbeidsdelingen.
Hva Uptimecheck dekker, og hva den ikke dekker
Uptimecheck er en tjeneste for syntetisk overvåking. Den legger ikke til noe RUM-skript på sidene dine, så for tidsmålinger og JavaScript-feil fra dine egne besøkende bør du bruke et eget RUM-verktøy ved siden av. Dette gjør den:
Oppetidsovervåking: HTTP(S)-, ping- og portsjekker så ofte som hvert minutt fra Stockholm, London og New York, med sjekk av nøkkelord, JSON og headere, og hver feil bekreftet fra et annet sted før et varsel sendes. Responstidene deles opp i DNS, tilkobling, TLS, server og nedlasting.
Flytovervåking: opptil 10 trinn, for eksempel å åpne en side, logge inn, sende inn et skjema eller kalle et API, med verdier som føres videre fra ett trinn til det neste. Flyter med vanlige forespørsler kan kjøre hvert minutt; flyter i en ekte nettleser kjører JavaScript og klikk høyst hvert 15. minutt, med et skjermbilde av trinnet som feilet.
Overvåking av sidehastighet: en daglig Lighthouse-test på mobil og desktop for startsiden og opptil 4 sider til, og, for sider og nettsteder med nok besøk, hva ekte Chrome-brukere har opplevd de siste 28 dagene ifølge Chrome UX Report. Du får et varsel når poengsummen til en side faller under grensen din.
For å sette opp en brukerreise, se hvordan du overvåker en innlogging eller kasse med en flyt og hvordan du sjekker sidehastighet. Planene starter på 9 € i måneden ved årlig fakturering eller 12 € ved månedlig fakturering, ekskl. mva.; se prissiden.
Få vite at noe er ødelagt før de besøkende forteller deg det. Prøv Uptimecheck gratis i 14 dager, uten kredittkort.