Un punteggio alto su PageSpeed e un sito lento possono coesistere. Il voto riassume un test di caricamento; chi visita il sito apre anche menu, compila moduli e aspetta risposte. Prima di installare un altro plugin o cambiare hosting, individua quando compare la lentezza.
Distingui tre aspetti: pagina o origine, laboratorio o utenti reali, caricamento o interazione. La sezione Sviluppo web e prestazioni collega queste osservazioni a decisioni verificabili.
In questo articolo
Che cosa dicono il punteggio e i dati reali
Il punteggio delle prestazioni riassume una singola esecuzione di Lighthouse. Aiuta a individuare problemi e confrontare test in condizioni simili. Rete, contenuti e ambiente fanno variare il risultato: registra metriche e condizioni insieme al voto.
I dati degli utenti reali provengono da CrUX e coprono una finestra mobile di 28 giorni. Controlla se il rapporto descrive la URL o l’intera origine. Se la pagina non ha abbastanza campioni, PageSpeed può mostrare l’origine; se mancano dati anche lì, non c’è una valutazione sul campo. L’assenza di dati non equivale né a un esito positivo né a uno negativo.
Le Core Web Vitals sono LCP, INP e CLS. Al 75° percentile, le soglie buone sono rispettivamente fino a 2,5 secondi, 200 millisecondi e 0,1. Quel percentile non è una media: osserva anche la distribuzione, perché il valore aggregato può nascondere esperienze peggiori.
La documentazione di PageSpeed Insights chiarisce cosa misurano il punteggio e i dati sul campo. Consulta quelle definizioni prima di confrontare risultati diversi.
Individua quando la pagina rallenta
Il contenuto principale tarda ad apparire? Analizza il caricamento. Il menu risponde lentamente dopo che la pagina è visibile? Riproduci il clic. La ricerca reagisce al tocco ma impiega tempo a mostrare risultati? Misura la richiesta e il completamento dell’attività. Ogni sintomo richiede un’indagine diversa.
INP misura la risposta visiva a clic, tocchi e pressioni dei tasti. Da solo non copre tutta la durata di un’operazione asincrona. Un indicatore di caricamento può apparire subito mentre il server tarda a rispondere; misura anche quell’attesa.
Un TBT basso nel caricamento iniziale non esclude interazioni lente in seguito. Annota azione, dispositivo e condizioni. Usa i dati sul campo per orientare la riproduzione; se mancano, prova i percorsi più comuni.
La guida di web.dev sulle interazioni lente spiega come registrare un flusso e confrontarlo con i dati sul campo disponibili.
Un esempio misurato su questo sito in produzione
Il 1° novembre 2026 alle 00:48 CET, un test online dell’articolo su llms.txt di questo blog ha ottenuto 99 punti nella prova mobile. Il rapporto usava Lighthouse 13.6.0, un Moto G Power emulato e una rete 4G lenta simulata. Era una singola esecuzione del caricamento iniziale, non un monitoraggio dei visitatori.
Il test ha rilevato LCP di 1,1 secondi, TBT di 0 ms e CLS di 0,053. Nella sezione dedicata all’esperienza reale compariva «No hay datos». I numeri di laboratorio erano buoni in quella prova; senza dati sul campo non si può valutare l’esperienza dei visitatori.
La prima schermata mostra 99 punti nelle prestazioni mobile, altre tre valutazioni da 100 e nessun dato sul campo. L’interfaccia di PageSpeed resta nella sua lingua spagnola originale.
Questo esempio non dimostra che il sito sia lento. Mostra il limite di un voto alto: 99 non colma la mancanza di informazioni sull’uso reale. Neppure un TBT di 0 ms garantisce che menu, ricerca e moduli rispondano bene in ogni situazione.
Nonostante il 99, il rapporto segnala risorse che bloccano il rendering e stima un risparmio di 840 ms. È una stima, non un miglioramento misurato. Esamina le risorse, proponi una modifica e confronta prima e dopo. Qui è stata documentata la diagnosi; il sito non è stato modificato e non è stato misurato alcun guadagno.
La seconda schermata espande quella diagnosi. L’elenco delle risorse offre un’ipotesi di ottimizzazione da verificare, non la prova di un risparmio già ottenuto.
Registrerei la misurazione e proverei i percorsi importanti prima di inseguire l’ultimo punto. Un reclamo richiede URL, azione, dispositivo e rete per essere riproducibile. Un’altra esecuzione può dare numeri diversi: il punteggio non è permanente.
Numeri e condizioni sono nel rapporto PageSpeed online originale. Consulta quella prova prima di estenderne il risultato ad altri visitatori.
Scegli la prossima azione in base alle prove
Punteggio alto in laboratorio, esperienza sul campo scarsa: verifica che ambito e tipo di dispositivo coincidano. Poi riproduci la metrica problematica in condizioni simili a quelle dei visitatori.
Punteggio basso in laboratorio, esperienza sul campo buona: esamina diagnosi e variabilità tra test. Potrebbe esserci un’opportunità utile per dispositivi o reti più limitati. Prima di un intervento importante, individua chi ne beneficia e quale comportamento deve migliorare.
Nessun dato sul campo: usa il laboratorio per orientare l’indagine e prova le attività principali. Se serve osservare i visitatori, valuta una misurazione propria con ambito e trattamento dei dati adeguati. Fino ad allora, limita le conclusioni a ciò che è stato osservato.
Lentezza dopo il clic: registra il flusso nel pannello Performance di Chrome DevTools. Determina se l’attesa si trova prima dell’elaborazione, in JavaScript, nella visualizzazione del fotogramma successivo o nella risposta di rete.
La spiegazione di web.dev sulle differenze tra laboratorio e dati sul campo aiuta a interpretare questi casi senza confondere condizioni controllate ed esperienza completa dei visitatori.
Trasforma il reclamo in un’attività verificabile
Sostituisci «migliora PageSpeed» con un sintomo riproducibile: «Su questa URL, aprendo la ricerca da mobile, c’è una pausa prima che compaia il campo». Annota dispositivo, rete, stato di accesso e consenso e passaggi da ripetere. Non servono dati personali.
Definisci la prova attesa: registrazioni dello stesso flusso prima e dopo, in condizioni confrontabili. Individua la fase responsabile e preserva ricerca, navigazione da tastiera e integrazioni. Un voto migliore non compensa un’attività che smette di funzionare.
In laboratorio ripeti i test e registra la variabilità, senza scegliere solo il risultato migliore. Sul campo annota la data della modifica: la finestra mobile continuerà a mescolare esperienze precedenti e successive.
La guida al pannello Performance di Chrome DevTools spiega come registrare il percorso e localizzare il ritardo che inizia dopo il clic.
Quando smettere di inseguire il punteggio
Dai priorità a una correzione quando puoi collegare un sintomo a una causa e a un beneficio verificabile per il visitatore. Se le attività importanti funzionano bene e la proposta cambia solo il numero, chiedi una motivazione proporzionata a costo e rischio.
La stessa cautela vale per la SEO. Google indica di usare le Core Web Vitals nei suoi sistemi, ma buoni risultati non garantiscono le prime posizioni. La sua documentazione osserva che cercare un punteggio perfetto solo per la SEO potrebbe non essere il miglior uso del tempo.
Le indicazioni di Google sull’esperienza di pagina aiutano a capire il ruolo delle Core Web Vitals nella ricerca senza promettere posizioni.
Vuoi decidere quale problema di prestazioni indagare sul tuo sito? Scrivimi su WhatsApp indicando la URL e l’attività interessata.
Nota metodologica: ricerca documentale e un test online sul sito in produzione, con ricerca, scrittura e illustrazione assistite da IA. Non sono stati misurati miglioramenti di conversione o posizionamento né l’INP dei visitatori. La copertina è un’illustrazione basata su foto dell’autore.