Syntetisk övervakning testar din webbplats eller ditt API med skriptade förfrågningar enligt ett schema, oavsett om någon besöker den eller inte. Real user monitoring (RUM) mäter vad riktiga besökare upplever, med ett skript i deras webbläsare, men bara när de besöker sidan. Syntetiska kontroller talar om att något är trasigt, ofta innan kunderna märker det. RUM talar om hur snabb och smidig webbplatsen är för dem som använder den, på deras enheter och nätverk. Börja med syntetiska kontroller för tillgänglighet, och lägg till RUM när prestandan för riktiga besökare blir en fråga du behöver svar på.
Så fungerar syntetisk övervakning
En övervakningstjänst spelar besökare. Från en känd plats, enligt ett fast schema, skickar den en förfrågan eller kör ett skript och bedömer resultatet. Eftersom den gör samma sak varje gång går resultaten att jämföra från en kontroll till nästa, och ett fel klockan 03:00 upptäcks klockan 03:00, utan att det behövs någon trafik. Syntetisk övervakning finns i flera former:
Upptidskontroller: en förfrågan till en URL, värd eller port, där statuskoden, svarstiden och ofta innehållet kontrolleras. Det här är den enklaste formen; läs vad upptidsövervakning är.
API-kontroller: en förfrågan med metod, huvuden och body, och kontroller av den JSON som kommer tillbaka.
Flöden i flera steg: en kundresa som inloggning eller utcheckning, körd steg för steg, som vanliga HTTP-förfrågningar eller i en riktig webbläsare som kör JavaScript.
Prestandatester i labbmiljö: ett verktyg som Lighthouse laddar en sida på en simulerad enhet och ett simulerat nätverk och ger den ett betyg.
Så fungerar real user monitoring
Real user monitoring lägger till ett skript på dina sidor. I varje besökares webbläsare läser det av tider som webbläsare exponerar via standardiserade API:er, till exempel Navigation Timing, och skickar dem till en insamlingstjänst. Sammanställt över alla besök får du fördelningar: hur lång tid sidor tar att ladda, hur snabbt de reagerar på klick och vilka sidor som ger JavaScript-fel, uppdelat på land, enhet och webbläsare.
Eftersom resultaten är fördelningar rapporterar RUM percentiler snarare än enskilda värden. Googles Core Web Vitals mäts vid den 75:e percentilen av sidladdningarna, med de här gränserna för en bra upplevelse:
Largest Contentful Paint (laddning): 2,5 sekunder eller mindre.
Interaction to Next Paint (responsivitet): 200 millisekunder eller mindre.
Cumulative Layout Shift (visuell stabilitet): 0,1 eller mindre.
Det finns också RUM-data som du inte samlar in själv. Googles Chrome UX Report (CrUX) publicerar fältdata från Chrome-användare som tillåter det, per sida och per webbplats, när det finns tillräckligt med trafik. Det är de data som Google använder för Core Web Vitals i sökresultaten.
Sida vid sida
Syntetisk övervakningReal user monitoringVem som skapar datanEn övervakningstjänst, enligt schemaDina besökare, när de besöker sidanKräver trafikNejJaKräver ett skript på dina sidorNejJaUpptäcker ett avbrottJa, vid nästa kontrollIndirekt, när datan uteblirTäckerDe sidor och kundresor du skriptarAlla sidor som besöksEnheter och nätverkNågra få kändaAlla dina besökaresResultatGodkänt eller underkänt, en tid per kontrollFördelningar och percentilerBäst förTillgänglighet, larm, att fånga regressioner efter driftsättningarVerklig prestanda, Core Web Vitals, fel i webbläsaren
Vad var och en missar
Syntetiska blinda fläckar
Vägar du inte har skriptat. Om kassaflödet testar en produkt går en trasig sida för en annan kategori obemärkt förbi.
Var dina besökare finns. En kontroll från en stad ser den stadens väg till din server, inte vägen för en besökare på ett mobilnät på en annan kontinent.
Riktiga enheter. En långsam telefon, ett webbläsartillägg eller en gammal webbläsarversion kan förstöra eller sakta ner en sida som klarar varje kontroll.
RUM:s blinda fläckar
Inga besökare, inga data. På natten, på en ny sida eller på en webbplats med lite trafik har RUM lite eller inget att säga.
Avbrott. När webbplatsen ligger nere laddas skriptet aldrig, så ingenting rapporteras. En lucka i ett diagram är lätt att missa och väcker ingen.
Besökare du inte kan mäta. Annonsblockerare och samtyckesval kan stoppa skriptet, så datan beskriver de besökare som tillåter det.
Vikt. Skriptet i sig är extra arbete för sidan. Ladda det asynkront och håll koll på storleken.
Labbdata kontra fältdata
Samma uppdelning finns i prestandaverktygen, där den kallas labbdata och fältdata. Ett Lighthouse-betyg är labbdata: en syntetisk sidladdning på en simulerad mellanklasstelefon och ett simulerat nätverk. CrUX och din egen RUM är fältdata: vad riktiga besök har uppmätt. De går ofta isär. En sida kan få ett dåligt betyg i labbet och ändå klara Core Web Vitals i fält eftersom de flesta besökare har snabba enheter, eller tvärtom. Använd labbdata för att hitta och åtgärda problem och för att jämföra en release med nästa, och fältdata för att bedöma vad besökarna faktiskt får. Tipsen för en snabbare webbplats hjälper med båda, och vad som är en bra svarstid handlar om serversidan.
Vilken du ska börja med
Alla webbplatser: syntetiska upptidskontroller på startsidan och de sidor som drar in pengar. Ett avbrott kostar mer än en långsam sida, och bara syntetiska kontroller larmar dig om det på ett pålitligt sätt. Checklistan över vad du ska övervaka listar de adresser som är värda att täcka.
Butiker och SaaS-produkter: lägg till flöden i flera steg för utcheckning eller inloggning, så att en trasig kundresa fångas även när varje enskild sida svarar 200.
Webbplatser där söktrafiken spelar roll: håll koll på Core Web Vitals från CrUX och ett dagligt labbtest, så att en långsam release upptäcks innan den syns i rankningen.
Stora eller globala målgrupper och komplexa frontends: lägg till RUM för att se prestanda och JavaScript-fel per land, enhet och sida.
Så samverkar de
Tänk dig en butik som driftsätter en ny kassa på tisdagseftermiddagen. Klockan 03:12 på onsdagen börjar betalsteget få timeout. Ingen handlar, så RUM visar inget ovanligt, men det syntetiska kassaflödet misslyckas, en andra kontroll bekräftar det och utvecklaren i beredskap får ett larm. Åtgärdat till 03:30. På torsdagen visar RUM att Interaction to Next Paint i den nya kassan har fördubblats för Android-besökare, något som ingen syntetisk kontroll från en snabb server hade märkt. Det ena verktyget fångade avbrottet, det andra den långsamma upplevelsen. Så brukar arbetet fördelas.
Vad Uptimecheck täcker, och vad det inte gör
Uptimecheck är en tjänst för syntetisk övervakning. Den lägger inte till något RUM-skript på dina sidor, så för dina egna besökares tider och JavaScript-fel behöver du ett dedikerat RUM-verktyg vid sidan av. Det här gör den:
Upptidsövervakning: HTTP(S)-, ping- och portkontroller så ofta som varje minut från Stockholm, London och New York, med kontroller av nyckelord, JSON och huvuden, och varje fel bekräftat från en andra plats innan ett larm skickas. Svarstiderna delas upp i DNS, anslutning, TLS, server och nedladdning.
Flödesövervakning: upp till 10 steg som att öppna en sida, logga in, skicka ett formulär eller anropa ett API, med värden som förs vidare från ett steg till nästa. Flöden med vanliga förfrågningar kan köras varje minut; flöden i en riktig webbläsare kör JavaScript och klick högst var 15:e minut, med en skärmdump av steget som misslyckades.
Övervakning av sidhastighet: ett dagligt Lighthouse-test för mobil och dator på startsidan och upp till 4 sidor till, och, för sidor och webbplatser med tillräckligt många besök, vad riktiga Chrome-användare upplevde under 28 dagar enligt Chrome UX Report. Du får ett larm när en sidas betyg sjunker under din gräns.
För att sätta upp en kundresa, läs hur du övervakar en inloggning eller kassa med ett flöde och hur du kontrollerar sidhastigheten. Planerna börjar på 9 € i månaden vid årsbetalning eller 12 € vid månadsbetalning, exkl. moms; se prissidan.
Få veta att något är trasigt innan dina besökare berättar det. Prova Uptimecheck gratis i 14 dagar, inget kreditkort krävs.