Strumenti per le prestazioni web

I tre strumenti che misurano le prestazioni web: Google Lighthouse per il laboratorio, Chrome UX Report/CrUX per il campo e PageSpeed Insights per entrambi nella stessa interfaccia. Scopri quali dati usa Google per il posizionamento e quale strumento scegliere per ogni attività.

Tre strumenti coprono le prestazioni web e la distinzione essenziale è tra laboratorio e campo. Google Lighthouse esegue un audit simulato e assegna alla pagina un punteggio su scala centesimale: Performance = TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%. È uno strumento diagnostico, non un segnale di posizionamento. CrUX, Chrome UX Report, è il dataset sul campo degli utenti reali su cui si basa la Ricerca Google, al p75 in una finestra di 28 giorni. PageSpeed Insights mostra entrambi: in alto i dati CrUX sul campo, rilevanti per la SEO, e sotto un’esecuzione Lighthouse di laboratorio, utile per la diagnosi. Usa i dati sul campo per sapere a che punto sei e quelli di laboratorio per individuare che cosa correggere. Questo hub rimanda ai tre approfondimenti.

Prova a sostegno di questa affermazione CrUX reports aggregated real-user Chrome experience data over a rolling collection period. Ambito: Eligible Chrome users and sufficiently popular origins/URLs; not every page has CrUX data. Attendibilità: alta · Verificato: Chrome Developers: CrUX methodology Prova a sostegno di questa affermazione Lighthouse produces lab diagnostics and a performance score from a controlled run, distinct from field data. Ambito: Lighthouse lab testing; settings and versions affect results. Attendibilità: alta · Verificato: Chrome Developers: Lighthouse performance scoring

TL;DR — La misurazione delle prestazioni web si riduce alla distinzione tra laboratorio e campo. Lighthouse = laboratorio: un audit simulato (4G lenta, CPU rallentata 4×) che assegna alla pagina un punteggio su scala centesimale (Performance = TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%). È uno strumento diagnostico, non un segnale di posizionamento, e non può misurare INP: usa TBT come proxy. CrUX = campo: veri utenti Chrome che hanno acconsentito alla raccolta, al 75° percentile in una finestra mobile di 28 giorni; è il dataset sul campo alla base dei report pubblici di Google sui CWV. PageSpeed Insights = entrambi nella stessa interfaccia: dati CrUX sul campo in alto, con la valutazione CWV Superata/Non superata rilevante per la SEO, ed esecuzione Lighthouse in laboratorio sotto, con il punteggio su scala centesimale che non lo è. Usa i dati sul campo per sapere a che punto sei, quelli di laboratorio per la diagnosi e Search Console per trovare gruppi di pagine con problemi su larga scala. Soltanto circa l’11,9% dei 43,66 milioni di pagine uniche di Site Audit nel mio campione di gennaio 2022 aveva una metrica CrUX: molte pagine di quel campione erano prive di dati sul campo e PSI mostrava soltanto il punteggio di laboratorio.

Il principio centrale: dati di laboratorio e dati sul campo

Quasi ogni equivoco su questi strumenti nasce dalla confusione tra due tipi di dati. La formulazione di web.dev è la più chiara: “CrUX is a collection of real-user experiences from the field, while Lighthouse is a controlled test in the lab.” (traduzione) «CrUX raccoglie le esperienze di utenti reali sul campo, mentre Lighthouse è un test controllato in laboratorio».

  • I dati di laboratorio sono “collected in a controlled environment with predefined device and network settings.” (traduzione) «raccolti in un ambiente controllato con impostazioni predefinite per dispositivo e rete». Sono riproducibili, rapidi e ottimi per rilevare regressioni, ma rappresentano un solo visitatore sintetico, non il tuo pubblico.
  • I dati sul campo “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.” (traduzione) «sono determinati monitorando tutti gli utenti che visitano una pagina e misurando un insieme di metriche delle prestazioni per ogni singola esperienza». Sono rumorosi, arrivano in ritardo e rappresentano la realtà.

