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.
TL;DR — Esistono tre strumenti principali per misurare la velocità delle pagine e vengono continuamente confusi. Google Lighthouse esegue un singolo test in un “laboratorio” simulato e assegna un punteggio su scala centesimale. CrUX raccoglie dati reali da veri utenti Chrome ed è la fonte di dati sul campo usata per i report sui Core Web Vitals. PageSpeed Insights mostra entrambi nella stessa schermata. La lezione fondamentale: Google non basa il posizionamento sul tuo punteggio di laboratorio.
Tre strumenti, tre funzioni
Quando inizi a misurare la velocità delle pagine, incontrerai continuamente tre nomi: Google Lighthouse, PageSpeed Insights e Chrome UX Report (CrUX). Molti pensano che siano la stessa cosa, ma non lo sono. Ecco il modo più semplice per distinguerli:
- Google Lighthouse è uno strumento di test. Carica la pagina su uno smartphone lento simulato, esegue una serie di controlli e assegna un punteggio su scala centesimale. È un test di laboratorio: un dispositivo, un momento, condizioni controllate.
- Chrome UX Report (CrUX) contiene dati reali provenienti da veri utenti Chrome che visitano il sito. Sono dati sul campo e sono quelli che Google usa per il posizionamento.
- PageSpeed Insights (PSI) è una pagina web gratuita che mostra entrambi: in alto i dati sul campo degli utenti reali provenienti da CrUX e sotto un test di laboratorio Lighthouse.
Laboratorio e campo: l’unico concetto da ricordare
“Laboratorio” indica un test controllato: un dispositivo, una configurazione di rete, esecuzione su richiesta. “Campo” significa persone vere su smartphone e computer reali, con connessioni reali, misurate durante l’uso effettivo del sito.
È importante perché Google si basa sui dati sul campo, non sul punteggio di laboratorio. Puoi ottenere 100 in Lighthouse mentre gli utenti reali sperimentano una pagina lenta, oppure un risultato scarso in laboratorio pur offrendo un’esperienza valida ai visitatori reali. Quando i due dati sono in disaccordo, per la SEO conta quello degli utenti reali, cioè sul campo.
Quale devo usare?
- “Come sto andando ai fini del posizionamento?” → Guarda i dati sul campo (CrUX), più facilmente in PageSpeed Insights o Google Search Console.
- “Che cosa rallenta la mia pagina?” → Esegui Lighthouse: elenca ciò che devi correggere.
- “Voglio soltanto un posto in cui vedere entrambi.” → PageSpeed Insights.
Vuoi il quadro completo, con il funzionamento dei punteggi Lighthouse, il significato di “p75”, i motivi per cui tante pagine non hanno alcun dato sul campo e il flusso preciso che uso per individuare e correggere i problemi? Passa alla scheda Avanzato.
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?
| Strumento | Tipo di dati | Che cos’è |
|---|---|---|
| Google Lighthouse | Laboratorio | Motore di audit simulato; il punteggio su scala centesimale |
| Chrome UX Report (CrUX) | Campo | Dataset di utenti reali usato da Google per il posizionamento |
| PageSpeed Insights | Entrambi | Un’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:
| Metrica | Peso |
|---|---|
| Total Blocking Time (TBT) | 30% |
| Largest Contentful Paint (LCP) | 25% |
| Cumulative Layout Shift (CLS) | 25% |
| First Contentful Paint (FCP) | 10% |
| Speed Index | 10% |
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.
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 posizionamento | Dati CrUX sul campo, tramite PageSpeed Insights o report CWV di Search Console |
| Trovare gruppi di pagine con problemi nell’intero sito | Report Core Web Vitals di Google Search Console |
| Diagnosticare la causa di un problema | Lighthouse, sezione di laboratorio di PSI o Chrome DevTools |
| Testare i dati sul campo e di laboratorio di un singolo URL | PageSpeed Insights |
| Testare una pagina protetta da accesso, soltanto in laboratorio | Lighthouse in Chrome DevTools |
| Monitorare le tendenze sul campo nel tempo | CrUX Vis, API CrUX History o BigQuery |
| Controllare molti URL via API | API PSI o API CrUX |
| Controllare i CWV degli utenti reali di un concorrente | PageSpeed Insights, che funziona su qualsiasi URL pubblico |
| Osservare l’aggiornamento in tempo reale di una metrica mentre interagisci e tracciare la causa precisa | Metriche live di Chrome DevTools + traccia delle prestazioni registrata |
| Rilevare una regressione prima della pubblicazione, da una posizione controllata o in CI | Monitoraggio sintetico |
| Vedere l’esperienza di ogni visitatore reale, segmentata secondo il tuo contesto aziendale | RUM 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
- Google Search Console → report Core Web Vitals. Individua su larga scala i gruppi di pagine con problemi nel sito.
- PageSpeed Insights. Conferma a livello di pagina: leggi il verdetto della valutazione CWV sui dati sul campo per un URL rappresentativo.
- Sezione di laboratorio di PSI / Lighthouse / Chrome DevTools. Diagnostica la causa principale e perfeziona la correzione con il feedback rapido di laboratorio.
- Attendi circa 30 giorni. I dati sul campo si aggiornano con la finestra di 28 giorni più il ritardo.
- 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.
Riepilogo AI
Una sintesi della versione Avanzato:
- Tre strumenti, due tipi di dati. Lighthouse = laboratorio; CrUX = campo; PageSpeed Insights = entrambi nella stessa interfaccia. La prima domanda per ogni numero è: laboratorio o campo?
- Google si basa sui dati sul campo (CrUX), non sui punteggi di laboratorio. I dati sul campo servono a stabilire le priorità; quelli di laboratorio a eseguire la diagnosi.
- Lighthouse è un audit simulato (4G lenta, CPU rallentata 4×) con punteggio su scala centesimale. Performance, con i pesi di Lighthouse 10, soggetti a versione e verificabili ma non permanenti, = TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%. Fasce: 0–49 rosso, 50–89 arancione, 90–100 verde. Non può misurare INP, usa TBT come proxy, varia tra le esecuzioni e non è un segnale di posizionamento. Da Lighthouse 13.3, maggio 2026, esiste una quinta categoria sperimentale, Agentic Browsing: controlli superato/non superato sulla preparazione agli agenti AI, separati dal punteggio su scala centesimale.
- CrUX = utenti Chrome consenzienti, senza Chrome su iOS né Edge/Safari/Firefox, al p75 in una finestra mobile di 28 giorni; è il dataset usato dalla Ricerca Google per il posizionamento. Servono circa ~30 giorni perché una correzione compaia. Nel mio campione Ahrefs di gennaio 2022, soltanto circa l’11,9% di 43,66 milioni di pagine uniche di Site Audit aveva una metrica CrUX e circa il 21,2% delle pagine misurate superava i CWV. La dashboard CrUX di Looker Studio è stata ritirata nel novembre 2025 → usa CrUX Vis.
- PageSpeed Insights mostra in alto i dati CrUX sul campo, con la valutazione CWV Superata/Non superata rilevante per la SEO, e sotto un’esecuzione Lighthouse di laboratorio, con il punteggio su scala centesimale che NON è un fattore di posizionamento. Funziona soltanto con URL pubblici, compresi quelli dei concorrenti.
- Regole decisionali: campo per la valutazione, laboratorio per la diagnosi; intero sito → Search Console; singoli URL → PSI; pagine protette da accesso → Lighthouse in DevTools.
- Oltre i tre strumenti: le metriche live e le tracce di DevTools possono rilevare un vero INP durante l’interazione; Search Console raggruppa URL simili anziché tracciare una pagina; il monitoraggio sintetico ripete i controlli su pianificazione o in CI; il RUM privato copre l’intera popolazione dei visitatori del tuo sito e può legittimamente differire da CrUX. Una classifica dei “migliori strumenti” risponde a una domanda diversa: esegui prima un test pubblico sul tuo URL.
- Precisazione sul posizionamento: Google documenta i CWV come input dei sistemi di ranking e CrUX come dataset alla base dei report pubblici sui CWV. Non esistono prove pubbliche che il numero esatto mostrato da una superficie CrUX pubblica sia il valore interno letterale per pagina letto dai sistemi di Google: consideralo il miglior proxy pubblico, non una lettura verificata.
- Flusso di lavoro: GSC, per trovare gruppi con problemi → PSI, per confermare a livello di pagina → Lighthouse/DevTools, per diagnosticare e correggere → attesa di circa 30 giorni → nuovo controllo sul campo.
Documentazione ufficiale
Documentazione primaria di Google, più una nota su Bing.
Google — gli strumenti
- Panoramica di Lighthouse — che cos’è Lighthouse, che cosa controlla e dove eseguirlo.
- Calcolo del punteggio Performance di Lighthouse — pesi delle metriche, fasce di punteggio e motivi della variabilità.
- Calcolo del punteggio Agentic Browsing di Lighthouse — la quinta categoria sperimentale, introdotta in Lighthouse 13.3 nel maggio 2026: controlli superato/non superato sulla preparazione agli agenti, separati dal punteggio su scala centesimale.
- Riferimento del pannello Prestazioni di Chrome DevTools — metriche live e tracce registrate per misurazioni locali basate sulle interazioni, compreso INP.
- Informazioni su PageSpeed Insights — PSI combina dati Lighthouse di laboratorio e dati CrUX sul campo; fasce di punteggio.
- Uso di CrUX in PageSpeed Insights — funzionamento della sezione sul campo e della valutazione Superata/Non superata.
- Panoramica di Chrome UX Report (CrUX) — dataset, ruolo nei CWV e modalità di accesso.
- Metodologia CrUX — utenti idonei e piattaforme incluse.
- API CrUX — media mobile di 28 giorni e definizione di p75.
- CrUX Vis — strumento visivo per le tendenze che ha sostituito la dashboard ritirata.
Google — laboratorio, campo e posizionamento
- Differenze tra dati di laboratorio e sul campo — Philip Walton spiega che cosa rappresenta ciascun tipo e a quale dare priorità.
- Strumenti per i Core Web Vitals (web.dev) — panoramica di Google sulla dotazione di strumenti.
- Comprendere i Core Web Vitals e i risultati della Ricerca Google — come i CWV si inseriscono nei sistemi di posizionamento.
- Comprendere l’esperienza sulle pagine nella Ricerca Google — l’indicazione secondo cui un “punteggio perfetto… potrebbe non essere il modo migliore di impiegare il tempo”.
Bing / Microsoft
- Bing non ha pubblicato indicazioni che presentino questi strumenti per le prestazioni come fattori di posizionamento. Bing Webmaster Tools mostra una panoramica dei Core Web Vitals, ma i CWV rimangono soprattutto un costrutto di Google. Consulta la guida di Bing Webmaster Tools per le indicazioni generali.
Citazioni dalle fonti
Dichiarazioni pubbliche e attribuite di Google. Ogni link profondo porta al passaggio citato nella pagina di origine.
Google — che cos’è ogni strumento
- “Lighthouse is an open-source, automated tool to help you improve the quality of web pages.” (traduzione) «Lighthouse è uno strumento open source e automatizzato che aiuta a migliorare la qualità delle pagine web.» — Documentazione Chrome for Developers. Vai alla citazione
- “PageSpeed Insights (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) «PageSpeed Insights (PSI) fornisce informazioni sull’esperienza utente di una pagina su dispositivi mobili e desktop e suggerimenti per migliorarla.» Vai alla citazione
- “The Chrome User Experience Report… is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” (traduzione) «Chrome User Experience Report… è un dataset che riflette il modo in cui gli utenti reali di Chrome sperimentano le destinazioni più popolari del web.» Vai alla citazione
Google — laboratorio, campo e dati usati per il posizionamento
- “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).» Vai alla citazione
- “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.» Vai alla citazione
- “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à.» — Philip Walton, web.dev. Vai alla citazione
- “The data in the Chrome UX Report is a 28-day rolling average of aggregated metrics.” (traduzione) «I dati di Chrome UX Report sono una media mobile di 28 giorni di metriche aggregate.» Vai alla citazione
- “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.» — Google Search Central, documentazione sull’esperienza sulle pagine. Vai alla citazione
John Mueller, Google (tramite fonti secondarie)
- “It is a ranking factor, and it’s more than a tie-breaker, but it also doesn’t replace relevance.” (traduzione) «È un fattore di posizionamento ed è più di un criterio di spareggio, ma non sostituisce la pertinenza.» Riferito ai Core Web Vitals come segnale di posizionamento. Leggi la copertura
- “it’s not going to make your site’s rankings jump up.” (traduzione) «non farà balzare in alto il posizionamento del tuo sito.» Nel contesto dell’aggiornamento della documentazione sull’esperienza sulle pagine del marzo 2024. Leggi la copertura
Strumenti per le prestazioni web: scheda rapida
I tre strumenti in sintesi
| Strumento | Tipo di dati | Fonte dei dati | Caso d’uso ideale | Come accedervi |
|---|---|---|---|---|
| Google Lighthouse | Laboratorio (simulato) | Un singolo audit su un dispositivo con throttling (4G lenta, CPU rallentata 4×) | Diagnosticare che cosa correggere; rilevare regressioni in CI | Chrome DevTools, CLI, modulo Node, all’interno di PSI |
| PageSpeed Insights | Entrambi (laboratorio + campo) | Lighthouse (laboratorio) + CrUX (campo) | Controllare i CWV degli utenti reali di un URL pubblico e la diagnostica di laboratorio | pagespeed.web.dev (soltanto URL pubblici) + API PSI |
| Chrome UX Report (CrUX) | Campo (utenti reali) | Utenti Chrome consenzienti, p75 su 28 giorni | Sapere a che punto sei per il posizionamento; analizzare le tendenze | PSI, Search Console, API CrUX, API History, BigQuery, CrUX Vis |
Dati essenziali
- Google si basa sui dati sul campo (CrUX), non sul punteggio di laboratorio. Il numero su scala centesimale di PSI non è un input di posizionamento.
- Pesi Performance di Lighthouse, per Lighthouse 10 e soggetti a versione, quindi da verificare prima di citarli: TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%. Fasce: 0–49 rosso, 50–89 arancione, 90–100 verde. Lighthouse 13.3+, maggio 2026, aggiunge una quinta categoria sperimentale, Agentic Browsing, con controlli superato/non superato separati dal punteggio su scala centesimale.
- Lighthouse non può misurare INP e usa TBT come proxy. La schermata delle metriche live di DevTools può osservare un vero INP, perché sei tu a generare l’interazione.
- CrUX riguarda soltanto Chrome e utenti consenzienti, escludendo Chrome su iOS, Edge, Safari e Firefox, usa p75, una finestra di 28 giorni e un ritardo di circa 2 giorni: servono circa ~30 giorni perché una correzione compaia.
- Soltanto circa l’11,9% di 43,66 milioni di pagine uniche di Site Audit nel mio campione di gennaio 2022 aveva una metrica CrUX; circa il 21,2% delle pagine misurate superava i CWV, secondo il mio studio Ahrefs sui dati CWV.
- Dashboard CrUX ritirata nel novembre 2025 → usa CrUX Vis (
cruxvis.withgoogle.com). - Campo per la valutazione, laboratorio per la diagnosi. Intero sito → Search Console; singoli URL → PSI; pagine protette da accesso → Lighthouse in DevTools.
Errori nella misurazione delle prestazioni web
Presentare un punteggio Lighthouse come input di posizionamento di Google
Lighthouse è uno strumento diagnostico di laboratorio. Google usa i dati CrUX sul campo per la valutazione dei Core Web Vitals, quindi descrivi il punteggio per ciò che è realmente.
Usare i dati sul campo per diagnosticare una riga di codice
CrUX indica che gli utenti reali hanno un problema, ma non la causa esatta nell’implementazione. Dopo aver individuato il segmento debole nei dati sul campo, riproduci il percorso interessato in DevTools o Lighthouse.
Confrontare condizioni di test diverse
Un’esecuzione desktop con cache calda e una mobile con cache fredda e throttling rispondono a domande diverse. Per i confronti prima/dopo, mantieni costanti strumento, posizione, profilo del dispositivo, stato della cache e percorso.
Ottimizzare l’aggregato ignorando i gruppi di pagine
Un risultato positivo a livello di origine può nascondere un template lento e uno negativo può nascondere pagine sane. Parti da una visione ampia, poi segmenta per pattern di URL ed esperienza.
Risolvere i disaccordi comuni tra gli strumenti
PageSpeed Insights mostra dati sul campo per l’origine, non per l’URL
Causa probabile: l’URL non dispone di abbastanza dati CrUX idonei. Correzione: leggi l’etichetta dell’ambito e usa i dati di origine soltanto come contesto, poi aggiungi il RUM o i gruppi di Search Console per le decisioni a livello di pagina. Conferma: il report identifica chiaramente l’ambito rappresentato da ogni valore.
Lighthouse cambia a ogni esecuzione
Causa probabile: i risultati di laboratorio variano in base a rete, CPU, cache, risposta del server e attività di terze parti. Correzione: standardizza le condizioni e confronta più esecuzioni anziché un singolo punteggio. Conferma: la stessa opportunità persiste nell’insieme delle esecuzioni.
Search Console mostra risultati scarsi mentre il test locale è buono
Causa probabile: il laboratorio locale non rappresenta dispositivi, località o percorsi più lunghi degli utenti reali. Correzione: usa il report sul campo per individuare il gruppo interessato, poi riproduci lo scenario in uno strumento diagnostico. Conferma: la traccia di laboratorio spiega il collo di bottiglia del segmento sul campo.
Una correzione è visibile in Lighthouse ma non in CrUX
Causa probabile: Lighthouse è immediato, mentre CrUX usa una finestra mobile di dati sul campo. Correzione: convalida prima con esecuzioni di laboratorio controllate e il tuo RUM, poi attendi l’aggiornamento della finestra pubblica sul campo. Conferma: il RUM migliora prima che la tendenza CrUX lo segua.
Mettiti alla prova: strumenti per le prestazioni web
Cinque domande rapide sui tre strumenti e sui dati di laboratorio rispetto a quelli sul campo. Scegli una risposta per ciascuna domanda, poi verifica.
Cronologia modifiche
Aggiornato il 20 set 2026.
Riepilogo editoriale e dettagli registrati delle modifiche.Riepilogo
Completata la verifica rigorosa dei punteggi Lighthouse nell'articolo, nella memoria e nel sidecar italiano.
Dettagli delle modifiche
-
Il punteggio numerico è ora descritto come scala centesimale, evitando di confonderlo con un codice di stato HTTP e preservando invariati significato tecnico e vincoli di pubblicazione.
Confronto completo non disponibile — non è stata archiviata alcuna istantanea precedente per questa revisione.
Aggiornato il 8 set 2026.
Riepilogo editoriale e dettagli registrati delle modifiche.Riepilogo
Creata la prima bozza italiana source-locked; la numerazione locale delle revisioni inizia dall’ordinale 1.
Dettagli delle modifiche
-
Materializzati 113 blocchi in italiano, mantenendo la cronologia della fonte come provenienza.
-
Localizzati tramite sidecar tutti i 43 campi testuali dei componenti mantenendo i rispettivi hash della fonte.
Confronto completo non disponibile — non è stata archiviata alcuna istantanea precedente per questa revisione.
Aggiornato il 18 lug 2026.
Riepilogo editoriale e dettagli registrati delle modifiche.Riepilogo
Individuata la nuova categoria sperimentale Agentic Browsing di Lighthouse (v13.3, maggio 2026), aggiunta la versione alla tabella dei pesi del punteggio Performance, precisata la formulazione sul segnale di posizionamento dei CWV e ampliata la dotazione oltre i tre strumenti principali con metriche live e tracce di DevTools, gruppi di URL in Search Console, monitoraggio sintetico e RUM privato, secondo l’addendum di ricerca del 16 luglio 2026.
Dettagli delle modifiche
-
Corretta l’affermazione obsoleta “Lighthouse ha quattro categorie, PWA è scomparsa”; Lighthouse 13.3 (maggio 2026) ha aggiunto una quinta categoria sperimentale, Agentic Browsing, con valutazioni superato/non superato separate dal punteggio Performance su scala centesimale.
-
Aggiunta alla tabella dei pesi del punteggio Performance l’indicazione esplicita della versione “Lighthouse 10”, affinché i numeri risultino verificabili e non permanenti.
-
Precisata l’affermazione sul segnale di posizionamento; Google documenta i CWV come input dei sistemi di ranking e CrUX come dataset dei report pubblici, ma nessuna fonte pubblica dimostra che un numero CrUX pubblico sia letteralmente il valore interno per pagina.
-
Aggiunta una sezione “Oltre i tre strumenti” e righe nella matrice dedicate a metriche live e tracce di Chrome DevTools, raggruppamento degli URL in Search Console, monitoraggio sintetico e RUM privato, mantenendo la struttura basata sui tre strumenti principali.
Confronto completo non disponibile — non è stata archiviata alcuna istantanea precedente per questa revisione.