PageSpeed Insights (PSI)

TL;DR — PageSpeed Insights (PSI) è uno strumento gratuito di Google che valuta una pagina in due modi diversi: come visitatori reali l’hanno effettivamente vissuta (dati sul campo), e come è andato un singolo test simulato (il punteggio di laboratorio 0–100). Il numero 0–100 è quello su cui tutti si fissano — e non è ciò che Google usa per il ranking. Quindi niente panico per un punteggio rosso.

Cos’è PageSpeed Insights

PageSpeed Insights si trova su pagespeed.web.dev. È gratuito, non richiede login e funziona su qualsiasi URL pubblico — inclusi quelli dei tuoi concorrenti. Incolli un URL e testa sia mobile che desktop (mobile è la scheda predefinita e i punteggi mobile sono quasi sempre più bassi).

Le due cose che PSI ti mostra

Questa è la parte che confonde tutti, quindi la tengo semplice. PSI mostra due report separati per la stessa pagina:

1. Dati sul campo — cosa hanno vissuto le persone reali. Questi provengono dal Chrome UX Report (CrUX), ovvero utenti Chrome reali che visitano la tua pagina negli ultimi 28 giorni. È la sezione etichettata “Discover what your real users are experiencing.” (Traduzione) : «Scopri cosa stanno vivendo i tuoi utenti reali.» È qui che ottieni la Core Web Vitals Assessment — un semplice Passed o Failed.
2. Dati di laboratorio — un test simulato. PSI esegue anche Google Lighthouse una volta, su un telefono e una rete simulati, e produce il punteggio Performance 0–100 più un elenco di correzioni suggerite.

L’unica cosa da ricordare

Il punteggio 0–100 non è un fattore di ranking. Google classifica in base ai Core Web Vitals sul campo — Largest Contentful Paint, Interaction to Next Paint e Cumulative Layout Shift, misurati da utenti reali. Il punteggio di laboratorio 0–100 è un numero separato da un sistema separato. Puoi ottenere un 72 e comunque superare i Core Web Vitals.

Altre cose che mettono in difficoltà le persone:

• Il punteggio cambia ogni volta che lo esegui. È un test simulato, quindi il numero oscilla. Eseguilo alcune volte e non dare peso a una variazione di 3–5 punti.
• Non ti serve un 100. Quasi nessuno ottiene 100. Punta a superare i Core Web Vitals, non a raggiungere un numero perfetto.
• Un buon punteggio non garantisce una pagina veloce per gli utenti reali, e un punteggio “brutto” non significa che gli utenti reali stiano soffrendo.

Onestamente, a meno che il tuo sito non sia davvero lento, non è da qui che inizierei. Vuoi la ripartizione completa — campo vs. laboratorio, le soglie p75, i fallback dei dati e come PSI differisce da Lighthouse e Search Console? Passa alla scheda Advanced.

TL;DR — PSI (pagespeed.web.dev) riporta due analisi indipendenti di un URL: dati sul campo dal Chrome UX Report — utenti reali su un periodo mobile di 28 giorni, che guidano la Core Web Vitals Assessment Passed/Failed al 75° percentile — e dati di laboratorio, una singola esecuzione di Lighthouse che fornisce il punteggio Performance 0–100 più diagnostica. Il punteggio 0–100 è un dato di laboratorio e non è un fattore di ranking; il ranking usa i Core Web Vitals sul campo (LCP/INP/CLS). I dati sul campo richiedono abbastanza campioni CrUX (a livello di URL, con fallback a livello di origine, altrimenti “No data”). Anche il punteggio di laboratorio è variabile da esecuzione a esecuzione — eseguilo alcune volte. PSI è la UI web; Lighthouse è il motore; il report di Search Console è un’altra vista CrUX.

PSI è due strumenti in un unico involucro

La cosa più importante da capire su PageSpeed Insights è che non è un’analisi — sono due, presentate in un’unica interfaccia. web.dev lo dice chiaramente: “PSI is a tool that reports field data from CrUX and lab from Lighthouse for a given page.” (Traduzione) : «PSI è uno strumento che riporta dati sul campo da CrUX e dati di laboratorio da Lighthouse per una data pagina.» Quelle due metà provengono da sistemi diversi, misurano cose diverse e contano per ragioni diverse. Confondile e quasi ogni domanda su PSI diventa confusa; tienile separate e tutto torna.