Le indicazioni di Google sulle priorità sono esplicite: “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (traduzione) «Se per una pagina disponi sia di dati sul campo sia di dati di laboratorio, devi usare quelli sul campo per stabilire le priorità». La prima domanda che ogni SEO dovrebbe porsi prima di leggere un numero è quindi: in questo momento sto guardando dati di laboratorio o dati sul campo?

StrumentoTipo di datiChe cos’è
Google LighthouseLaboratorioMotore di audit simulato; il punteggio su scala centesimale
Chrome UX Report (CrUX)CampoDataset di utenti reali usato da Google per il posizionamento
PageSpeed InsightsEntrambiUn’interfaccia: dati CrUX sul campo in alto, Lighthouse in laboratorio sotto

Google Lighthouse: la diagnostica di laboratorio

Lighthouse è “an open-source, automated tool to help you improve the quality of web pages.” (traduzione) «uno strumento open source e automatizzato che aiuta a migliorare la qualità delle pagine web». Gli fornisci un URL, “runs a series of audits against the page,” (traduzione) «esegue una serie di audit sulla pagina» e restituisce un report su Performance, Accessibilità, Best practice e SEO. Lighthouse 12 ha eliminato la vecchia categoria PWA, ma con Lighthouse 13.3, pubblicato nel maggio 2026, esiste di nuovo una quinta categoria: Agentic Browsing, un audit sperimentale sulla capacità della pagina di funzionare con gli agenti AI, che valuta qualità dell’albero di accessibilità, stabilità del layout e registrazione degli strumenti WebMCP. Non usa il punteggio ponderato su scala centesimale delle altre quattro categorie: restituisce controlli superato/non superato e un conteggio frazionario della preparazione. Non includerla quindi nel numero Performance descritto sotto.

Il punteggio Performance è una media ponderata di cinque metriche di laboratorio, valida per Lighthouse 10. Google modifica queste ponderazioni tra le versioni, quindi considera i numeri verificabili, non permanenti:

MetricaPeso
Total Blocking Time (TBT)30%
Largest Contentful Paint (LCP)25%
Cumulative Layout Shift (CLS)25%
First Contentful Paint (FCP)10%
Speed Index10%

Fasce di colore: 0–49 rosso (scarso), 50–89 arancione (da migliorare), 90–100 verde (buono). Alcuni aspetti spesso trascurati:

  • Applica intenzionalmente il throttling — 4G lenta e CPU rallentata 4× — e per questo il punteggio è spesso inferiore all’esperienza reattiva che ottieni sul tuo computer veloce.
  • Non può misurare INP. Come spiega web.dev, gli strumenti “that load pages in a simulated environment without a user cannot measure INP… the Total Blocking Time (TBT) metric is lab-measurable and is a proxy for INP.” (traduzione) «che caricano pagine in un ambiente simulato senza un utente non possono misurare INP… la metrica Total Blocking Time (TBT) è misurabile in laboratorio ed è un proxy di INP». Un TBT perfetto non garantisce che INP venga superato sul campo.
  • Il punteggio varia tra le esecuzioni, come afferma chiaramente Google. Esegui il test 3–5 volte in modalità in incognito con le estensioni disattivate e considera il risultato un intervallo.
  • Non è un segnale di posizionamento. Lighthouse serve a diagnosticare che cosa correggere. → Approfondimento: Google Lighthouse.

Chrome UX Report (CrUX): il dataset degli utenti reali usato da Google per il posizionamento

CrUX è “a dataset that reflects how real-world Chrome users experience popular destinations on the web,” (traduzione) «un dataset che riflette il modo in cui gli utenti reali di Chrome sperimentano le destinazioni più popolari del web» e, soprattutto, “CrUX data is used by Google Search to inform the page experience ranking factor.” (traduzione) «i dati CrUX vengono usati dalla Ricerca Google per alimentare il fattore di posizionamento relativo all’esperienza sulle pagine». Sono i dati alla base del programma Core Web Vitals, quelli che contribuiscono effettivamente al posizionamento.

