Sintetico e monitoraggio utenti reali: cosa individua ciascuno
Il monitoraggio sintetico esegue controlli scriptati secondo una pianificazione da ubicazioni che scegli tu; il monitoraggio degli utenti reali registra i tempi dai browser delle persone che visitano il tuo sito. Il sintetico ti dice se il sito funziona, il monitoraggio degli utenti reali ti dice come è stato percepito da chi c'era davvero.
Cosa fa ciascuno
Il monitoraggio sintetico, chiamato a volte monitoraggio attivo o proattivo, invia una richiesta che hai definito tu da una macchina che controlli, a un intervallo che imposti tu. Quella richiesta può essere piccola come una GET HTTP oppure grande come una sessione browser scriptata che effettua l'accesso, aggiunge un articolo al carrello e completa l'acquisto. Ogni esecuzione produce un risultato, che qualcuno abbia visitato il sito o no.
Il monitoraggio degli utenti reali, di solito abbreviato in RUM, è passivo. Uno script piccolo nelle tue pagine riporta cosa ha misurato il browser per quella visita: tempi di navigazione, caricamento delle risorse, errori e i Core Web Vitals così come li ha vissuti il visitatore. Produce dati solo in proporzione al tuo traffico, e non produce nulla quando non c'è nessuno.
Cosa individua il sintetico che il RUM non vede
- Interruzioni alle 4 del mattino, o su qualsiasi pagina con poco traffico. Se nessuno carica la pagina, il RUM non ha nulla da riportare, e un'interruzione totale è esattamente il caso in cui il beacon non può essere inviato
- Disponibilità da luoghi dove non hai ancora utenti, che è come scopri che un nuovo mercato non riesce a raggiungerti
- Una base di riferimento pulita. Lo stesso script, dalla stessa ubicazione, allo stesso intervallo, così che un cambiamento nel numero sia un cambiamento nel sito e non in chi ha visitato in quel momento
- Flussi multi-passaggio che non vorresti far eseguire a utenti reali, come un acquisto che creerebbe un ordine vero, oppure un accesso che puoi far girare su un account di prova
- Guasti di scadenza e di configurazione che non raggiungono mai un browser: certificati, record DNS, inserimenti in blacklist, porte aperte
- Il primo guasto dopo un deployment, prima che arrivi il traffico che lo avrebbe rivelato
Cosa individua il RUM che il sintetico non vede
- La distribuzione reale di dispositivi, reti e ubicazioni. Un controllo sintetico da una connessione di un data center non riprodurrà mai un telefono di fascia media su dati mobili
- Script di terze parti, banner per il consenso e personalizzazione che si caricano solo per sessioni reali con cookie reali
- Problemi che riguardano un sottoinsieme di utenti: una versione del browser, una regione, una variante A/B
- Quali pagine lente contano davvero, pesate in base a quante persone le vedono
- I Core Web Vitals sul campo, che è ciò che usano i motori di ricerca, a differenza dei valori da laboratorio prodotti da un'esecuzione sintetica
Quando servono entrambi
I due approcci rispondono a domande diverse, quindi la separazione è di solito netta. Usa il sintetico per tutto ciò per cui avviseresti qualcuno: disponibilità, tempo di risposta rispetto a una soglia, scadenza di certificati e domini, e i flussi critici che generano il tuo fatturato. Questi devono essere veri alle 4 del mattino con traffico zero, e hanno bisogno di una base di riferimento stabile su cui basare l'avviso.
Usa il RUM per decidere cosa correggere. Quando una pagina è lenta per alcune persone, il RUM ti dice quali persone e quante, che è l'informazione di cui ha bisogno un argomento di priorità e che un controllo sintetico non può fornire.
Una configurazione pratica è il sintetico che guida gli avvisi e il registro di uptime, il RUM che guida l'elenco delle prestazioni da migliorare. Se puoi eseguirne solo uno, esegui il sintetico: un'interruzione non monitorata costa più di una pagina lenta non misurata, e il RUM non può riportare nulla su una pagina che non è riuscita a caricarsi.
Dove si colloca il monitoraggio delle transazioni
Un controllo di transazione è il monitoraggio sintetico nella sua forma più dettagliata: uno script browser registrato che percorre passo dopo passo un vero percorso utente e fallisce sul passaggio che si è rotto, invece che sul sito nel suo insieme. Individua la classe di guasto che un semplice controllo di disponibilità segnala come funzionante, dove la home page restituisce 200 mentre il modulo di accesso dietro di essa è rotto.
Poiché è sintetico, gira secondo una pianificazione senza bisogno di traffico, e poiché fa girare un browser reale esercita il JavaScript, le dipendenze di terze parti e i reindirizzamenti che un semplice controllo HTTP salta. Il monitoraggio delle transazioni di HostTracker funziona così, e la guida al controllo di transazione copre come viene registrato uno script e cosa riporta ciascun passaggio.
Trasformare una misurazione in un avviso
Nessuno dei due approcci è utile finché qualcosa non agisce sul risultato. Un controllo sintetico vale la pena averlo perché gira che tu lo stia osservando o no, e perché un guasto può raggiungerti immediatamente: HostTracker esegue i suoi controlli da oltre 300 postazioni in 158 città su 13 tipi di monitor, e invia avvisi via email, SMS, chiamata vocale, Slack, Telegram e altro quando un risultato cambia. Abbina questo a qualunque RUM tu già raccolga e avrai entrambe le metà: un avviso quando il sito si rompe, e le prove di chi lo ha trovato lento. Il resto della sezione dei concetti di monitoraggio copre i termini su cui si basano questi due approcci.