Dati sul campo: cosa hanno sperimentato gli utenti reali

La sezione superiore — « Discover what your real users are experiencing » (Traduzione) : « Scopri cosa stanno vivendo i tuoi utenti reali » — è alimentata dal Chrome UX Report (CrUX). web.dev descrive l’API CrUX come capace di fornire « low-latency access to aggregated real-user experience data at page and origin granularity » (Traduzione) : « accesso a bassa latenza a dati aggregati sull’esperienza degli utenti reali con granularità di pagina e di origine », sotto forma di « 28-day rolling average. » (Traduzione) : « media mobile di 28 giorni ». PSI si aggiorna quotidianamente; il dataset CrUX su BigQuery viene pubblicato ogni mese.

Alcuni meccanismi che contano:

• La valutazione Core Web Vitals è Superato/Non superato al p75. Secondo la documentazione di Chrome, « to pass, the percentile must be categorized as ‘good’ in all three Core Web Vitals. Otherwise, the assessment appears as ‘failed’. » (Traduzione) : « Per superare la valutazione, il percentile deve essere classificato come “buono” in tutti e tre i Core Web Vitals; in caso contrario, la valutazione risulta “non superata”. » I tre sono Largest Contentful Paint (buono < 2,5 s), Interaction to Next Paint (buono < 200ms) e Cumulative Layout Shift (buono < 0,1). PSI mostra anche FCP e TTFB come « Other metrics » (Traduzione) : « Altre metriche » — informative, ma escluse dal verdetto.
• C’è un’eccezione documentata, ed è solo per INP. Se una pagina non ha abbastanza campioni CrUX per riportare specificamente INP, la guida attuale di PSI dice che può comunque valutare Superato/Non superato solo dai buoni valori p75 di LCP e CLS. Non esiste un’eccezione equivalente per LCP o CLS — se uno di questi è quello a cui mancano abbastanza dati, non interpretarlo come un superamento; dati insufficienti non sono un lasciapassare documentato su nessuna metrica tranne INP.
• p75 significa 75° percentile. Il valore mostrato è quello rispetto al quale il 75% delle visualizzazioni di pagina è stato più veloce. web.dev ha scelto il 75° percentile affinché la misura fosse « resistant to outliers » (Traduzione) : « resistente ai valori anomali » — un obiettivo più rigoroso della mediana.
• INP ha sostituito FID a marzo 2024. Se stai guardando vecchi screenshot o vecchie guide (incluso il mio vecchio articolo Ahrefs su PageSpeed Insights e Core Web Vitals), potrebbero mostrare ancora FID; la valutazione ora usa INP.
• URL → origine → fallback “Nessun dato”. Se non ci sono abbastanza dati CrUX per lo specifico URL, PSI ripiega su dati a livello di origine (aggregati su tutto il sito). Se non ci sono affatto dati CrUX, vedrai “No data,” (Traduzione) : « Nessun dato », ma Lighthouse viene comunque eseguito. Come nota web.dev, « CrUX data is only available when sites meet certain eligibility criteria » (Traduzione) : « I dati CrUX sono disponibili soltanto quando i siti soddisfano determinati criteri di idoneità », e « PSI is only available for public URLs. » (Traduzione) : « PSI è disponibile soltanto per URL pubblici. » Pagine a basso traffico e pagine appena create spesso non hanno dati sul campo a livello di URL.

Leggi l’etichetta dell’ambito prima di scrivere il risultato. CrUX a livello di URL descrive il campione di campo idoneo attribuito a quell’URL. Il fallback a livello di origine è un segnale utile a livello di sito, ma non può diagnosticare da solo la pagina testata. “Nessun dato” significa che il campione di campo non è disponibile o è insufficiente—non che la pagina sia superata, non superata, o che non abbia ricevuto traffico. Il risultato Lighthouse qui sotto può ancora diagnosticare quella esecuzione di laboratorio controllata, ma non colma il divario dei dati sul campo mancanti.

Dati di laboratorio: il punteggio Lighthouse 0–100

La sezione inferiore è una singola esecuzione Lighthouse su un dispositivo e una rete simulati, che produce il punteggio Performance e un elenco di opportunità e diagnostica. La classificazione di Google: « A score of 90 or above is considered good. 50 to 89 is a score that needs improvement, and below 50 is considered poor. » (Traduzione) : « Un punteggio pari o superiore a 90 è considerato buono; da 50 a 89 richiede miglioramenti, mentre sotto 50 è considerato scarso. »

