In breve
Decidi quali percorsi osservare e quali informazioni minime servono a distinguere le esperienze. Controlla qualità del campione, distribuzione dei tempi e versione del sito. Usa le differenze per riprodurre i problemi, senza confondere una correlazione con una causa dimostrata.
- Partire dalle operazioni importanti per i clienti, oltre alla homepage.
- Raccogliere misure tecniche e contesto senza acquisire i contenuti dei moduli.
- Leggere distribuzioni e quantità dei campioni per gruppi confrontabili.
- Verificare le correzioni sui percorsi che mostravano il problema.
Definire una domanda prima di scegliere lo strumento
Scrivi il dubbio in modo verificabile: il calendario è lento sui telefoni, la ricerca peggiora nelle ore affollate oppure l’area clienti risponde male dopo l’accesso. La domanda determina pagine e operazioni da osservare. Installare uno strumento senza questa scelta può produrre molti grafici e poche decisioni.
Indica chi leggerà i risultati e quale intervento potrebbe derivarne. In un esempio ipotetico, un noleggio potrebbe voler distinguere l’apertura della scheda mezzo dal caricamento delle disponibilità. L’obiettivo non è registrare ogni gesto del visitatore: serve capire dove nasce l’attesa. Un campione piccolo ma progettato con un responsabile e una verifica periodica può essere più gestibile di un insieme di misure che nessuno riesce a interpretare.
Affiancare metriche di pagina e tempi delle operazioni
I Core Web Vitals descrivono aspetti dell’esperienza della pagina, ma non sostituiscono ogni misura del servizio. Per esempio, una buona risposta visiva a un clic non dimostra che un preventivo sia stato elaborato rapidamente. Se l’operazione continua sul server, serve osservarne anche l’esito.
Concorda inizio e fine delle misure personalizzate: dalla richiesta disponibilità alla comparsa di date utilizzabili, oppure dall’invio di una ricerca ai risultati pronti. Le funzioni User Timing consentono agli sviluppatori di definire marcatori e intervalli. Nomi e significato devono restare stabili tra versioni. Registra separatamente completamento, errore e interruzione: contare soltanto le operazioni riuscite può nascondere proprio le attese più problematiche.
Scegliere gruppi utili e dati essenziali
Per iniziare possono bastare modello di pagina, categoria di dispositivo, browser e versione del sito. Aggiungi un’informazione solo se aiuta una decisione: distinguere una scheda prodotto da un articolo è spesso più utile che conservare tutti gli indirizzi completi, con parametri variabili e difficili da interpretare.
Per il contesto di accesso può essere sufficiente un’indicazione generale, senza identificare la persona. Escludi testi digitati, email, numeri d’ordine, token e contenuti dell’area riservata. Fai definire con il responsabile del trattamento configurazione, conservazione e condizioni di attivazione dello strumento.
| Dato | Utilità |
|---|---|
| Tipo di pagina | Confrontare funzioni simili |
| Dispositivo | Isolare differenze di esperienza |
| Versione del sito | Collegare i dati agli aggiornamenti |
| Esito dell’operazione | Distinguere attesa, errore e riuscita |
Verificare che la raccolta rappresenti ciò che accade
Prima di leggere il cruscotto, prova che lo stesso evento non venga inviato più volte e che le misure arrivino anche nei percorsi previsti. Un cambiamento di pagina, una scheda chiusa o un servizio esterno possono rendere incompleta l’osservazione. Non trasformare i dati mancanti in tempi pari a zero.
Le indicazioni web.dev sulla misurazione sul campo raccomandano anche di evitare che il codice di monitoraggio rallenti il sito. Il tecnico dovrebbe verificare invio e carico delle risorse. Documenta ciò che resta fuori: blocchi del browser, condizioni di consenso, versioni non supportate e operazioni su domini esterni. Per i dettagli di rete, Resource Timing offre misure utili, ma alcune informazioni dipendono da permessi e origine della risorsa.
Leggere distribuzioni e campioni prima delle medie
Una media unica può nascondere una quota di visite molto lente. Guarda la distribuzione dei valori e i percentili, insieme al numero di osservazioni. Per i Core Web Vitals il riferimento di classificazione è il 75º percentile, come spiegato da web.dev. Altre misure del servizio richiedono obiettivi definiti sul compito, senza copiarne automaticamente le soglie.
Evita di spezzare subito il traffico in decine di gruppi minuscoli. Se un browser ha poche osservazioni, un episodio isolato può dominare il risultato. Confronta prima famiglie ampie e restringi l’analisi quando il campione lo consente. Conserva periodo, numero di eventi e copertura della raccolta: due valori senza queste informazioni possono sembrare comparabili pur descrivendo popolazioni molto diverse.
Trasformare una differenza in una prova tecnica
Il monitoraggio indica dove guardare; la causa va verificata. Se le visite da telefono mostrano un’attesa maggiore, riproduci lo stesso percorso con un dispositivo rappresentativo e controlla richieste, codice e servizi esterni. Non attribuire automaticamente il difetto alla rete mobile o alla potenza del telefono.
Prepara una scheda con operazione, gruppo interessato, periodo e ipotesi da testare. Un’associazione tra lentezza e abbandono non dimostra da sola che l’una causi l’altro: possono intervenire tipo di pubblico, disponibilità del prodotto o provenienza delle visite. Mantieni separati il controllo tecnico e la misurazione di richieste e contatti. Se il problema riguarda la reazione dei comandi, la guida all’INP aiuta a focalizzare l’indagine sulle interazioni.
Confrontare le versioni e mantenere un controllo utile
Annota quando è stata pubblicata la correzione e confronta periodi e gruppi il più possibile simili. Una promozione che porta molti nuovi visitatori può modificare il campione mentre viene rilasciato il miglioramento. Verifica quindi sia il dato complessivo sia il gruppo che aveva segnalato il difetto.
Conserva un controllo periodico con poche domande: quali percorsi peggiorano, quante persone riguardano e quale responsabile deve intervenire? Imposta segnalazioni su scostamenti sostenuti, accompagnate da un numero minimo di osservazioni concordato, evitando allarmi per ogni caso isolato. Il monitoraggio deve produrre una decisione o una verifica, non soltanto un report. Collega il processo alla prevenzione dei rallentamenti dopo gli aggiornamenti e rivedi le misure quando cambiano funzioni e percorsi del sito.
Domande frequenti
RUM significa registrare il video delle visite?
No. Il monitoraggio delle prestazioni può raccogliere tempi, metriche e informazioni tecniche senza registrare lo schermo o il contenuto dei campi. Le registrazioni di sessione sono una funzione distinta, da valutare separatamente.
Perché i dati non coincidono con PageSpeed Insights?
Possono cambiare popolazione, periodo, pagine, modalità di raccolta e metriche disponibili. Verifica che cosa rappresentano i due insiemi prima di confrontarli; non assumere che uno scarto dimostri un errore.
Ha senso monitorare un sito con poche visite?
Può essere utile sui percorsi importanti, ma i gruppi piccoli richiedono prudenza. Affianca misurazioni e segnalazioni a prove controllate, evitando conclusioni generali basate su pochissimi eventi.
Fonti e approfondimenti
Riferimenti ufficiali per verificare le indicazioni e applicarle al proprio sito.
- web.dev: buone pratiche per misurare le prestazioni sul campo (si apre in una nuova scheda)
- MDN: misure personalizzate con User Timing (si apre in una nuova scheda)
- MDN: dati sui tempi delle risorse e limiti disponibili (si apre in una nuova scheda)
- web.dev: soglie e percentili dei Core Web Vitals (si apre in una nuova scheda)