Chrome UX Report (CrUX): dati reali sui Core Web Vitals

TL;DR — CrUX è la raccolta di dati sulla velocità nel mondo reale di Google, basata su utenti Chrome reali. Sono i dati che Google usa per valutare i tuoi Core Web Vitals, non il punteggio di laboratorio che uno strumento come Lighthouse genera su una singola macchina di test. Ecco perché il punteggio Lighthouse può essere verde mentre Search Console segnala problemi: misurano cose diverse.

Che cos’è CrUX

Il Chrome User Experience Report — in breve CrUX — è un dataset gratuito pubblicato da Google che mostra come le persone reali, su dispositivi e reti reali, vivono i siti web. Invece di testare una pagina una volta in laboratorio, CrUX raccoglie misurazioni da grandi quantità di utenti Chrome reali e ne comunica il risultato.

Questi sono i cosiddetti dati sul campo (a volte: dati sugli utenti reali). Sono l’opposto dei dati di laboratorio, quelli che uno strumento come Lighthouse produce caricando la pagina una volta su una macchina di test controllata. Entrambi sono utili, ma solo uno dei due è ciò che Google guarda per valutare il tuo sito.

Perché è importante

CrUX è il dataset ufficiale alla base del programma Core Web Vitals. I sistemi di ranking di Google usano i Core Web Vitals misurati dai dati sul campo degli utenti reali, non un punteggio Lighthouse di laboratorio. Quindi, se guardi sempre e solo il tuo numero Lighthouse, potresti stare osservando la cosa sbagliata.

Hai già visto CrUX, anche se non lo sapevi. La sezione “Scopri l’esperienza dei tuoi utenti reali” in cima a PageSpeed Insights è CrUX. Anche il report Core Web Vitals di Search Console è CrUX. Sono questi i numeri che contano.

L’errore che commette la maggior parte delle persone

Un buon punteggio Lighthouse non significa che i tuoi Core Web Vitals siano buoni. Lighthouse esegue una sola prova, su un dispositivo simulato, con una rete rallentata e una cache vuota. I tuoi visitatori reali usano telefoni e laptop diversi, connessioni veloci e lente, vicine e lontane. CrUX cattura questo insieme disordinato; Lighthouse no. Una pagina può ottenere 95 in Lighthouse e mostrare comunque “Poor” in CrUX se la maggior parte degli utenti reali usa dispositivi mobili lenti.

Un’altra cosa sorprendente: non tutte le pagine sono presenti in CrUX. Un URL ha bisogno di un numero sufficiente di visite reali per essere incluso. Molte pagine con poco traffico non hanno alcun dato CrUX, quindi gli strumenti mostrano in alternativa i dati dell’intero sito (“origin”) oppure dicono semplicemente che non ci sono ancora dati sul campo.

Vuoi conoscere la metodologia — la finestra di 28 giorni, il 75° percentile, i dati a livello di origin rispetto a quelli a livello di URL e tutti i modi per recuperare i dati CrUX? Passa alla scheda Advanced.

TL;DR — CrUX è il Chrome User Experience Report ufficiale: dati UX sul campo del mondo reale, aggregati dagli utenti Chrome idonei — quelli che soddisfano i criteri di consenso, sincronizzazione e piattaforma supportata di Google — e il dataset alla base del programma Core Web Vitals. I dati sono riportati al 75° percentile su una finestra di aggregazione mobile di 28 giorni, sia a livello di origin sia di URL. La copertura è parziale: non comprende mai tutti gli utenti Chrome né tutti i visitatori, ma solo utenti Chrome idonei su piattaforme supportate (niente Chrome su iOS, Edge/Safari/Firefox), e una pagina deve avere un numero sufficiente di campioni per essere inclusa; perciò molti URL con poco traffico non hanno dati CrUX e gli strumenti ricadono sul livello origin o mostrano “no data”. Attualmente lo espongono sei superfici: PageSpeed Insights, Search Console, CrUX API (ogni giorno), History API (ogni settimana), BigQuery (ogni mese) e CrUX Vis — controlla la documentazione attuale, perché cadenze e quote possono cambiare. CrUX è sul campo; Lighthouse è in laboratorio: ecco perché i due risultati non coincidono.

CrUX è il livello dei dati sul campo dei Core Web Vitals

Google lo descrive chiaramente: “The Chrome User Experience Report … is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” E non è un progetto secondario: “CrUX is the Google dataset of the Web Vitals program. All user-centric Core Web Vitals metrics are represented.” I dati sono “used by Google Search to inform the page experience ranking factor.”

Quindi il modello mentale è questo: i Core Web Vitals sono le metriche; CrUX è il dataset in cui vivono. Quando la Ricerca valuta i tuoi CWV, legge CrUX. Questo singolo fatto risolve gran parte della confusione su questa pagina.