Che cosa devi sapere:

  • Riguarda soltanto Chrome e utenti che hanno acconsentito. Include Chrome desktop e Android degli utenti che hanno attivato i report, ma non Chrome su iOS, WebView, Edge, Safari o Firefox. Per un pubblico che usa molto Safari, CrUX può rappresentare una minoranza degli utenti reali.
  • È una media mobile di 28 giorni al 75° percentile. p75 significa “75% of page loads experienced the given metric at or less than this value.” (traduzione) «il 75% dei caricamenti di pagina ha registrato la metrica indicata a un valore uguale o inferiore». I valori p75 sono derivati sinteticamente: “it does not imply that any user actually experienced the value indicated.” (traduzione) «non implica che un utente abbia realmente sperimentato il valore indicato».
  • Feedback lento. Considerando la finestra di 28 giorni e un ritardo di circa 2 giorni, servono all’incirca ~30 giorni perché una correzione compaia completamente nei dati sul campo.
  • Copertura parziale. Nel mio studio Ahrefs sui dati dei Core Web Vitals, soltanto circa l’11,9% dei 43,66 milioni di pagine analizzate disponeva di dati CrUX e circa il 21,2% delle pagine superava i Core Web Vitals. Le percentuali di superamento a livello di origine sono più alte, circa il 33%, ma i dati di origine nascondono singole pagine con problemi e Google si basa sui dati a livello di pagina.
  • Sei modalità di accesso: PageSpeed Insights, report CWV di Search Console, API CrUX, API CrUX History, BigQuery, soltanto a livello di origine e con dati dal 2017, e CrUX Vis. Nota: la dashboard CrUX di Looker Studio è stata ritirata nel novembre 2025; usa invece CrUX Vis (cruxvis.withgoogle.com). → Approfondimento: Chrome UX Report (CrUX).

PageSpeed Insights (PSI): campo e laboratorio nello stesso posto

PSI “reports on the user experience of a page on both mobile and desktop devices, and provides suggestions on how that page may be improved.” (traduzione) «fornisce informazioni sull’esperienza utente di una pagina su dispositivi mobili e desktop e suggerimenti per migliorarla». In realtà sono due dataset sotto lo stesso cappotto:

  • In alto: dati CrUX sul campo. “Real-user experience data in PSI is powered by the Chrome User Experience Report (CrUX) dataset.” (traduzione) «I dati sull’esperienza degli utenti reali in PSI provengono dal dataset Chrome User Experience Report (CrUX)». Alimentano la valutazione dei Core Web Vitals, Superata o Non superata al p75 per LCP, INP e CLS: “To pass, the percentile must be categorized as ‘good’ in all three Core Web Vitals.” (traduzione) «Per superarla, il percentile deve essere classificato come “buono” in tutti e tre i Core Web Vitals». Se l’URL esatto non ha dati, PSI passa al livello di origine e poi a “Nessun dato”.
  • In basso: esecuzione Lighthouse in laboratorio. “PSI uses Lighthouse to analyze the given URL in a simulated environment.” (traduzione) «PSI usa Lighthouse per analizzare l’URL fornito in un ambiente simulato». È il punteggio Performance su scala centesimale con la diagnostica.
Prova a sostegno di questa affermazione Lighthouse produces lab diagnostics and a performance score from a controlled run, distinct from field data. Ambito: Lighthouse lab testing; settings and versions affect results. Attendibilità: alta · Verificato: Chrome Developers: Lighthouse performance scoring

Il punto essenziale per la SEO: il punteggio su scala centesimale è un dato di laboratorio e NON è un input di posizionamento. Soltanto la valutazione CWV sul campo, cioè la sezione CrUX, riflette ciò che Google usa per il ranking. PSI funziona su qualsiasi URL pubblico, quindi puoi controllare anche i concorrenti, ma soltanto su URL pubblici: “It cannot be used on development sites that are not publicly accessible.” (traduzione) «Non può essere usato su siti di sviluppo non accessibili pubblicamente». Per questi ultimi, esegui Lighthouse in DevTools. → Approfondimento: PageSpeed Insights (PSI).

Scegliere lo strumento giusto

La decisione si riduce a poche domande:

Vuoi…Usa
Sapere a che punto sei per il posizionamentoDati CrUX sul campo, tramite PageSpeed Insights o report CWV di Search Console
Trovare gruppi di pagine con problemi nell’intero sitoReport Core Web Vitals di Google Search Console
Diagnosticare la causa di un problemaLighthouse, sezione di laboratorio di PSI o Chrome DevTools
Testare i dati sul campo e di laboratorio di un singolo URLPageSpeed Insights
Testare una pagina protetta da accesso, soltanto in laboratorioLighthouse in Chrome DevTools
Monitorare le tendenze sul campo nel tempoCrUX Vis, API CrUX History o BigQuery
Controllare molti URL via APIAPI PSI o API CrUX
Controllare i CWV degli utenti reali di un concorrentePageSpeed Insights, che funziona su qualsiasi URL pubblico
Osservare l’aggiornamento in tempo reale di una metrica mentre interagisci e tracciare la causa precisaMetriche live di Chrome DevTools + traccia delle prestazioni registrata
Rilevare una regressione prima della pubblicazione, da una posizione controllata o in CIMonitoraggio sintetico
Vedere l’esperienza di ogni visitatore reale, segmentata secondo il tuo contesto aziendaleRUM privato sul tuo sito

Alla base della tabella ci sono due regole: campo per la valutazione, laboratorio per la diagnosi e l’intero sito va in Search Console, i singoli URL in PSI. Se una pagina non ha dati CrUX, da PSI non puoi valutarne affatto i CWV sul campo; rimane soltanto un punteggio di laboratorio, che non dice nulla sul segnale di posizionamento.

Oltre i tre strumenti: DevTools, gruppi di Search Console, RUM e monitoraggio sintetico

Lighthouse, PSI e CrUX coprono gran parte delle esigenze quotidiane di un SEO, ma chiamarli “i tre strumenti” sminuisce il resto della dotazione:

  • Metriche live e tracce delle prestazioni in Chrome DevTools. Apri una pagina nel pannello Prestazioni di DevTools e LCP, CLS e INP si aggiornano mentre tu interagisci con la pagina; registra una traccia e puoi individuare lo script o la risorsa precisa che provoca il ritardo. Poiché avviene una vera interazione, può rilevare un valore INP, a differenza del caricamento di laboratorio non interattivo di Lighthouse.
  • Il report Core Web Vitals di Search Console raggruppa URL simili, non traccia una singola pagina. È una superficie di triage per l’intero sito, utile a trovare il template o il pattern di URL che presenta problemi su larga scala. Apri un gruppo, poi porta un URL rappresentativo in PSI o DevTools per la diagnosi.
  • Il monitoraggio sintetico ripete lo stesso controllo automatizzato secondo una pianificazione, da località e profili dispositivo scelti, spesso integrato nella CI. Una regressione viene così rilevata prima della pubblicazione invece di comparire in CrUX circa 30 giorni dopo. È ripetibile e controllato, ma osserva soltanto gli scenari configurati, non il traffico reale.
  • Il RUM privato (Real User Monitoring) integra nel tuo sito un sistema che registra l’esperienza reale di ogni visitatore, non soltanto della popolazione Chrome idonea e consenziente di CrUX, e può segmentarla secondo il contesto aziendale, come utenti autenticati, percorso di pagamento e ricavi, che CrUX non conosce. Per lo stesso motivo può legittimamente essere in disaccordo con CrUX: cambiano copertura dei browser, regole sul consenso, campionamento e finestre di aggregazione. Devi gestire direttamente i compromessi relativi a configurazione, privacy/consenso e costi.

Tutto questo non cambia il principio centrale: i dati sul campo, CrUX o il tuo RUM, indicano a che punto sei; strumenti di laboratorio, tracce e test sintetici spiegano perché. Se invece cerchi una classifica di prodotti e non una mappa dei compiti, esistono molti elenchi dei “migliori strumenti per le prestazioni web”. In genere fai prima a eseguire un test pubblico sul tuo URL, perché un elenco classifica i fornitori, non la tua pagina.