Cosa sapere sull’esecuzione di laboratorio:

• È simulato e l’esecuzione mobile è volutamente lenta. Il mobile emula un telefono di fascia media su una connessione limitata; il desktop usa un profilo emulato più veloce. Ecco perché il tuo punteggio mobile è quasi sempre più basso di quello desktop — e perché i dati di campo degli utenti reali spesso appaiono migliori di quanto suggeriscano le diagnosi di laboratorio.
• Il punteggio è variabile. Ogni esecuzione è un audit Lighthouse fresco lato server — la pagina, il datacenter di Google, le condizioni di rete e persino la versione di Chrome/Lighthouse possono spostare il numero tra un’esecuzione e l’altra. Consiglio di eseguirlo alcune volte (3–5) e di guardare l’intervallo piuttosto che trattare una singola esecuzione come verità assoluta. Qualche punto di oscillazione è rumore.
• Se confronti le esecuzioni, salva più del punteggio. La risposta dell’API include un timestamp, l’URL richiesto e finale, il fattore di forma, l’ambiente emulato, la versione di Lighthouse ed eventuali avvisi — conservali insieme a ciascun punteggio. Due “72” non sono confrontabili se uno è stato eseguito su una versione diversa di Lighthouse o ha incontrato un reindirizzamento che l’altro non ha avuto. Non fare la media di punteggi non etichettati; etichettali o non confrontarli.
• Le versioni di Lighthouse si muovono indipendentemente dall’API PSI. PSI è rimasto sull’API v5, ma il motore Lighthouse sottostante continua a pubblicare nuove release (la più recente menzionata nelle note di rilascio di Google al momento di questa recensione è Lighthouse 13.0, datata 2025-10-20) — i campi di audit, i pesi e le fasce possono cambiare con la versione del motore anche se il contratto API non cambia.
• Gli « Estimated savings » (Traduzione) : « risparmi stimati » non sono additivi. I secondi mostrati accanto a ciascuna diagnosi presuppongono che quella correzione venga fatta in isolamento. I problemi interagiscono; i guadagni nel mondo reale sono quasi sempre inferiori alla somma delle singole stime. Trattali come indicativi, non come un budget che puoi sommare.
• I pesi delle metriche cambiano con le versioni di Lighthouse. Il punteggio Performance è una combinazione ponderata di metriche di laboratorio (le metriche di tempo di caricamento, il Total Blocking Time e il CLS hanno il peso maggiore), ma i pesi esatti cambiano tra le release di Lighthouse — controlla la calcolatrice di punteggio attuale piuttosto che fidarti di una suddivisione fissa.

Il mito che causa più danni: “il punteggio è un fattore di ranking”

Non lo è. Il punteggio Performance da 0 a 100 è un numero di laboratorio di Lighthouse, e non ho trovato alcuna fonte ufficiale attuale di Google Search che documenti quel punteggio stesso come input di ranking o che colleghi un cambio di punteggio a un cambio di ranking. La documentazione di Google sull’esperienza di pagina punta invece ai Core Web Vitals sul campo — dati di utenti reali basati su CrUX, lo stesso tipo di dati che la sezione sul campo di PSI mostra al p75. (Una precisazione importante: la visualizzazione pubblica dei dati sul campo di PSI è una superficie di reporting con proprie regole di idoneità e fallback; Google non ha pubblicato l’esatta pipeline interna che alimenta il ranking, quindi tratta i “dati di campo” come lo stesso tipo di segnale piuttosto che assumere un’identità byte-per-byte con ciò che PSI ti mostra.) Una pagina può essere a 72 in laboratorio e comunque superare la valutazione Core Web Vitals perché i suoi dati di utenti reali sono buoni — numeri diversi da sistemi diversi. Il mito correlato — « a good lab score equals a good real-user experience » (Traduzione) : « un buon punteggio di laboratorio equivale a una buona esperienza degli utenti reali » — fallisce per lo stesso motivo: le condizioni di laboratorio non sono quelle dei visitatori. Quando i dati sul campo e quelli di laboratorio divergono, i dati sul campo sono i più rilevanti per la SEO.