Come CrUX raccoglie i dati

CrUX è costruito sugli utenti Chrome reali, ma su un sottoinsieme specifico e idoneo: non tutti gli utenti Chrome e non tutti i visitatori del tuo sito. Le esperienze di un utente vengono aggregate solo se sono soddisfatti tutti e quattro i criteri: “Enable usage statistic reporting. Sync their browser history. Not have a Sync passphrase set. Use a supported platform.”

“Supported platform” fa molto lavoro. Sono incluse: Chrome desktop su Windows, macOS, ChromeOS e Linux, oltre a Chrome su Android (inclusi Custom Tabs e WebAPK). Sono escluse: Chrome su iOS, Android WebView e “other Chromium browsers.” In pratica, Microsoft Edge, Samsung Internet, Safari e Firefox non sono affatto inclusi in CrUX; e non lo è neppure alcun browser iOS, perché tutti usano WebKit.

Questo è il punto cieco da tenere a mente. Se gestisci un sito e-commerce o editoriale in cui la maggior parte del traffico arriva da iPhone/Safari, CrUX potrebbe misurare solo una minoranza del tuo pubblico reale. I dati non sono sbagliati: semplicemente non rappresentano tutti.

Perché alcune pagine non hanno dati CrUX

CrUX non copre ogni pagina, e questo trae in inganno molte persone. Google dice: “Not all origins or pages are represented in the dataset. There are separate eligibility criteria for origins and pages, primarily that they must be publicly discoverable and there must be a large enough number of visitors in order to create a statistically significant dataset.” La soglia esatta di popolarità non è dichiarata: considera non ufficiale qualsiasi numero specifico di visitatori che trovi citato, non una regola documentata.

L’idoneità di pagina e origin viene valutata separatamente. Un origin può avere abbastanza traffico idoneo per essere riportato anche quando molte singole pagine non lo hanno: è proprio per questo che un dominio può mostrare dati a livello di origin mentre un URL specifico ne è privo. E un risultato mancante non è un punteggio: significa solo che Google non dispone di un campione idoneo abbastanza grande per riportare dati per quella portata. Mancante non significa zero, superato o non superato.

Ci sono anche requisiti meccanici: la pagina deve restituire 200 (dopo i redirect) e non deve avere noindex (nell’header o nel meta tag). Inoltre esiste una regola del 20%: “origins or pages having more than 20% of their total traffic excluded due to ineligible combinations of dimensions are excluded entirely from the dataset.”

Ho misurato quanto può essere sottile questa copertura. Nel mio studio sui dati Core Web Vitals ho combinato CrUX con un crawl Ahrefs di 43,66 milioni di pagine. Solo 5,21 milioni — circa l’11,9 % — avevano almeno una metrica Core Web Vitals nel dataset CrUX di gennaio 2022. Le altre avevano troppo poco traffico per qualificarsi. È la situazione normale del web, non un errore.

Quando un URL specifico non ha dati, gli strumenti procedono a cascata. In PageSpeed Insights: CrUX a livello di URL → se insufficiente, fallback a CrUX a livello di origin → se manca anche quello, non ottieni dati sul campo e rimane solo la sezione Lighthouse di laboratorio. La nota di Google sul motivo per cui le richieste granulari falliscono più spesso: “The more fine-grained the request is, for example a specific combination of URL and form factor, the fewer user experiences it will include. This may lead to more frequent ‘not found’ errors.”

Come CrUX aggrega i dati: 28 giorni e p75

Due numeri definiscono il modo in cui CrUX riporta ogni risultato.

La finestra mobile di 28 giorni. “The data in the Chrome UX Report is a 28-day rolling average of aggregated metrics.” Ogni valore che vedi è un’aggregazione sugli ultimi 28 giorni. Una conseguenza segnalata da Google è questa: “the collectionPeriod will always show 28-days, even if the data is not for the full 28 days (for example if a page was launched less than 28 days ago).”

La conseguenza pratica — e lo ripeto da anni — è che le correzioni impiegano un po’ di tempo per comparire. CrUX è indietro di circa 2 giorni rispetto al tempo reale e ogni valore è un’aggregazione sulla finestra mobile, non un numero in tempo reale: quindi una modifica non sostituisce del tutto i dati precedenti finché non si accumulano abbastanza nuove sessioni idonee e quelle vecchie non escono dalla finestra. Un mese circa è una regola pratica ragionevole, ma non è un conto alla rovescia fisso: la velocità con cui una correzione compare dipende dal traffico idoneo dell’URL o dell’origin, dalla durata della metrica e dal periodo di raccolta riportato per quel record. Come ho scritto nella mia guida al CLS, “it takes a while to see the impact of changes.” Serve a gestire le aspettative: non promettere risultati dal primo giorno e nemmeno una data precisa.