Il flusso di lavoro che uso davvero

  1. Google Search Console → report Core Web Vitals. Individua su larga scala i gruppi di pagine con problemi nel sito.
  2. PageSpeed Insights. Conferma a livello di pagina: leggi il verdetto della valutazione CWV sui dati sul campo per un URL rappresentativo.
  3. Sezione di laboratorio di PSI / Lighthouse / Chrome DevTools. Diagnostica la causa principale e perfeziona la correzione con il feedback rapido di laboratorio.
  4. Attendi circa 30 giorni. I dati sul campo si aggiornano con la finestra di 28 giorni più il ritardo.
  5. Controlla nuovamente i dati sul campo in PSI e Search Console per confermare il miglioramento degli utenti reali.

I dati di laboratorio sono il ciclo di feedback rapido dopo una modifica; quelli sul campo sono la conferma lenta e autorevole.

Come funzionano davvero i CWV nel posizionamento, in breve

Google documenta i Core Web Vitals come un elemento usato dai propri sistemi di posizionamento e CrUX come il dataset alla base dei report pubblici sui CWV visibili in PSI, Search Console e nell’API CrUX: questo è ben accertato e non riguarda i punteggi di laboratorio. Non è invece documentata pubblicamente una corrispondenza 1:1 tra il numero esatto mostrato da una superficie CrUX pubblica e il valore interno letterale letto dai sistemi di ranking di Google per quella pagina. Considera il dato pubblico il miglior proxy disponibile del segnale, non una lettura verificata. In ogni caso è un segnale reale ma modesto. John Mueller lo ha definito “more than a tie-breaker, but it also doesn’t replace relevance,” (traduzione) «più di un criterio di spareggio, ma non sostituisce la pertinenza» e, durante l’aggiornamento della documentazione del 2024, “it’s not going to make your site’s rankings jump up.” (traduzione) «non farà balzare in alto il posizionamento del tuo sito». La documentazione di Google sull’esperienza sulle pagine afferma ora che “trying to get a perfect score just for SEO reasons may not be the best use of your time.” (traduzione) «cercare di ottenere un punteggio perfetto soltanto per motivi SEO potrebbe non essere il modo migliore di impiegare il tempo». Per la trattazione completa, con soglie, tre metriche e peso da attribuire al segnale, consulta l’hub Core Web Vitals.

Una nota su Bing

Bing non ha pubblicato documentazione che presenti questi strumenti per le prestazioni come fattori di posizionamento nel modo in cui lo ha fatto Google; i Core Web Vitals sono soprattutto un costrutto di Google. Bing Webmaster Tools mostra una panoramica dei Core Web Vitals e i miglioramenti reali a esperienza utente e velocità sono utili su tutti i motori di ricerca, ma la catena di strumenti descritta in questa pagina appartiene a Google.

Dove proseguire

Questo hub è la mappa; ciascuno strumento ha un proprio approfondimento al livello inferiore:

  • Google Lighthouse — il motore di audit di laboratorio: le quattro categorie, la costruzione del punteggio Performance ponderato su scala centesimale, i motivi del throttling e della variabilità e perché è uno strumento diagnostico invece di un input di posizionamento.
  • PageSpeed Insights (PSI) — due dataset nella stessa interfaccia: sezione CrUX sul campo e sezione Lighthouse di laboratorio, valutazione CWV Superata/Non superata, fallback dei dati e API PSI per i test in massa.
  • Chrome UX Report (CrUX) — dataset sul campo degli utenti reali: copertura degli utenti Chrome consenzienti, finestra p75 di 28 giorni, dati di origine e URL, motivi della dicitura “Nessun dato” e sei modalità di accesso, compreso CrUX Vis dopo il ritiro della dashboard.

Per le metriche misurate da questi strumenti — Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, oltre a Total Blocking Time e Speed Index — e per le soglie usate da Google, inizia dall’hub Core Web Vitals.

Aggiungi una nota dell’esperto

Fissa una citazione dell’esperto

Persona nuova? Crea il suo profilo non rivendicato in /admin/experts/ → Fissa una citazione dell’esperto prima.