Scopri i motivi per cui i dati RUM possono mostrare numeri di Core Web Vitals diversi da CrUX.
Data di pubblicazione: 15 agosto 2022, Ultimo aggiornamento: 17 dicembre 2025
Il Chrome User Experience Report (CrUX) fornisce metriche sull'esperienza utente relative al modo in cui gli utenti reali di Chrome trovano le destinazioni più frequenti sul web. Questi dati vengono raccolti automaticamente da Chrome dagli utenti che hanno attivato l'opzione e vengono resi disponibili in base ai criteri di idoneità di CrUX.
I dati di CrUX sono quindi disponibili per milioni di siti web. Molti proprietari di siti non avevano mai avuto accesso ai dati sul campo prima e CrUX ha consentito a molti siti di comprenderne il valore per la prima volta. In quanto set di dati pubblico, CrUX può essere utilizzato anche per l'analisi della concorrenza e il benchmarking delle metriche relative all'esperienza utente.
Il Real User Monitoring (RUM) è simile a CrUX, ma invece di Chrome che raccoglie automaticamente le metriche sull'esperienza utente, il codice è incluso nei siti web per eseguire questa raccolta e inviarla a un provider RUM o a una soluzione di analisi per un'ulteriore analisi.
Poiché entrambe le soluzioni misurano le metriche relative all'esperienza utente, è naturale presumere che debbano essere equivalenti. Le differenze possono creare confusione. Questa guida spiega perché può succedere e offre suggerimenti su cosa fare quando i numeri non corrispondono.
Vantaggi dell'integrazione di CrUX con una soluzione RUM
CrUX è un ottimo strumento per avere una visione coerente dei siti e, in quanto set di dati di Google per il programma Core Web Vitals, i siti probabilmente vorranno tenere d'occhio ciò che mostra. L'obiettivo di CrUX è fornire una panoramica statisticamente rilevante di milioni di siti web per un confronto incrociato.
Tuttavia, per un approfondimento sull'indagine del perché i dati mostrano i numeri che mostrano, investire in una soluzione RUM completa per integrare CrUX può darti accesso a informazioni più dettagliate di quelle che possono essere rese disponibili in un set di dati pubblicamente interrogabile. In questo modo, puoi spiegare e migliorare le tue metriche in diversi modi.
Analisi più approfondita per esaminare i problemi
CrUX può essere spesso utilizzato per segnalare se hai un problema sul tuo sito, ma non necessariamente dove si trova esattamente il problema sul tuo sito né perché. Le soluzioni RUM, siano esse sviluppate internamente tramite la libreria web-vitals o alcuni dei numerosi prodotti commerciali, possono aiutare a colmare questa lacuna.
L'utilizzo di una soluzione RUM ti consente di accedere a dati molto più granulari per tutte le tue pagine e su tutti i browser. Inoltre, ti consente di segmentare e analizzare questi dati in modi che CrUX non consente, permettendoti di eseguire il drill-down e di esaminare le aree problematiche del sito. Sono influenzati da un particolare segmento di utenti? O utenti che eseguono determinate azioni? Quando ha iniziato a verificarsi esattamente il problema? Queste sono domande a cui è molto più facile rispondere con i dati aggiuntivi che uno strumento RUM può fornire.
Correlazione con altre metriche aziendali
RUM ti consente anche di confrontare direttamente le metriche sul rendimento web con qualsiasi metrica aziendale, mostrando il valore dell'investimento nel rendimento e quali altre attività di rendimento dare la priorità. Abbiamo numerosi case study di aziende che hanno eseguito questa correlazione, come Farfetch o The Economic Times.
Raccogli altri dati sul rendimento
Una soluzione RUM consente di raccogliere altre metriche personalizzate, legate direttamente alla tua attività specifica. Uno degli esempi più noti è la metrica "Time to first Tweet" di Twitter. Queste misure specifiche del sito possono poi essere correlate ai miglioramenti di Core Web Vitals e alle metriche aziendali.
Differenze tra due insiemi di dati dei campi
Un uomo con un orologio sa che ora è. Un uomo con due orologi non ne è mai sicuro.
Legge di Segal
Quando hai due origini dati, può essere spesso fonte di confusione e frustrazione capire perché differiscono. Così come è importante comprendere la differenza tra le metriche di laboratorio e sul campo, possono esserci anche differenze tra due origini di dati sul campo. In un mondo ideale i dati sarebbero gli stessi, ma esistono molti motivi per cui possono differire.
Dati di laboratorio e dati reali
La prima cosa da verificare è se stai esaminando le metriche di laboratorio (sintetiche) o quelle sul campo (RUM). Sebbene sia naturale presumere che i prodotti RUM esaminino solo i dati dei campi, molti offrono anche un componente di laboratorio.
I dati di laboratorio sono incredibilmente utili proprio per le condizioni fisse in cui vengono misurati. Può essere utilizzato per monitorare modifiche o regressioni impreviste in un ambiente di produzione senza il rumore di una popolazione di campo in evoluzione. Tuttavia, i dati di laboratorio potrebbero non essere rappresentativi dell'esperienza utente reale, pertanto le metriche sul campo possono mostrare risultati molto diversi.
Abitanti
I set di dati utilizzati dalle soluzioni CrUX e RUM potrebbero essere diversi a causa delle differenze nelle visite alle pagine misurate a seconda dei browser, degli utenti, dei siti e dei dispositivi confrontati.
Browser inclusi
Il Chrome User Experience Report, come suggerisce il nome, è disponibile solo per Chrome. Sebbene esistano molti browser basati su Chromium (Edge, Opera e Brave, per citarne alcuni) che condividono gran parte del codebase di Chrome, solo gli utenti di Chrome inseriscono i dati in CrUX. Questa limitazione significa anche che gli utenti di Chrome su iOS non sono inclusi, poiché utilizzano il motore del browser Webkit sottostante. Anche le WebView di Android non vengono conteggiate come "Chrome", pertanto i dati di questi utenti non sono inclusi, anche se sono incluse le schede personalizzate di Chrome.
Sebbene Chrome sia uno dei browser più popolari al mondo e, di conseguenza, probabilmente fornirebbe una rappresentazione ampia delle prestazioni del tuo sito nella maggior parte dei casi, la misurazione di questo browser non è affatto una misura di tutti i tuoi utenti. Questo potrebbe spiegare una delle principali differenze tra RUM e CrUX. Questo è particolarmente vero per le tecniche di ottimizzazione delle prestazioni che si basano su API o formati dell'immagine disponibili solo in Chrome, ad esempio.
La mancanza di dati iOS può anche portare a bias. Ad esempio, poiché gli utenti iOS utilizzano in genere dispositivi più performanti o visitano i siti da più paesi con un'infrastruttura di rete migliore, la loro inclusione può portare a metriche sul rendimento complessivo elevate. D'altra parte, l'esclusione di questi utenti, come fa CrUX, può portare a dati distorti verso la fascia più bassa dei visitatori del sito (case study di esempio). Gli utenti Android in genere coprono una gamma più ampia di dispositivi, funzionalità dei dispositivi e mercati.
Le soluzioni RUM possono ottenere dati per browser diversi da Chrome, in particolare dai browser basati su Chromium che spesso hanno le stesse metriche (come Core Web Vitals) integrate. Anche i browser non basati su Chromium vengono misurati dalle soluzioni RUM, ma potrebbero avere un insieme di metriche più limitato. Ad esempio, Cumulative Layout Shift (CLS) è disponibile solo nei browser basati su Chromium. Alcune altre metriche basate sulla visualizzazione, come LCP, INP e persino First Contentful Paint (FCP), possono essere misurate in modo molto diverso (vedi di seguito).
Utenti che hanno eseguito l'attivazione
Oltre a essere limitato agli utenti di Chrome, CrUX è ulteriormente limitato dal fatto che misura solo un sottoinsieme di utenti di Chrome che hanno scelto di condividere i dati di CrUX al momento dell'installazione del browser.
Inoltre, i provider RUM esaminano solo un sottoinsieme di utenti, di solito a causa dei prompt dei banner dei cookie, che chiedono agli utenti di attivare la raccolta dei dati RUM, o dei tracker blocker. Ciò può influire negativamente su alcuni caricamenti iniziali della pagina se la conferma non viene fornita fino alla seconda pagina o a quelle successive, quando alcuni asset del sito sono già stati memorizzati nella cache dalle pagine precedenti. Se ciò accade di frequente, le metriche potrebbero apparire più favorevoli in RUM di quanto non siano in realtà se i caricamenti iniziali delle pagine più lenti vengono esclusi in un numero sufficiente di casi.
Siti inclusi
CrUX è destinato solo a generare report sui siti web pubblici, pertanto esistono altri criteri di idoneità che potrebbero impedire la registrazione dei dati in CrUX. Il più importante di questi criteri è che il sito web deve essere rilevabile pubblicamente e sufficientemente popolare da garantire una dimensione minima del campione da cui trarre conclusioni significative. Nella maggior parte dei casi, ciò comporterà la mancata disponibilità di dati in CrUX. Questa differenza è meno confusa rispetto alla disponibilità di dati diversi, ma spiega perché ciò accade.
Tuttavia, se pagine specifiche di un sito sono contrassegnate come indicizzabili, ma altre no, potresti visualizzare solo un sottoinsieme di URL in CrUX. Se l'origine è rilevabile pubblicamente, tutte le visualizzazioni di pagina al suo interno verranno incluse nei dati a livello di origine, ma i dati a livello di URL potrebbero non essere disponibili.
Dispositivi
CrUX segmenta i dati in base a dispositivi mobili, computer e tablet, anche se molti strumenti si concentrano sui primi due e potrebbero non mostrare i dati dei tablet o includerli nei dispositivi mobili o nei computer. Le caratteristiche di rendimento su dispositivi mobili e computer possono essere molto diverse, sia in termini di importazione dei contenuti sia di funzionalità dei dispositivi che li visualizzano.
I dati RUM consentono di segmentare il traffico in modo simile, ma spesso mostrano dati consolidati per impostazione predefinita. Il RUM potrebbe consentire la segmentazione solo per tipo di dispositivo (ad esempio, dispositivo mobile) o browser (ad esempio, Chrome), ma non per entrambi, per visualizzare solo il traffico di Chrome su dispositivi mobili. Quando esegui il confronto con i dati di CrUX, assicurati di confrontare elementi simili filtrando per tipo di dispositivo e browser Chrome.
Campionamento
Le soluzioni RUM in genere consentono di regolare la frequenza di campionamento dei visitatori che hanno eseguito l'opt-in per la raccolta dei dati. Questo può essere utilizzato per ridurre il volume di dati da analizzare e i costi dei servizi RUM commerciali. Se la dimensione del campione è troppo piccola e non è rappresentativa della popolazione più ampia, anche le metriche risultanti saranno distorte in modo simile. Discuti con il tuo provider RUM le dimensioni di campionamento appropriate per il tuo sito.
Aggregazione dei dati
I dati dei campi, per loro stessa natura, includono molti, molti punti dati delle stesse metriche rispetto ai dati di laboratorio, che forniscono un singolo valore. Se questi dati vengono aggregati in modo diverso per i report, può verificarsi un'altra causa di differenze tra CrUX e RUM.
Periodo di tempo
I dati di CrUX si basano su una finestra temporale mobile di 28 giorni del traffico e non è possibile modificare questo periodo di tempo, anche se i dati di CrUX BigQuery vengono archiviati per ogni mese, consentendoti di visualizzare i mesi precedenti, e l'API CrUX History fornisce anche dati storici su un periodo settimanale. Entrambi forniscono comunque dati basati sulla finestra temporale mobile di 28 giorni.
I dati RUM in genere consentono una granularità molto maggiore per vedere l'impatto delle modifiche molto prima. Tuttavia, se scegli periodi più brevi, i dati RUM possono essere influenzati indebitamente dalle fluttuazioni del traffico e dei visitatori del sito web. Quando confronti i dati RUM con quelli di CrUX, assicurati sempre di esaminare il rendimento nell'arco di 28 giorni. Una volta che hai la certezza che i dati sono simili, puoi esaminare altri intervalli di tempo per analizzare i dati RUM.
Aggregazione delle statistiche
Le metriche CrUX vengono misurate al 75° percentile, ovvero osservando il valore raggiunto dal 75% delle visualizzazioni di pagina. I dati dei campi presenteranno valori estremi e la rimozione del 25% delle esperienze peggiori ha lo scopo di fornire un valore che la maggior parte dei visitatori può ragionevolmente aspettarsi di ottenere.
I prodotti RUM spesso offrono un numero maggiore di opzioni per aggregare le metriche, tra cui il 75° percentile, la mediana e altri percentili. Se confronti i valori RUM con i dati CrUX, è necessario assicurarti di esaminare i dati del 75° percentile per confrontare elementi simili.
I dati dell'istogramma in CrUX includono tutti i dati disponibili, non solo il 75° percentile, e mostrano il numero di visualizzazioni di pagina in ogni valutazione, ma il punteggio aggregato si baserà sul 75° percentile. Questi dati CrUX vengono visualizzati in strumenti come PageSpeed Insights:
Differenze nelle metriche
Esistono molte metriche utilizzate per misurare le prestazioni web, quindi quando confronti due diversi set di dati, è importante capire quali metriche vengono misurate e come vengono utilizzate.
Metriche misurate
I dati CrUX sono il set di dati di Google dell'iniziativa Core Web Vitals e misurano principalmente queste metriche (LCP, CLS e INP), con alcune metriche aggiuntive a integrazione di queste.
Gli strumenti RUM di solito includono questi Core Web Vitals, ma spesso anche molte altre metriche. Alcuni provider RUM misurano anche l'esperienza utente utilizzando la propria combinazione di tutte queste metriche, ad esempio per fornire un "indice di soddisfazione" o simili. Quando confronti i dati RUM con quelli di CrUX, assicurati di confrontare elementi simili.
Gli strumenti che valutano lo stato di superamento o meno dei Core Web Vitals dovrebbero considerare una pagina come superata se soddisfa i target consigliati al 75° percentile per tutti i Core Web Vitals. Se INP non è presente per le pagine senza interazioni, devono essere superati solo LCP e CLS.
Differenze delle metriche tra i browser
CrUX misura solo nei browser Chrome. Puoi consultare i changelog di Web Vitals per vedere come cambiano con ogni versione di Chrome.
Le soluzioni RUM, invece, misurano i dati da una gamma più ampia di browser. I browser basati su Chromium (Edge, Opera e così via) saranno probabilmente simili a Chrome, a meno che Chrome non stia implementando nuove modifiche, come indicato nel log delle modifiche.
Per i browser non basati su Chromium, le differenze possono essere più marcate. Ad esempio, le metriche basate sulla visualizzazione come LCP, INP e FCP sono disponibili in Safari e Firefox, ma vengono misurate in modo diverso. Ciò può comportare variazioni significative nei tempi registrati. Come indicato in precedenza, se vuoi confrontare RUM con CrUX, è meglio filtrare solo gli utenti di Chrome per consentire un confronto simile.
Tempistiche delle metriche
Le metriche di Core Web Vitals sono fornite dalle API dei browser web, ma ciò non significa che non possano esserci differenze nei valori riportati utilizzando queste API. Il momento esatto in cui viene eseguita la misurazione della metrica, ovvero al caricamento della pagina o durante l'intero ciclo di vita della pagina, può portare a differenze. Gli strumenti RUM potrebbero non misurare sempre le metriche nello stesso modo, anche se utilizzano gli stessi nomi e le stesse API del browser per ottenere i dati, il che può creare confusione.
Largest Contentful Paint (LCP) è una metrica di caricamento pagina. L'API web può segnalare un numero di elementi LCP se gli elementi più grandi vengono caricati in un secondo momento dopo il rendering iniziale. L'elemento LCP finale è quello che si verifica quando la pagina termina il caricamento o l'utente interagisce con la pagina. Pertanto, possono verificarsi differenze se l'elemento LCP viene segnalato prima di questi due eventi.
Inoltre, nei dati dei campi, l'elemento LCP può essere diverso a seconda di come viene caricata la pagina. Per un caricamento pagina predefinito che mostra la parte superiore dei contenuti della pagina, l'elemento LCP dipenderà principalmente dalle dimensioni dello schermo. Tuttavia, se la pagina viene aperta con un link di ancoraggio più in basso nel documento o con un deep link in un'app a pagina singola (SPA), di cui parleremo più avanti, l'elemento LCP può essere diverso.
Non dare per scontato che le tempistiche LCP fornite in CrUX o RUM siano basate sullo stesso elemento degli strumenti di laboratorio. Mentre CrUX ti fornirà il valore LCP complessivo per pagina o origine, RUM può segmentarlo ulteriormente per identificare le singole sessioni con problemi di LCP.
La metrica Cumulative Layout Shift (CLS) viene misurata durante l'intera durata della pagina, pertanto il CLS del caricamento pagina iniziale potrebbe non essere rappresentativo delle pagine che causano variazioni maggiori in un secondo momento, dopo il caricamento della pagina e l'interazione dell'utente con la pagina. Se il valore CLS viene rilevato solo dopo il caricamento della pagina, come fanno molti prodotti RUM, il risultato sarà diverso rispetto a quello ottenuto dopo che l'utente ha terminato di utilizzare la pagina.
La metrica di reattività Interaction to Next Paint (INP) richiede la misurazione di un input e osserva tutte le interazioni di clic, tocco e tastiera durante l'intero ciclo di vita della pagina, in modo simile a CLS, pertanto il valore riportato di INP potrebbe essere molto diverso se misurato dopo che l'utente ha effettuato una serie di interazioni sulla pagina.
CrUX seguirà la documentazione di Core Web Vitals e misurerà queste metriche per l'intera durata della pagina. Per vari motivi, molti provider RUM scelgono invece di misurare queste metriche dopo il caricamento pagina o in un altro momento (ad esempio, quando viene fatto clic su un invito all'azione chiave).
Quando si riscontrano variazioni inspiegabili tra le due origini dati, è importante capire dal tuo fornitore di RUM quando vengono misurati i Core Web Vitals.
Applicazioni a pagina singola
Le applicazioni a pagina singola (SPA) funzionano aggiornando i contenuti della pagina corrente, anziché eseguire la navigazione nelle pagine effettiva a livello di browser. Ciò significa che il browser non le considera come navigazioni nelle pagine, anche se gli utenti le percepiscono come tali. Le API Core Web Vitals fornite dal browser non ne tengono conto, pertanto CrUX non supporta queste navigazioni nelle pagine. Stiamo lavorando per risolvere questo problema. Per saperne di più, consulta il post Misurazione delle navigazioni soft.
Alcuni fornitori di RUM tentano di rilevare le "navigazioni soft" nelle SPA, ma se attribuiscono anche le metriche di Core Web Vitals a queste "navigazioni soft", si verificheranno differenze con CrUX, poiché le API sottostanti non supportano questa funzionalità per molte delle metriche.
Differenze tra CrUX e API Web
Oltre alle differenze relative a quali visualizzazioni di pagina vengono misurate e a cosa viene misurato, esistono altri scenari più complessi di cui tenere conto che possono portare a differenze nei dati di CrUX e RUM. Alcune sono dovute alle limitazioni delle API web utilizzate per misurare le metriche, mentre altre riguardano i casi in cui i risultati restituiti dall'API devono essere trattati in modo diverso per determinati scenari. La documentazione di Core Web Vitals elenca queste differenze per LCP e CLS, ma le differenze principali sono indicate anche nelle sezioni seguenti.
Cache back-forward
CrUX considera i ripristini della cache back-forward (o bfcache) come navigazioni nelle pagine, anche se non comportano un caricamento pagina convenzionale. Poiché le API web non li considerano come un caricamento pagina, le soluzioni RUM devono eseguire passaggi aggiuntivi per conteggiare queste pagine se vogliono corrispondere a CrUX. Si tratta di caricamenti pagina notevolmente più rapidi che possono comportare la segnalazione di un rendimento complessivo migliore per un sito, pertanto la loro esclusione può comportare metriche sul rendimento della pagina complessivo peggiori. Consulta la tua soluzione RUM per capire se gestisce le pagine ripristinate dalla bfcache.
Iframe
Per motivi di sicurezza e privacy, le pagine di primo livello non hanno accesso ai contenuti all'interno degli iframe (nemmeno agli iframe con stessa origine). Ciò significa che le metriche sul rendimento dei contenuti al loro interno possono essere misurate solo dall'iframe stesso e non tramite le API web nella pagina di framing. Se i contenuti dell'iframe includono l'elemento LCP o contenuti che influiscono sul CLS o sull'INP riscontrati dall'utente, non saranno disponibili per le soluzioni RUM (inclusa la libreria JavaScript web-vitals di Google).
CrUX, invece, viene misurato dal browser Chrome stesso anziché da JavaScript sulla pagina, quindi non ha queste limitazioni e misura le metriche all'interno degli iframe quando genera report su Core Web Vitals. Questo riflette in modo più accurato l'esperienza dell'utente, ma può essere un altro motivo delle differenze per i siti che utilizzano iframe.
Un esempio concreto di come questo possa portare a differenze tra i dati LCP in CrUX e RUM sono gli elementi <video> incorporati. Il primo frame visualizzato di un elemento <video> con riproduzione automatica playsinline può essere considerato un candidato LCP, ma i contenuti incorporati per i servizi di streaming video più diffusi potrebbero inserire questi elementi in un <iframe>. CrUX può tenerne conto, in quanto può accedere ai contenuti <iframe>, mentre le soluzioni RUM non possono farlo.
Risorse multiorigine
I contenuti multimediali LCP pubblicati da altri domini potrebbero non fornire il tempo di rendering nell'API PerformanceObserver, a meno che non venga fornita l'intestazione Timing-Allow-Origin (TAO), a causa delle limitazioni di sicurezza del browser per ridurre gli attacchi di timing. In questo caso, viene utilizzato il tempo di caricamento della risorsa, ma questo potrebbe essere molto diverso dal momento in cui i contenuti sono stati effettivamente visualizzati.
Ciò può portare alla situazione apparentemente impossibile in cui l'LCP viene segnalato dalle API web come precedente all'FCP. Non è così, ma sembra che lo sia a causa di questa limitazione di sicurezza.
Il problema è stato risolto alla fine del 2024 e un tempo di rendering leggermente approssimativo è disponibile da Chrome 133 anche quando Timing-Allow-Origin non viene fornito.
Anche in questo caso, CrUX segnala i dati sul tempo di rendering per Core Web Vitals. Consigliamo ai siti di limitare i contenuti multiorigine che influiscono sulle metriche di Core Web Vitals e di attivare l'intestazione TAO, se possibile, per misurare queste metriche in modo più accurato. Altre risorse multiorigine potrebbero essere soggette a limitazioni simili.
Schede in background
Quando una pagina non viene aperta in una scheda in background, continuerà a emettere metriche utilizzando le API web. Tuttavia, questi non vengono registrati da CrUX perché forniscono tempi non coerenti con l'esperienza utente. Le soluzioni RUM dovrebbero anche considerare di ignorare queste visualizzazioni di pagina o almeno spiegare come vengono trattate.
Cosa possiamo fare?
Abbiamo mostrato perché potrebbero esserci differenze tra i dati di CrUX e RUM, dovute a differenze nella metodologia utilizzata da ciascuno o agli utenti e alle visualizzazioni di pagina inclusi o esclusi. Idealmente, entrambi i set di dati saranno comunque rappresentativi del rendimento del tuo sito per essere utili, ma i motivi indicati dovrebbero spiegare perché è molto improbabile ottenere gli stessi numeri in ciascuno.
Se le differenze sono minime (ad esempio, un LCP di 2,0 secondi rispetto a 2,2 secondi), entrambi i set di dati saranno utili e in genere possono essere considerati approssimativamente sincronizzati.
Quando differenze marcate ti fanno dubitare dell'accuratezza dei dati, devi cercare di comprenderle. I dati RUM possono essere filtrati per essere più in linea con CrUX (esaminando solo gli utenti di Chrome, per computer o dispositivi mobili, con valori del 75° percentile nell'arco di 28 giorni) per ridurre queste differenze?
In questo caso, e se riesci a far corrispondere i dati in modo più preciso, dovresti comunque chiederti perché vedi queste differenze nei dati complessivi e cosa significano. Gli utenti che non utilizzano Chrome stanno alterando le tue metriche in modo positivo o negativo? Questo ti fornisce maggiori informazioni su dove si trovano i problemi di prestazioni a cui puoi dare la priorità?
Se gli utenti che non utilizzano Chrome ottengono risultati diversi, puoi utilizzare questo prezioso insight fornito da RUM per ottimizzare in modo diverso. Ad esempio, alcune API non sono disponibili su determinati browser, ma puoi prendere in considerazione alternative per i browser non supportati per migliorare anche le loro esperienze. In alternativa, puoi offrire un'esperienza diversa, ma più efficiente, agli utenti su dispositivi o reti con limitazioni. CrUX è limitato ai dati di Chrome, ma dovresti considerare le esperienze di tutti i visitatori del tuo sito per dare la priorità ai miglioramenti. I dati RUM possono colmare questa lacuna.
Una volta comprese le ragioni di eventuali differenze, entrambi gli strumenti possono essere incredibilmente utili per comprendere le esperienze utente del tuo sito web e contribuire a migliorarle, anche se i numeri non sono identici. Utilizza i dati RUM per integrare i dati CrUX e approfondire ciò che CrUX ti dice a livello generale segmentando il traffico per identificare se sono aree particolari del tuo sito o della tua base utenti che richiedono attenzione.
Spesso, osservare le tendenze per verificare che i miglioramenti abbiano gli impatti positivi previsti è più importante che far corrispondere esattamente ogni numero tra le due origini dati. Come accennato in precedenza, RUM ti consente di esaminare diversi intervalli di tempo per avere un'anteprima dei punteggi CrUX di 28 giorni, anche se l'esame di intervalli di tempo troppo brevi può portare a dati rumorosi, motivo per cui CrUX utilizza 28 giorni.
Spesso non esiste una risposta "giusta" o "sbagliata" per queste diverse metriche: sono solo un modo diverso di osservare i tuoi utenti e la loro esperienza sul tuo sito. La cosa più importante per offrire un servizio migliore ai visitatori del tuo sito è comprendere il motivo di queste differenze e l'impatto che possono avere sul tuo processo decisionale.