Il 75° percentile (p75). I CWV vengono valutati al p75, non sulla mediana. La definizione di Google è: “75% of page loads experienced the given metric at or less than this value.” Per superare la soglia, tre caricamenti su quattro devono essere al valore indicato o sotto il livello “good”. Un’importante precisazione di Google: i valori percentili “are synthetically derived, it does not imply that any user actually experienced the value indicated.” Un p75 “good” non significa letteralmente che il 75% degli utenti sia soddisfatto: significa che il 75% dei caricamenti è arrivato alla soglia o al di sotto, e il quartile superiore non viene penalizzato finché questa condizione è rispettata.

Livello origin e livello URL

CrUX riporta i dati a due livelli di granularità, e la differenza è una delle cose più importanti da capire per chi si occupa di SEO.

• Livello origin aggrega “all data present for all pages in that origin … together”: in pratica, fa la media dell’intero dominio.
• Livello URL restituisce “only data for that specific URL.”

Questi due livelli possono divergere nettamente. Un sito può mostrare CrUX “Good” a livello di origin mentre una landing page specifica e importante è “Poor”, perché le pagine più veloci altrove compensano la media dell’origin. Poiché PSI ricade sui dati dell’origin quando un URL non ha un campione sufficiente, potresti osservare la media del dominio pensando di guardare la pagina che hai davanti.

Il mio studio sui dati ha mostrato questa differenza su larga scala: nel campione di gennaio 2022, circa il 33% dei siti superava i CWV a livello di origin, ma solo circa il 21,2% delle singole pagine li superava. I numeri a livello di dominio erano più alti in parte perché includono visite ripetute e memorizzate nella cache sull’intero sito. Considera queste cifre uno snapshot datato su un campione ampio, non un tasso universale attuale; la lezione di fondo però resta valida: controlla i dati a livello di URL per le pagine chiave quando sono disponibili e non dare per scontato che un origin superato significhi che ogni pagina lo sia.

CrUX distingue anche per form factor — PHONE, TABLET e DESKTOP — e Google valuta usando i dati appropriati per ciascun form factor; ecco perché i numeri mobile e desktop differiscono.

Sul campo vs in laboratorio: perché il tuo punteggio Lighthouse non coincide

Questa è la tensione centrale, e vale la pena essere precisi. I dati sul campo sono “determined by monitoring all users who visit a page and measuring … each one of those users’ individual experiences”: questa categoria generale è chiamata anche RUM (real-user monitoring), e CrUX è una sua implementazione specifica e pubblica. I dati di laboratorio (Lighthouse) sono “determined by loading a web page in a controlled environment with a predefined set of network and device conditions.”

Sono diversi perché i dati sul campo “includes a wide variety of network and device conditions as well as a myriad of different types of user behavior,” mentre un test di laboratorio “intentionally limits the number of variables”: un dispositivo, una rete, una posizione e in genere una cache fredda. PageSpeed Insights mostra letteralmente entrambi: la sezione CrUX sul campo in alto (quella su cui Google ti valuta) e la sezione Lighthouse di laboratorio in basso (un’approssimazione utile per il debugging). Come dicono i documenti CrUX: “CrUX is a collection of real-user experiences from the field, while Lighthouse is a controlled test in the lab.”

Quindi, quando la tua esecuzione Lighthouse locale dice 95 ma Search Console dice “Needs Improvement”, non c’è nulla di rotto: stai confrontando un singolo caricamento pulito in laboratorio con la realtà disordinata dei tuoi utenti.

CrUX non è la stessa cosa del tuo RUM. Uno strumento RUM privato e di prima parte (strumentato con qualcosa come la libreria JavaScript web-vitals) e CrUX possono riportare numeri diversi per la stessa pagina, perché popolazioni, stati del consenso, campionamento e durata delle metriche non sono identici. Pensa alle tre opzioni come a lavori diversi:

• CrUX — il benchmark pubblico e gratuito delle esperienze Chrome idonee. Usalo per vedere ciò che vede Google e controllare le prestazioni sul campo di un concorrente.
• RUM privato — il tuo monitoraggio strumentato. Usalo quando ti servono tutti i browser (non solo Chrome idoneo), dettagli per utente o segmento, oppure avvisi in tempo reale che la finestra mobile di CrUX non può offrire.
• Monitoraggio sintetico (Lighthouse, WebPageTest e strumenti simili) — un test controllato e ripetibile. Usalo per i controlli di regressione prima del rilascio e per diagnosticare perché una metrica sul campo è scarsa, non per dichiarare risolta la metrica sul campo.