Anche i Core Web Vitals sul campo sono un segnale di ranking piuttosto debole. Gli stessi dipendenti di Google li hanno ridimensionati — Gary Illyes ha definito l’esperienza di pagina più vicina a un criterio di spareggio che a un segnale importante. La mia posizione onesta non è cambiata: non credo che i Core Web Vitals abbiano molto impatto sulla SEO e, a meno che un sito non sia estremamente lento, in genere non darò priorità alla loro correzione rispetto a contenuti e link. Correggili per gli utenti e per il caso davvero lento — non per il panico dovuto a un numero rosso.

Come leggere davvero un report PSI

1. Leggi prima i dati sul campo. Ha superato (Pass) o fallito (Fail) la valutazione Core Web Vitals? Questo è il verdetto rilevante per la SEO. Se dice “No data”, non c’è ancora abbastanza traffico CrUX — stai lavorando solo con dati di laboratorio.
2. Controlla separatamente mobile e desktop. Il mobile è l’impostazione predefinita e di solito il più debole; è anche quello che conta di più, poiché Google indicizza con priorità al mobile.
3. Poi usa le diagnostiche di laboratorio per trovare la causa. I dati di laboratorio sono il tuo ciclo di feedback rapido per trovare e correggere il problema di fondo — risorse che bloccano il rendering, immagini sovradimensionate, fonti di spostamento del layout, attività lunghe.
4. Correggi, poi attendi. I dati sul campo si basano su una finestra mobile di 28 giorni, quindi una correzione pubblicata oggi può richiedere fino a 28 giorni per apparire completamente nella valutazione Core Web Vitals. Usa i dati di laboratorio per confermare subito la correzione; usa i dati sul campo per confermare che ha effettivamente inciso sugli utenti reali.
5. Confronta i concorrenti. Poiché PSI funziona su qualsiasi URL pubblico, puoi eseguire le pagine di un concorrente e confrontare i loro Core Web Vitals sul campo con i tuoi — un caso d’uso che la maggior parte delle guide non menziona mai.

PSI e gli strumenti con cui viene confuso

• PSI vs. Lighthouse. Lighthouse è il motore; PSI è un’interfaccia web che esegue Lighthouse e sovrappone i dati sul campo CrUX. Se esegui Lighthouse da solo (in Chrome DevTools o tramite CLI), ottieni l’audit di laboratorio ma sulla tua macchina e rete, senza dati sul campo.
• PSI vs. report Core Web Vitals di Search Console. Entrambi si basano su CrUX, quindi entrambi riflettono utenti reali. La differenza: Search Console raggruppa URL simili e riporta su larga scala per l’intera proprietà, mentre PSI è per singolo URL (o con fallback a livello di origine). Se GSC e PSI sembrano discordare, di solito è il raggruppamento.
• PSI vs. Chrome DevTools / WebPageTest / DebugBear / Ahrefs Site Audit. Questi offrono più configurazione (dispositivi personalizzati, posizioni, throttling) e, in alcuni casi, monitoraggio degli utenti reali. Il punto di forza di PSI è essere gratuito, senza configurazione e legato al dataset CrUX di Google.

L’API PSI (per test in batch)

