Apri PageSpeed Insights, inserisci il tuo sito e trovi un numero arancione. Sotto ci sono sigle, secondi e una lista di suggerimenti. La tentazione è installare un plugin, rifare il test e sperare nel verde.
Prima di mettere mano al sito, però, conviene capire che cosa stai misurando. Un articolo che compare tardi, un menu che reagisce in ritardo e un pulsante che si sposta mentre lo tocchi sono problemi diversi. I Core Web Vitals aiutano a distinguerli: LCP riguarda il caricamento, INP la risposta alle interazioni e CLS la stabilità visiva.
Qui trovi le soglie, un metodo per leggere i report e i controlli da passare a chi sviluppa il sito. Puoi anche inserire i tuoi valori nel lettore qui sotto: ti restituisce una lista di verifiche, senza chiederti accessi o collegare servizi esterni.
Il tuo report, spiegato
Leggi i tuoi Core Web Vitals
Inserisci i valori dello stesso dispositivo e periodo. Per i dati reali usa il 75° percentile riportato da PageSpeed. Se un dato manca, lascia il campo vuoto.
Dati reali: questa URL · Mobile
Inserisci i valori del tuo report
Il lettore applica le soglie ai dati che inserisci. Non esegue una scansione del sito.
I valori restano in questa pagina: il lettore non li invia e non li salva. Il download avviene solo quando lo scegli.
Quali sono i Core Web Vitals e quali valori sono buoni
Il riferimento è il 75° percentile delle visite, separando mobile e desktop. Detto in modo semplice: almeno il 75% delle visite deve restare entro la soglia buona di ciascuna metrica. La media può nascondere le esperienze peggiori.
| Metrica | Buono | Da migliorare | Scarso |
|---|---|---|---|
| LCP, caricamento | Fino a 2,5 s | Oltre 2,5 fino a 4 s | Oltre 4 s |
| INP, interazioni | Fino a 200 ms | Oltre 200 fino a 500 ms | Oltre 500 ms |
| CLS, stabilità | Fino a 0,1 | Oltre 0,1 fino a 0,25 | Oltre 0,25 |
Il CLS è un punteggio senza unità: 0,1 non significa né un decimo di secondo né il 10% della pagina. Le soglie e il metodo di valutazione sono documentati nella guida ufficiale ai Web Vitals.
Se hai LCP 2,1 secondi, INP 340 millisecondi e CLS 0,04, il punto da approfondire è la reattività. Comprimere un'altra immagine potrebbe aiutare il caricamento, ma non spiega perché il menu risponde lentamente.
PageSpeed: dati reali e test di laboratorio
PageSpeed Insights raccoglie due fotografie diverse. La sezione sull'esperienza reale usa CrUX, il Chrome User Experience Report: dati aggregati dei visitatori idonei, riferiti agli ultimi 28 giorni. La sezione di diagnosi esegue invece un test Lighthouse in condizioni simulate. Lo spiega la documentazione di PageSpeed Insights.
Il test di laboratorio serve a riprodurre un problema e valutare una modifica. I dati reali aiutano a capire che cosa stanno vivendo le persone. Un risultato ottenuto sul tuo portatile non descrive necessariamente chi apre il sito da un telefono meno potente.
Controlla anche il perimetro: stai leggendo i dati di questa URL oppure dell'origine, cioè l'insieme delle pagine sullo stesso protocollo e host? Se mancano campioni per la pagina, PageSpeed può mostrare quelli dell'origine. Se mancano anche quelli, il risultato è assenza di dati, non una bocciatura.
Andrè, ma ho 100 su PageSpeed e Search Console segnala ancora problemi?
Può succedere. Il punteggio Performance di Lighthouse non è l'esito dei Core Web Vitals sul campo. Prima di confrontarli, controlla dispositivo, URL o origine e periodo. Se hai pubblicato una correzione stamattina, la finestra dei dati reali contiene ancora visite precedenti.
Da dove partire per misurare il tuo sito
Scegli alcune pagine che rappresentano davvero il sito: una guida, una categoria, una pagina prodotto o il modulo da cui arrivano le richieste. Limitarsi alla home può lasciare fuori il template che usano quasi tutti i visitatori.
- Apri PageSpeed Insights. Analizza una URL e separa i risultati mobile da quelli desktop.
- Annota fonte e perimetro. Scrivi se i valori vengono da CrUX o dal test locale e se descrivono la pagina o l'origine.
- Guarda la metrica problematica. Registra il valore, la data e il template interessato. Conserva il report per il confronto successivo.
- Riproduci il comportamento. Apri il menu, usa i filtri, scorri e prova i passaggi principali. Una schermata appena caricata racconta solo una parte della visita.
Per individuare la causa, il pannello Performance di Chrome DevTools permette di registrare ciò che accade durante caricamento e interazioni. Chi segue lo sviluppo può usare quella registrazione per risalire all'elemento o allo script coinvolto.
Un esempio di appunto utile: “pagina prodotto, mobile, apertura del selettore taglia, pulsante visibile ma risposta in ritardo”. È molto più semplice da riprodurre di “il sito è lento”.
LCP alto: quando il contenuto principale arriva tardi
Il Largest Contentful Paint misura quando viene visualizzato l'elemento di contenuto più grande nell'area visibile iniziale. Può essere un'immagine o un blocco di testo. Non coincide con il caricamento completo della pagina.
La prima verifica è identificare quell'elemento. Se è il titolo, ottimizzare alla cieca la copertina potrebbe non cambiare il risultato. Se è una foto, guarda quando il browser la scopre, quando inizia a scaricarla e quando riesce a mostrarla.
La guida Google per ottimizzare LCP distingue quattro parti: risposta iniziale del server, ritardo prima del download della risorsa, durata del download e ritardo prima della visualizzazione. Per un'immagine LCP, questi sono i controlli da cui partire:
- renderla individuabile nell'HTML iniziale;
- evitare
loading="lazy"sull'immagine che serve subito; - fornire dimensioni adeguate allo schermo e un file ottimizzato;
- controllare CSS o JavaScript che ne ritardano la comparsa;
- valutare
fetchpriority="high"per la risorsa critica, verificando l'effetto.
Immagina una copertina che pesa poco ma compare solo quando finisce un'animazione introduttiva. Ridurre ancora il file lascia intatta l'attesa dell'animazione. Il report deve aiutarti a trovare quel passaggio, prima di perdere un pomeriggio sulle impostazioni di compressione.
Se invece la risposta iniziale del server è lenta, approfondisci il Time to First Byte, o TTFB. Redirect, generazione della pagina, cache e distanza del server possono contribuire al ritardo. TTFB è una metrica di supporto, non un quarto Core Web Vital.
INP alto: il sito si vede, ma reagisce male
L'Interaction to Next Paint osserva la risposta a clic, tocchi e input da tastiera durante la visita, fino al successivo aggiornamento visivo. Il valore finale rappresenta le interazioni più lente, con un metodo che scarta alcuni casi estremi nelle visite con molte interazioni. Non è il tempo medio dei clic. Il vecchio FID è stato sostituito da INP nel marzo 2024.
Pensa a un filtro prodotti: tocchi una casella e per un momento non capisci se il sito abbia ricevuto il comando. INP riguarda quella reattività. Non misura necessariamente quanto impiega l'intera ricerca remota a completarsi. La definizione ufficiale di INP chiarisce anche che lo scorrimento, da solo, non rientra nelle interazioni misurate.
La diagnosi di un INP alto separa l'attesa prima di eseguire il codice, il lavoro svolto dal gestore dell'interazione e il tempo per aggiornare lo schermo. Bisogna capire dove si accumula il ritardo.
Controllerei JavaScript che occupa a lungo il thread principale, operazioni pesanti avviate al clic e aggiornamenti troppo estesi della pagina. A seconda della causa, può servire dividere il lavoro in attività più brevi, ridurre gli script caricati o limitare gli elementi da ricalcolare. Spostare tutto al primo clic rischia semplicemente di far aspettare la persona in quel momento.
Il normale test Lighthouse di caricamento non misura INP, perché non riproduce una visita con interazioni. Mostra anche il Total Blocking Time, utile per individuare blocchi in laboratorio: non copiarlo nel campo INP. Sono misure diverse.
CLS alto: gli elementi si spostano sotto le dita
Stai per aprire un articolo e un banner spinge il titolo più in basso. Tocchi qualcos'altro. Quel tipo di spostamento inatteso è il problema osservato dal Cumulative Layout Shift.
La metrica considera gli spostamenti raggruppati in finestre di attività e usa la finestra con il punteggio maggiore. Non somma indistintamente ogni movimento della visita. Il calcolo è spiegato nella documentazione di CLS.
Spesso il controllo più utile è lo spazio riservato prima che un contenuto arrivi. Immagini senza dimensioni, pubblicità e incorporamenti possono spingere ciò che è già visibile. Anche un cambio di font può modificare gli ingombri del testo. La guida all'ottimizzazione di CLS propone di intervenire sulle cause effettive degli spostamenti.
Per un video incorporato, per esempio, riserva dall'inizio un riquadro con il rapporto corretto. Per le immagini, dichiara larghezza e altezza e mantieni il rapporto nelle regole responsive. Per gli annunci, progetta lo spazio anche quando la creatività arriva dopo il testo.
Non fermarti al caricamento. Scorri una guida lunga e osserva che cosa accade quando entrano in scena video, widget o nuove sezioni. Un test breve può non incontrare lo spostamento che disturba chi legge per diversi minuti.
Come usare il report di Search Console
Il report Segnali web essenziali di Google Search Console raggruppa URL con un'esperienza simile e separa mobile e desktop. La pagina mostrata come esempio serve a indagare il gruppo: il suo risultato PageSpeed può differire dai valori aggregati.
Partirei dai problemi classificati come scarsi e dai gruppi che coinvolgono pagine importanti. Se il difetto appartiene al template prodotto, correggere un singolo prodotto difficilmente basta. La guida ufficiale al report descrive gruppi, stati e procedura di convalida.
Dopo l'intervento, prova alcune URL rappresentative. Quando la correzione è pronta, avvia la convalida del problema nel report. Il riscontro sul campo richiede nuove visite e tempo: non aspettarti che tutte le etichette cambino insieme al deploy.
Quale problema correggere per primo
Metterei insieme gravità, diffusione e importanza della pagina. Un menu quasi inutilizzabile sulle schede prodotto può meritare attenzione prima di una piccola ottimizzazione su una pagina consultata raramente.
Considera questo esempio inventato per illustrare il metodo:
| Situazione | Controllo iniziale |
|---|---|
| Guide: LCP 4,6 s, immagine iniziale tardiva | Individuare quando parte il download e cosa ne ritarda la visualizzazione |
| Prodotti: INP 620 ms, selettore variante bloccato | Registrare l'interazione e individuare il lavoro che occupa il browser |
| Categoria: CLS 0,18, banner inserito sopra l'elenco | Verificare lo spazio riservato al banner |
Se le pagine prodotto generano le richieste commerciali, comincerei dal selettore. Se quasi tutti gli ingressi arrivano sulle guide, darei molto peso anche al loro caricamento. I valori orientano la scelta; per ordinare gli interventi servono anche le pagine coinvolte e il loro uso.
Con WordPress, prima di aggiungere un plugin di ottimizzazione, riproduci il problema in una copia di prova. Cambia una configurazione alla volta e verifica menu, moduli e acquisti. Ritardare uno script può migliorare un test e rompere una funzione: il numero da solo non chiude il lavoro.
Quanto contano i Core Web Vitals per la SEO
Google utilizza i Core Web Vitals nei suoi sistemi di ranking, ma raggiungere valori buoni non garantisce le prime posizioni. La documentazione sull'esperienza sulle pagine invita a considerarli insieme agli altri aspetti della qualità.
Un contenuto veloce che non risponde alla domanda resta poco utile. E se la pagina non compare perché è esclusa dall'indice, il controllo da fare riguarda l'indicizzazione Google. Sono diagnosi da tenere distinte.
Evita anche di attribuire un aumento di traffico alla sola velocità se nello stesso periodo hai cambiato titoli, contenuti e collegamenti. Registra le modifiche: potrai valutare il risultato con più criterio.
Come capire se la correzione ha funzionato
Conserva una scheda con URL, dispositivo, fonte del dato, valore iniziale e modifica eseguita. Ripeti la stessa prova in condizioni comparabili, controllando più esecuzioni. Prova anche la funzione interessata: un filtro deve continuare a filtrare.
Poi osserva i dati delle nuove visite. Il laboratorio può darti un primo riscontro rapido; CrUX aiuta a verificare l'effetto sul campo mentre la finestra di 28 giorni si aggiorna. Se hai pochi campioni, puoi valutare un sistema di misurazione dei visitatori reali: la libreria web-vitals di Google è una delle basi tecniche disponibili. La raccolta e la gestione dei dati vanno progettate per il tuo sito.
Per iniziare, scegli una pagina importante e annota il problema che riesci a riprodurre. Affianca a quel problema il valore corretto, LCP, INP oppure CLS, e passa alla prima verifica. Una causa identificata bene vale più di cinque plugin attivati insieme.
Fonti ufficiali ricontrollate il 13 settembre 2026. Gli esempi numerici sono illustrativi e non rappresentano misurazioni di questo sito o risultati ottenuti per clienti.
Commenti
Hai una domanda o un’esperienza utile? Scrivila qui.
Ricevuto
In attesa di pubblicazione
Il commento è stato inviato. In questa pagina ne vedi un’anteprima finché non viene controllato.
Ultimi interventi
Non ci sono ancora commenti. Puoi aprire tu la discussione.