Per la teoria generale sul campo e il laboratorio, oltre CrUX in particolare — opzioni per gli strumenti RUM, configurazioni di monitoraggio sintetico e il quadro decisionale più ampio — consulta l’approfondimento Dati sul campo e di laboratorio.

Cosa contiene CrUX (e cosa non contiene)

Sono presenti tutti e tre i Core Web Vitals — Largest Contentful Paint (caricamento), Interaction to Next Paint (reattività) e Cumulative Layout Shift (stabilità visiva) — valutati al p75 rispetto a queste soglie:

Oltre ai tre, CrUX contiene anche metriche di supporto come FCP (First Contentful Paint), il TTFB sperimentale e RTT (Round Trip Time, che ha sostituito la dimensione ECT ritirata nel gennaio 2025), oltre alle sotto-parti dell’immagine LCP e ai tipi di navigazione.

Ciò che CrUX non contiene sono le diagnosi esclusive del laboratorio: Total Blocking Time, Speed Index e Time to Interactive non esistono in CrUX, ma sono disponibili solo in Lighthouse. E nota il cambiamento storico: INP ha sostituito FID come Core Web Vital nel marzo 2024 e FID è stato rimosso da CrUX nell’agosto 2024 (e da BigQuery nel settembre 2024). Molte guide più vecchie fanno ancora riferimento a FID: non sono aggiornate.

Sei modi per accedere a CrUX

Le cadenze, le quote e la profondità storica indicate sotto sono aggiornate al momento della scrittura; Google le ha già cambiate in passato (la recente dismissione del CrUX Dashboard ne è un esempio), quindi considera questa una fotografia e controlla i documenti ufficiali collegati per i numeri attuali prima di costruire qualcosa che dipenda da essi.

Alcuni dettagli che vale la pena conoscere:

• PageSpeed Insights è il modo più rapido per guardare un URL. Dati sul campo in alto, laboratorio in basso; è gratuito e non richiede una chiave API.
• Il report Core Web Vitals di Search Console raggruppa gli URL indicizzati per stato (Good / Needs Improvement / Poor), con viste Mobile e Desktop separate. Poiché raggruppa le pagine per modello, un “gruppo di pagine” può mescolare URL veloci e lenti: ecco perché una pagina può apparire a posto in PSI ma essere segnalata in GSC.
• La CrUX API (POST …/v1/records:queryRecord) restituisce la finestra attuale di 28 giorni con p75 e intervalli dell’istogramma; puoi interrogare origin oppure url (sono mutuamente esclusivi). È gratuita, richiede una chiave API Google e “limited to 150 queries per minute per Google Cloud project.”
• La CrUX History API offre fino a 40 settimane di snapshot settimanali: dati di tendenza senza toccare BigQuery.
• BigQuery è l’opzione per l’analisi su larga scala (storico dal 2017 e dati a livello di paese che le API non espongono), ma è solo a livello di origin: le tabelle standard non contengono dati per URL.
• CrUX Vis (cruxvis.withgoogle.com) è lo strumento visuale. Nota: il vecchio CrUX Dashboard in Looker Studio è stato dismesso nel novembre 2025 e il suo connettore ha smesso di aggiornarsi. Se una guida ti rimanda ancora al Dashboard, è obsoleta: usa CrUX Vis.

CrUX modifica il ranking?

CrUX è la fonte dei dati sul campo per il segnale di page experience, quindi sì, alimenta un input del ranking; ma ridimensionerei le aspettative sul suo valore. La mia posizione, dalla mia guida ai Core Web Vitals, è: “I don’t expect much, if any, improvement in rankings from improving Core Web Vitals,” e “unless you are extremely slow, I generally won’t prioritize fixing them.” Il motivo più forte per interessarsi ai tuoi numeri CrUX è l’esperienza utente, non un aumento del ranking. Comprendi i dati e non farti prendere dal panico.

Dove si colloca

CrUX è il motore dei dati sul campo sotto l’hub Core Web Vitals. Le metriche che riporta hanno ciascuna il proprio approfondimento — Largest Contentful Paint, Interaction to Next Paint e Cumulative Layout Shift — e i due strumenti principali che mostrano CrUX sono PageSpeed Insights (campo + laboratorio) e Google Lighthouse (solo laboratorio). Se ricordi una cosa sola: la distinzione campo/laboratorio spiega come un punteggio verde in laboratorio e una valutazione CWV negativa possano essere entrambi veri.

Riepilogo AI

Una sintesi della versione Advanced:

• CrUX = dati sul campo ed è il dataset alla base dei Core Web Vitals. Quando Google valuta i tuoi CWV per la Ricerca, legge CrUX, non un punteggio Lighthouse di laboratorio.
• La raccolta è limitata alle esperienze Chrome idonee: utenti che soddisfano quattro criteri documentati (consenso, cronologia sincronizzata, nessuna passphrase Sync, piattaforma supportata), mai tutti gli utenti Chrome e mai tutti i visitatori. Niente Chrome su iOS, Android WebView, Edge/Safari/Firefox. Per i pubblici dominati da Safari, CrUX misura solo una minoranza degli utenti reali.
• La copertura è parziale e l’idoneità di pagina e origin viene valutata separatamente: un origin può qualificarsi anche quando molte sue pagine non lo fanno. Un risultato mancante significa “campione idoneo insufficiente per riportare dati”, non zero e non superato. Nel mio campione di gennaio 2022 su 43,66 milioni di pagine Site Audit uniche, solo circa l’11,9 % aveva almeno una metrica Core Web Vitals in CrUX. Gli strumenti fanno fallback: URL → origin → “no data” (solo laboratorio).
• L’aggregazione è una finestra mobile di 28 giorni al p75, non una media letterale e non un numero in tempo reale. p75 significa che il 75% dei caricamenti è arrivato al valore o sotto; i valori sono derivati sinteticamente. Le correzioni impiegano in genere circa un mese per registrarsi, ma non esiste una garanzia fissa di 30 giorni: dipende dal volume di traffico idoneo, dalla durata della metrica e dal ritardo della finestra.
• La distinzione origin/URL è importante. Origin = aggregato dell’intero dominio; URL = quella pagina. Divergono: il mio studio ha rilevato che circa il 33 % dei siti superava i CWV a livello di origin, contro solo circa il 21,2 % delle singole pagine. Controlla il livello URL per le pagine chiave.
• Campo e laboratorio spiegano perché Lighthouse (un singolo caricamento pulito in laboratorio) non coincide con CrUX (utenti reali e disordinati). PSI mostra entrambi. CrUX è una forma specifica e pubblica di RUM: uno strumento RUM privato e di prima parte può comunque dare risultati diversi.
• Sei superfici di accesso (cadenze e quote aggiornate al momento della scrittura: verifica prima di farci affidamento): PSI (giornaliera, per URL), Search Console (settimanale), CrUX API (giornaliera), History API (settimanale, 40 settimane), BigQuery (mensile, solo origin, dal 2017), CrUX Vis (settimanale, visuale). Il CrUX Dashboard è stato dismesso nel novembre 2025: usa CrUX Vis.
• L’impatto sul ranking è ridotto; il vero motivo per interessarsi a CrUX è l’esperienza utente.

Documentazione ufficiale

Documentazione CrUX primaria del team Chrome su developer.chrome.com.

• Panoramica di CrUX — cos’è CrUX, il suo ruolo nel programma Web Vitals e come lo usa la Ricerca.
• Metodologia CrUX — i quattro criteri di idoneità degli utenti, le piattaforme supportate/escluse, la regola del 20%, la rimozione del percorso URL e la gestione di SPA/iframe.
• CrUX API — finestra di 28 giorni, definizione di p75, endpoint queryRecord, limite di 150 richieste al minuto e cadenza giornaliera.
• CrUX History API — snapshot settimanali, fino a 40 settimane di storico.
• CrUX su BigQuery — rilascio mensile (secondo martedì), solo livello origin, storico dal 2017 e dati per paese.
• CrUX Vis — lo strumento visuale che ha sostituito il CrUX Dashboard dismesso.
• Guida PageSpeed Insights + CrUX — la cascata URL → origin → nessun dato e la distinzione campo/laboratorio.
• Note di rilascio CrUX — transizione FID→INP, rimozione di FID e cronologia della dismissione del Dashboard.

Approfondimenti correlati (web.dev)

• Differenze tra dati di laboratorio e sul campo — perché un punteggio di laboratorio e CrUX non coincidono.
• Differenze tra CrUX e RUM — dettagli su Chrome-only, esclusione di iOS, SPA e iframe.

Citazioni dalla fonte

Dichiarazioni ufficiali tratte dalla documentazione CrUX del team Chrome. Ogni link è un deep link che porta al passaggio citato.

Che cos’è CrUX