Non devi usare l’interfaccia web un URL alla volta. L’API PageSpeed Insights (base https://www.googleapis.com/pagespeedonline/v5) restituisce gli stessi dati in modo programmatico. Parametri chiave: url (obbligatorio), strategy (mobile o desktop) e category (performance, accessibility, best-practices, seo). La risposta si divide come nell’interfaccia: loadingExperience (dati sul campo a livello di URL), originLoadingExperience (dati sul campo a livello di origine) e lighthouseResult (l’audit di laboratorio). È così che testeresti un batch di URL secondo una pianificazione, invece di cliccarli manualmente.

Non costruire automazione duratura sui dati sul campo con questa API. La documentazione API di Google ora si apre con un avviso che prevede di interrompere l’inclusione dei dati reali CrUX nell’API PSI e indirizza chi automatizza verso l’API CrUX API o CrUX History API dedicate. Continua a usare l’API PSI per l’audit di laboratorio Lighthouse — quella parte non è interessata — ma se pianifichi estrazioni batch di dati sul campo, sviluppa su un’API specifica per CrUX, non su loadingExperience/originLoadingExperience nella risposta PSI.

Dove si colloca nelle prestazioni web

PSI è uno strumento di misurazione, non la destinazione. Le metriche che mostra — Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift — sono i Core Web Vitals, e l’hub per queste (soglie, significato di ciascuna e come migliorarle) è il posto giusto dove andare dopo. Lighthouse è il motore di laboratorio su cui gira PSI; CrUX (il Chrome UX Report) è la fonte dei dati sul campo che alimenta la parte superiore di ogni report PSI. Comprendi questi tre elementi e PSI smette di essere una scatola misteriosa.

Riepilogo AI

Una sintesi della versione Advanced:

• PSI = due strumenti in un’unica interfaccia. Dati sul campo dal Chrome UX Report (utenti reali) e dati di laboratorio da una singola esecuzione di Lighthouse, per lo stesso URL, su pagespeed.web.dev. Gratuito, senza login, qualsiasi URL pubblico, mobile + desktop.
• I dati sul campo guidano la valutazione dei Core Web Vitals — Superato/Non superato, al 75° percentile, su LCP (<2,5 s), INP (<200ms) e CLS (<0,1). Finestra mobile di 28 giorni, aggiornata quotidianamente. FCP e TTFB sono mostrati ma non contano per il verdetto.
• I dati di laboratorio sono il punteggio di prestazione 0–100 (90+ buono, 50–89 da migliorare, <50 scarso) più diagnostica. Il mobile è limitato e ottiene punteggi inferiori al desktop.
• Il punteggio 0–100 NON è documentato come fattore di ranking. I sistemi di ranking di Google utilizzano i Core Web Vitals sul campo (dati reali basati su CrUX — lo stesso tipo di dati che la sezione sul campo di PSI mostra, sebbene Google non abbia pubblicato la pipeline interna esatta come identica alla visualizzazione pubblica di PSI). Una pagina può ottenere 72 e superare comunque i CWV — numeri diversi da sistemi diversi.
• Fallback CrUX: livello URL → livello origine → “Nessun dato” (Lighthouse viene comunque eseguito). Le pagine a basso traffico e le nuove pagine spesso non hanno dati sul campo a livello URL.
• Il punteggio è variabile da un’esecuzione all’altra — esegui 3–5 volte. I “risparmi stimati” non sono additivi. Non hai bisogno di 100.
• Leggi prima i dati sul campo (Superato/Non superato), poi usa la diagnostica di laboratorio per trovare la causa; pubblica la correzione, poi attendi fino a 28 giorni perché i dati sul campo la riflettano.
• PSI vs. Lighthouse (motore vs. interfaccia+dati sul campo) e vs. report CWV di Search Console (anche CrUX, ma raggruppato su larga scala). I CWV sono complessivamente un input di ranking minore.

Documentazione ufficiale

Documentazione di fonti primarie di Google e dei team Chrome / web.dev.

Google / PageSpeed Insights

• Strumento PageSpeed Insights — lo strumento stesso.
• API PageSpeed Insights — Informazioni — cosa fa PSI, i due tipi di dati e le fasce di punteggio 0–100.
• API PSI — riferimento runPagespeed — parametri (url, strategy, category) e struttura della risposta.

Chrome UX Report (la fonte dei dati sul campo)

• Usare CrUX in PageSpeed Insights — come funziona la sezione sul campo e la valutazione Superato/Non superato.
• Metodologia CrUX — idoneità, adesione e quali pagine sono incluse.
• API CrUX — la media mobile di 28 giorni che alimenta i dati sul campo di PSI.
• Panoramica CrUX — come CrUX alimenta il segnale di ranking dell’esperienza di pagina.

web.dev / Core Web Vitals

• Quali sono gli strumenti per i Core Web Vitals? — dove si colloca PSI tra gli strumenti CrUX/Lighthouse.
• Core Web Vitals — le soglie LCP/INP/CLS e la regola del 75° percentile.
• Definire le soglie dei Core Web Vitals — perché p75.
• Core Web Vitals e Ricerca Google — il contesto del segnale di ranking.

Citazioni dalla fonte

Dichiarazioni testuali, ciascuna collegata al relativo passaggio nella pagina di origine.

Google / Chrome / web.dev — come funziona PSI

• « PSI is a tool that reports field data from CrUX and lab from Lighthouse for a given page. » (Traduzione) : « PSI è uno strumento che riporta, per una determinata pagina, dati sul campo provenienti da CrUX e dati di laboratorio provenienti da Lighthouse. » — web.dev. Vai alla citazione
• « PSI is only available for public URLs. It cannot be used on development sites that are not publicly accessible. » (Traduzione) : « PSI è disponibile soltanto per URL pubblici e non può essere usato su siti di sviluppo non accessibili pubblicamente. » — web.dev. Vai alla citazione
• La sezione dei dati sul campo è descritta come « Discover what your real users are experiencing. » (Traduzione) : « Scopri cosa stanno vivendo i tuoi utenti reali. » — Documentazione Chrome, CrUX in PSI. Vai alla citazione
• « To pass, the percentile must be categorized as ‘good’ in all three Core Web Vitals. Otherwise, the assessment appears as ‘failed’. » (Traduzione) : « La valutazione viene superata soltanto se il percentile è classificato come “buono” per tutti e tre i Core Web Vitals; diversamente, risulta “non superata”. » — Documentazione Chrome, CrUX in PSI. Vai alla citazione
• L’API CrUX offre « low-latency access to aggregated real-user experience data at page and origin granularity » (Traduzione) : « accesso a bassa latenza a dati aggregati sull’esperienza degli utenti reali con granularità di pagina e di origine », sotto forma di « 28-day rolling average. » (Traduzione) : « media mobile di 28 giorni. » — Documentazione Chrome, API CrUX. Vai alla citazione

web.dev — soglie

• « a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices. » (Traduzione) : « Una buona soglia di misurazione è il 75° percentile dei caricamenti di pagina, segmentato tra dispositivi mobili e desktop. » — web.dev, Core Web Vitals. Vai alla citazione
• « if at least 75 percent of page views to a site meet the ‘good’ threshold, the site is classified as having ‘good’ performance. » (Traduzione) : « Se almeno il 75 per cento delle visualizzazioni di pagina di un sito soddisfa la soglia “buona”, il sito viene classificato come dotato di prestazioni “buone”. » — web.dev, definizione delle soglie. Vai alla citazione

Settore — distinzione tra punteggio e ranking (citazioni riportate, non dichiarazioni di Google)

• « The Performance score on PageSpeed Insights does not impact SEO directly. However, the real-user Core Web Vitals assessment does impact Google rankings. » (Traduzione) : « Il punteggio Performance di PageSpeed Insights non influisce direttamente sulla SEO; la valutazione dei Core Web Vitals basata su utenti reali influisce invece sul ranking di Google. » — Matt Zeunert, DebugBear. Fonte
• « Core Web Vitals are the only metrics Google explicitly uses for grading. » (Traduzione) : « I Core Web Vitals sono le sole metriche che Google dichiara esplicitamente di usare per la valutazione. » E « Running the same URL just minutes apart can yield different scores. » (Traduzione) : « Eseguire lo stesso URL a pochi minuti di distanza può produrre punteggi diversi. » — Ryan Sullivan, SiteCare. Fonte

Cheat sheet del report PSI

Ogni sezione PSI: campo vs. laboratorio, e cosa significa

Soglie “good” dei Core Web Vitals (campo, p75)

Fasce di punteggio Lighthouse (laboratorio)

• 90–100 — buono · 50–89 — da migliorare · <50 — scarso

Fallback dei dati sul campo

• CrUX a livello di URL → se non bastano, a livello di origine → se nessuno, “Nessun dato” (Lighthouse viene comunque eseguito).

Fatti rapidi

• I dati sul campo = 28 giorni mobili, aggiornati quotidianamente → una correzione può richiedere fino a 28 giorni per essere visibile.
• Il punteggio 0–100 è variabile — esegui 3–5 volte, ignora una variazione di 3–5 punti.
• I “risparmi stimati” non si sommano — presuppongono che ogni correzione venga fatta singolarmente.
• La scheda Mobile è quella predefinita e di solito ottiene un punteggio inferiore rispetto al desktop.
• INP ha sostituito FID a marzo 2024.

Strumenti attorno a PSI

• PageSpeed Insights (pagespeed.web.dev) — lo strumento stesso: dati sul campo (CrUX) + dati di laboratorio (Lighthouse), mobile e desktop, qualsiasi URL pubblico.
• Google Lighthouse — il motore di laboratorio che PSI esegue. Eseguilo localmente in Chrome DevTools (pannello Lighthouse) o tramite CLI per l’audit di laboratorio sul tuo dispositivo/rete (senza dati sul campo).
• Google Search Console — Report Core Web Vitals — l’altra visualizzazione basata su CrUX; raggruppa URL simili e riporta i dati sul campo dell’intera proprietà.
• CrUX Vis / CrUX API / BigQuery — vai direttamente ai dati sul campo dietro PSI per le tendenze nel tempo. (La vecchia CrUX Dashboard in Looker Studio è stata deprecata alla fine di novembre 2025 — le note di rilascio di Google e il suo post dedicato alla deprecazione confermano entrambi la data e indicano CrUX Vis (cruxvis.withgoogle.com) come sostituto. Se una guida ti dice ancora di usare la Dashboard, è obsoleta.)
• PSI API — test in blocco di molti URL in modo programmatico (url, strategy, category); la risposta si divide in loadingExperience, originLoadingExperience, e lighthouseResult. Google ha annunciato che intende interrompere l’inclusione dei dati reali degli utenti CrUX in questa API e ora raccomanda la CrUX API dedicata o la CrUX History API per l’automazione duratura dei dati sul campo — non costruire una pipeline che presuppone che gli oggetti sul campo dell’API PSI rimangano a lungo termine.
• Ahrefs Site Audit e WebPageTest / DebugBear — più configurazione e, in alcuni casi, monitoraggio reale degli utenti oltre una singola esecuzione di Lighthouse.

Errori di PageSpeed Insights che distorcono le priorità

• Trattare il punteggio 0–100 come un fattore di ranking. Il punteggio è una singola esecuzione di laboratorio di Lighthouse. La valutazione Core Web Vitals rilevante per il ranking proviene dai dati sul campo CrUX.
• Leggere il fallback dell’origine come prestazione dell’URL. Quando un URL manca di campioni sufficienti, PSI può mostrare dati a livello di origine. Controlla l’etichetta dell’ambito prima di affermare che la pagina stessa ha superato o fallito.
• Reagire a una singola esecuzione di laboratorio. La risposta del server e l’ambiente sintetico variano. Ripeti esecuzioni corrispondenti e usa l’intervallo o la mediana per distinguere il segnale dal rumore.
• Sommare i risparmi delle opportunità. Le stime degli audit si sovrappongono e presuppongono che ogni correzione avvenga in modo indipendente. Trattali come indizi direzionali, non come un totale promesso.
• Aspettarsi che una distribuzione cambi immediatamente i dati sul campo. CrUX è una vista mobile di 28 giorni. Usa la sezione di laboratorio per la diagnosi immediata e la sezione sul campo per la conferma nel tempo.
• Confrontare i punteggi mobile e desktop come se le condizioni fossero uguali. Valuta ogni profilo rispetto a se stesso e al tuo pubblico, piuttosto che trattare i numeri come un’unica scala.

PSI dice “Nessun dato”

Sintomo: La sezione sul campo non ha risultati CrUX, ma il report Lighthouse viene eseguito.

Causa probabile: L’URL e l’origine non soddisfano i requisiti di idoneità o volume di campioni di CrUX, oppure la pagina è nuova o ha poco traffico.

Correzione e conferma: Non inventare una conclusione sul campo. Usa la diagnostica di laboratorio per il lavoro immediato, controlla i modelli rappresentativi con traffico più alto e torna più tardi per vedere se appare un risultato sul campo a livello di URL o di origine.

PSI e Search Console non concordano

Sintomo: Un URL sembra sano in PSI mentre il suo gruppo in Search Console è scarso, o viceversa.

Causa probabile: PSI può mostrare dati a livello di URL o di origine, mentre Search Console raggruppa URL simili. Anche dispositivo, ambito e tempistica della finestra mobile possono differire.

Correzione e conferma: Confronta mobile/desktop, ispeziona l’ambito dei dati di PSI e campiona più URL dal gruppo di Search Console prima di concludere che uno dei due report è errato.

Il punteggio di laboratorio oscilla tra le esecuzioni

Sintomo: Ripetere PSI produce punteggi o valori di metrica materialmente diversi.

Causa probabile: Una risposta del server variabile, una richiesta di terze parti o il normale rumore di laboratorio di una singola esecuzione hanno modificato la traccia.

Correzione e conferma: Esegui la stessa strategia più volte, confronta le singole metriche e i waterfall delle richieste e indaga su un collo di bottiglia ripetuto piuttosto che sul punteggio da solo.

Una correzione è visibile in Lighthouse ma non nei dati sul campo

Sintomo: La metrica di laboratorio migliora immediatamente, mentre la valutazione sul campo dei Core Web Vitals rimane invariata.

Causa probabile: CrUX include ancora le visite precedenti al rilascio nella sua finestra mobile di 28 giorni, oppure la correzione non ha aiutato gli utenti e i modelli rappresentati nel dataset sul campo.

Correzione e conferma: Verifica ora la distribuzione e la traccia di laboratorio, annota la data di rilascio, quindi osserva la distribuzione sul campo attraverso l’intera finestra di reporting.

Ottieni un risultato PSI dall’API

L’API espone separatamente le sezioni sul campo e di laboratorio. Fornisci la tua chiave API e URL:

curl --get 'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode "url=$TARGET_URL" \
  --data 'strategy=mobile' \
  --data-urlencode "key=$PSI_KEY" \
  --output psi.json

Conserva la risposta grezza così che la data del test, la strategia e l’ambito dei dati rimangano verificabili.

Separa l’ambito sul campo dal punteggio di laboratorio

Con jq, estrai la categoria del campo URL, la categoria di fallback dell’origine e il punteggio Lighthouse invece di comprimerli in un unico numero:

jq '{
  url_field: .loadingExperience.overall_category,
  origin_field: .originLoadingExperience.overall_category,
  lab_score: (.lighthouseResult.categories.performance.score * 100)
}' psi.json

Un valore mancante sul campo non è uno zero; significa che quell’ambito non era disponibile nella risposta.

Ripeti l’esecuzione di laboratorio senza nascondere i campioni

for run in 1 2 3; do
  curl --silent --get 'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
    --data-urlencode "url=$TARGET_URL" \
    --data 'strategy=mobile' \
    --data-urlencode "key=$PSI_KEY" \
  | jq -r "[$run, (.lighthouseResult.categories.performance.score * 100)] | @tsv"
done

Riporta tutti i campioni o un riepilogo documentato; non selezionare solo il punteggio migliore.

Mettiti alla prova: PageSpeed Insights

Cinque domande rapide su come leggere correttamente PSI. Scegli una risposta per ciascuna, poi controlla.

Risorse che meritano il tuo tempo

I miei scritti correlati

• Google PageSpeed Insights: guida per principianti — la mia guida su Ahrefs (nota: precede il passaggio da FID a INP).
• Core Web Vitals: guida completa — dati sul campo e di laboratorio, con la mia opinione su quanto contino davvero i CWV.
• Guida introduttiva alla SEO tecnica — dove si collocano le prestazioni nel quadro più ampio.

Ufficiale

• Usare CrUX in PageSpeed Insights — la spiegazione di Chrome sulla sezione dei dati sul campo.
• Quali sono gli strumenti per i Core Web Vitals? — il rapporto tra PSI, Lighthouse, CrUX e Search Console.