• “The Chrome User Experience Report (also known as the Chrome UX Report, or CrUX for short) is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” [Vai alla citazione](https://developer.chrome.com/docs/crux#:~:text=The%20Chrome%20User%20Experience%20Report%20(also%20known%20as%20the%20Chrome%20UX%20Report)
• “CrUX is the Google dataset of the Web Vitals program. All user-centric Core Web Vitals metrics are represented.” Vai alla citazione

Idoneità e copertura

• “Not all origins or pages are represented in the dataset. There are separate eligibility criteria for origins and pages, primarily that they must be publicly discoverable and there must be a large enough number of visitors in order to create a statistically significant dataset.” Vai alla citazione
• I quattro criteri dell’utente: “Enable usage statistic reporting. Sync their browser history. Not have a Sync passphrase set. Use a supported platform.” Vai alla citazione

Aggregazione

• “The data in the Chrome UX Report is a 28-day rolling average of aggregated metrics.” Vai alla citazione
• “75% of page loads experienced the given metric at or less than this value.” Vai alla citazione
• “The values for each percentile are synthetically derived, it does not imply that any user actually experienced the value indicated, only that some percentage of page loads experienced a metric value that was less than the value given.” Vai alla citazione

Origin e URL

• “When the identifier is an origin all data present for all pages in that origin are aggregated together.” / “When the identifier is a URL, only data for that specific URL will be returned.” Vai alla citazione

Campo e laboratorio (web.dev)

• “Field data is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users’ individual experiences.” Vai alla citazione
• “The Chrome User Experience Report, as its name suggests, is Chrome-only.” Vai alla citazione

Superfici di accesso a CrUX — scheda rapida

Dove ottenere i dati CrUX e a cosa serve ogni superficie — le cadenze e le quote sotto sono aggiornate al momento della scrittura; controlla i documenti ufficiali prima di farci affidamento.

Dati rapidi

• Finestra: ultimi 28 giorni, sempre, anche per le pagine appena lanciate.
• Valutazione a: p75 (75% dei caricamenti al valore o sotto), non una media.
• Ritardo: CrUX è indietro di circa 2 giorni; le correzioni in genere si registrano nell’arco di un mese, ma non c’è una garanzia fissa di 30 giorni: dipende dal traffico idoneo e dalla metrica coinvolta.
• Copertura: solo esperienze Chrome idonee (consenso, sincronizzazione e piattaforma supportata), mai tutti gli utenti Chrome e mai tutti i visitatori. Niente Chrome su iOS, WebView, Edge / Safari / Firefox.
• Nessun dato? La cascata è livello URL → livello origin → solo laboratorio (Lighthouse). Un risultato mancante significa “campione idoneo insufficiente”, non zero e non superato. L’idoneità di pagina e origin viene valutata separatamente.
• Campo e laboratorio: CrUX = campo (utenti reali, ciò che Google valuta). Lighthouse = laboratorio (un caricamento simulato, per il debugging).

Soglie CWV (al p75)

Strumenti per lavorare con CrUX

• PageSpeed Insights (pagespeed.web.dev) — il controllo sul campo per URL più rapido; CrUX in alto, laboratorio Lighthouse sotto. Gratuito e senza chiave.
• Search Console — report Core Web Vitals — valutazione CrUX dell’intero sito raggruppata per stato e separata tra Mobile/Desktop. La vista migliore per capire come stanno davvero i tuoi CWV.
• CrUX Vis (cruxvis.withgoogle.com) — strumento gratuito per le tendenze visuali tramite History API; livello origin e URL; fino a 40 settimane. Ha sostituito il CrUX Dashboard dismesso.
• CrUX API (chromeuxreport.googleapis.com/v1/records:queryRecord) — dati attuali sui 28 giorni via programma; aggiornamento giornaliero; richiede una chiave API gratuita Google Cloud per la “Chrome UX Report API”.
• CrUX History API (…:queryHistoryRecord) — snapshot settimanali, fino a 40 settimane, con gli stessi requisiti di autenticazione e limiti della CrUX API.
• CrUX su BigQuery (dataset chrome-ux-report) — per la ricerca su larga scala: livello origin, aggiornamento mensile (secondo martedì), dati per paese e storico dal 2017; piano gratuito.
• Chrome DevTools — pannello Performance — mostra i dati CrUX sul campo accanto alla traccia locale (aggiunto nel marzo 2025), così puoi confrontare laboratorio e campo fianco a fianco.

Quale superficie CrUX dovrei usare?

Errori CrUX che portano a decisioni sbagliate

Trattare un fallback dell’origin come prova a livello di pagina

PageSpeed Insights può passare da un URL al suo origin quando i campioni sono scarsi. Leggi l’ambito mostrato prima di affermare che una pagina specifica supera la soglia; usa i dati a livello di URL quando disponibili ed etichetta correttamente i dati dell’origin quando non lo sono.

Aspettarsi che una correzione del giorno del lancio riscriva una finestra di 28 giorni

CrUX è un dataset sul campo mobile, non un test di deploy in tempo reale. Usa dati di laboratorio o RUM per la diagnosi iniziale, poi aspetta che nuove esperienze sostituiscano la vecchia finestra sul campo.

Chiamare Lighthouse una misurazione CrUX

Lighthouse è una singola esecuzione di laboratorio controllata. CrUX aggrega visite Chrome reali e idonee. Usa Lighthouse per diagnosticare una probabile causa, non per dichiarare risolta la valutazione sul campo di Google.

Presumere che CrUX rappresenti ogni utente

CrUX esclude Safari, Firefox, Edge, Chrome su iOS, WebView e gli utenti Chrome che non soddisfano i criteri di idoneità. Confrontalo con un RUM di prima parte quando la composizione del pubblico potrebbe rendere non rappresentativo il campione Chrome.

PageSpeed Insights dice che non ci sono dati sul campo

Sintomo: manca la sezione sul campo. Probabile causa: né l’URL né il suo origin soddisfano i requisiti di idoneità o di campionamento CrUX. Correzione: verifica che la pagina pubblica restituisca 200 e sia indicizzabile, poi usa i dati di laboratorio o un RUM di prima parte; il traffico non può essere fabbricato per CrUX. Ricontrolla più avanti se l’utilizzo reale cresce.

La pagina sembra a posto ma l’origin sembra scarso

Sintomo: i risultati a livello di URL e di origin non coincidono. Probabile causa: l’origin aggrega molti tipi di pagina con prestazioni diverse. Correzione: mantieni l’ambito nel report, controlla URL rappresentativi dei template lenti ed evita di fare la media dei due record.

Lighthouse supera la soglia mentre Search Console fallisce

Sintomo: un test controllato è verde ma il report CWV non lo è. Probabile causa: gli utenti reali hanno dispositivi, reti, stati della cache o interazioni più lenti rispetto all’esecuzione di laboratorio. Correzione: segmenta CrUX per dispositivo, confronta la metrica sul campo e quella di laboratorio una per una e usa la traccia di laboratorio per riprodurre il collo di bottiglia sul campo.

Una richiesta API restituisce not found

Sintomo: una richiesta URL/form factor non restituisce alcun record. Probabile causa: la combinazione più ristretta contiene troppo poche esperienze idonee. Correzione: rimuovi le dimensioni opzionali, prova l’ambito origin e riporta esplicitamente il fallback invece di trattare i dati mancanti come un risultato superato.

Checklist per l’analisi CrUX

• Registra se ogni valore è a livello di URL o di origin.
• Mantieni separati i risultati mobile e desktop/form factor.
• Conferma che la finestra sia gli ultimi 28 giorni e annota le date di raccolta.
• Leggi p75 come percentile dei caricamenti di pagina, non come punteggio di un singolo utente.
• Controlla se PageSpeed Insights ha fatto fallback da URL a origin.
• Tratta i dati mancanti come copertura insufficiente, mai come un risultato superato.
• Confronta LCP, INP e CLS separatamente: una metrica superata non fa superare tutte le altre.
• Usa Lighthouse o DevTools per la diagnosi, non come sostituti dei dati sul campo.
• Confronta CrUX con un RUM di prima parte quando gli utenti non Chrome sono importanti.
• Lascia che la finestra mobile completi il ricambio prima di giudicare una correzione di produzione in CrUX.

Ambito, finestra, percentile, popolazione

Ogni numero CrUX diventa più facile da interpretare quando etichetto prima quattro elementi:

1. Ambito: è l’URL esatto o l’intero origin?
2. Finestra: quale periodo mobile di 28 giorni lo ha prodotto?
3. Percentile: è p75, non una media né la visita di un singolo utente.
4. Popolazione: utenti Chrome idonei su piattaforme supportate, non tutto il traffico.

Se un report omette uno qualsiasi di questi elementi, è facile sovrastimare il numero.

Prima il verdetto, poi la diagnosi

CrUX risponde a ciò che hanno sperimentato gli utenti reali idonei. Una traccia di laboratorio risponde a perché un caricamento controllato si è comportato in quel modo. Parti dal verdetto sul campo, scegli la metrica e l’ambito interessati, poi usa gli strumenti di laboratorio per indagare. Dopo aver distribuito una correzione, usa il laboratorio per confermare subito il meccanismo e CrUX per confermare il risultato a livello di popolazione quando la finestra mobile cambia.

KPI CrUX da seguire

LCP, INP e CLS al p75

Metrica: ogni Core Web Vital al p75. Cosa indica: l’esperienza sul campo che Google usa per la valutazione CWV. Come recuperarla: CrUX API, History API, CrUX Vis o PageSpeed Insights, registrando ambito e form factor. Benchmark / intervallo realistico: usa le soglie Good pubblicate in questo articolo e mantieni separate le tre metriche. Cadenza: tendenze settimanali, con controlli giornalieri durante un rollout.

Copertura dello stato Good per template

Metrica: quota dei gruppi di URL importanti valutati Good in Search Console. Cosa indica: quanto ampiamente le prestazioni sul campo sono sane nel sito. Come recuperarla: report Core Web Vitals mobile e desktop più un inventario dei template. Benchmark / intervallo realistico: stabilisci una baseline del sito e dai priorità ai template preziosi e ad alto traffico; gli URL poco densi potrebbero non avere un record CrUX individuale. Cadenza: settimanale.

Disponibilità dei dati a livello di URL

Metrica: URL prioritari monitorati con un proprio record CrUX invece di un fallback all’origin. Cosa indica: quante prove specifiche della pagina può sostenere il tuo reporting. Come recuperarla: registra il successo delle richieste API e l’ambito PSI per l’insieme fisso di URL. Benchmark / intervallo realistico: dipende dal traffico Chrome idoneo; non trasformare la copertura in un obiettivo che incentivi traffico artificiale. Cadenza: mensile.

Mettiti alla prova: Chrome UX Report

Cinque domande rapide sull’ambito, sulla copertura e sull’interpretazione di CrUX. Scegli una risposta per ciascuna e poi controlla.

Risorse che meritano il tuo tempo

I miei articoli correlati

• Studio sui dati Core Web Vitals con CrUX e 5,2M di pagine — il mio studio di prima parte che combina CrUX con un crawl di 43,66 milioni di pagine; è la fonte dei dati sulla copertura di circa l’11,9 % e sui tassi di superamento origin/pagina.
• Cosa sono i Core Web Vitals — dove si colloca CrUX e la mia opinione su quanto i CWV spostino davvero il ranking.
• Largest Contentful Paint (LCP) — il quadro dei dati sul campo per LCP.
• Cumulative Layout Shift (CLS) — compreso il motivo per cui la finestra di 28 giorni rallenta il miglioramento visibile.
• Guida a PageSpeed Insights — lo strumento che mostra i dati CrUX sul campo per URL.

Ufficiale

• Documentazione CrUX (team Chrome) — il riferimento canonico per tutto quanto sopra.
• Report CrUX di HTTP Archive — dashboard pubblici aggiornati costruiti su CrUX/BigQuery.

Da altri autori

• Guida al Chrome User Experience Report di DebugBear — confronto approfondito degli strumenti, rivolto agli sviluppatori.
• Guida SEO di Lumar a velocità del sito, CWV, Lighthouse e CrUX — un buon inquadramento SEO.
• SpeedCurve — Quando usare CrUX, RUM e monitoraggio sintetico — confronto onesto a tre vie; evidenzia chiaramente il punto cieco Chrome-only/iOS.
• GTmetrix — Che cos’è CrUX e perché dovrebbe interessarmi? — analisi dettagliata dell’idoneità e dei limiti di copertura.

Statistiche da citare

• Solo circa l’11,9 % delle 43,66 milioni di pagine Site Audit uniche nel mio campione di gennaio 2022 aveva almeno una metrica Core Web Vitals CrUX. Erano 5,21 milioni di pagine; le altre avevano troppo poco traffico per qualificarsi. Fonte
• Nello stesso campione di gennaio 2022, i tassi di superamento a livello di origin hanno superato quelli a livello di pagina: circa il 33 % contro circa il 21,2 %. I domini che superavano i CWV a livello di origin erano molto più numerosi in parte perché le medie dell’origin includono pagine più veloci e visite ripetute memorizzate nella cache. È uno snapshot datato, non un tasso universale attuale. Fonte
• Quasi nessun sito su 3G o connessioni più lente superava i CWV, secondo quello studio. “The LCP threshold seems almost impossible to pass on slower connections.” Fonte
• La geografia ha distorto i risultati in quel campione. Gli Stati Uniti si sono classificati al 38° posto globale con un tasso di superamento di circa il 41 %; le abitudini di dispositivo e rete dei vari paesi hanno spiegato gran parte della differenza. Fonte
• Per vedere una correzione registrarsi completamente servono circa un mese: la finestra di 28 giorni più il ritardo di circa 2 giorni di CrUX, anche se la tempistica esatta non è fissa e dipende dal traffico idoneo e dalla metrica coinvolta. Fonte
• Oggi più della metà degli origin supera i Core Web Vitals. Nel traguardo CrUX dell’agosto 2024, Google ha riferito che oltre il 50 % degli origin nel dataset superava tutti e tre i Core Web Vitals, in netto aumento rispetto al tasso di circa il 33 % a livello di origin misurato negli studi precedenti. Fonte
• CrUX copre oltre 15 milioni di origin. Nel 2024–2025 il dataset includeva dati da più di 15 milioni di origin distinti, secondo la documentazione metodologica del team Chrome. Fonte

Cronologia modifiche