Da altri

• Come usare PageSpeed Insights — Matt Zeunert (DebugBear); approfondimento tecnico su punteggio e diagnostica.
• PageSpeed Insights: lo strumento diagnostico di Google più frainteso — Ryan Sullivan (SiteCare); un’utile analisi dei miti più comuni.
• Il fattore di ranking Core Web Vitals è più di uno spareggio — Search Engine Journal contestualizza l’impatto dei CWV attraverso i commenti di Gary Illyes.
• L’aggiornamento Page Experience di Google è più di uno spareggio — Barry Schwartz riferisce come i rappresentanti di Google hanno descritto il segnale relativo all’esperienza di pagina.

Statistiche degne di citazione

• Quasi nessuno ottiene 100. Solo circa il 2% delle pagine testate raggiunge un 100 perfetto, e un punteggio di 50 ti colloca già nel top 25% — un contesto utile per chiunque sia in preda al panico per un numero sotto 90. Fonte
• I dati sul campo sono una media mobile di 28 giorni. Una correzione può richiedere fino a ~28 giorni per essere completamente riflessa nella valutazione Core Web Vitals — usa i dati di laboratorio per un feedback rapido nel frattempo. Fonte
• La soglia “buono” è il 75° percentile. Google valuta al p75 così che “una maggioranza di visite abbia sperimentato il livello di performance target” — il che significa che anche con un LCP superato di 2,5 s, un quarto dei visitatori ha atteso più a lungo. Fonte

Cronologia modifiche