I Core Web Vitals sono metriche sviluppate per descrivere aspetti concreti dell’esperienza reale: quanto rapidamente appare il contenuto principale, quanto prontamente la pagina risponde e quanto rimane stabile durante l’uso. Non misurano l’intera qualità del sito, ma trasformano alcuni problemi percepiti in dati confrontabili.
Nel febbraio 2021 le metriche principali erano LCP, FID e CLS. Dal marzo 2024 INP ha sostituito FID. Una guida aggiornata deve quindi spiegare il contesto storico senza applicare retroattivamente la metrica attuale.
LCP: caricamento del contenuto principale
Largest Contentful Paint misura quando viene visualizzato il più grande elemento di contenuto rilevante nell’area visibile, spesso un’immagine, un titolo o un blocco di testo. La soglia “buona” attuale è entro 2,5 secondi al 75º percentile.
Un LCP lento può dipendere da risposta del server, immagine hero pesante, CSS bloccante, font o rendering lato client. Bisogna identificare l’elemento LCP reale prima di applicare soluzioni generiche.
INP: reattività alle interazioni
Interaction to Next Paint valuta la latenza delle interazioni durante la visita e rappresenta la reattività complessiva. La soglia “buona” è entro 200 millisecondi al 75º percentile.
JavaScript lungo, lavoro sul thread principale, componenti pesanti e gestori inefficienti possono ritardare il feedback. Nel 2021 si utilizzava FID, limitato al ritardo della prima interazione; INP offre una visione più ampia.
CLS: stabilità visiva
Cumulative Layout Shift misura gli spostamenti imprevisti degli elementi visibili. Un valore “buono” è pari o inferiore a 0,1 al 75º percentile.
Immagini senza dimensioni, banner inseriti sopra i contenuti, font e componenti caricati in ritardo sono cause comuni. Riservare lo spazio necessario impedisce che l’utente tocchi il controllo sbagliato.
Perché si usa il 75º percentile
Le condizioni reali variano per dispositivo, rete e comportamento. Valutare il 75º percentile significa considerare buona l’esperienza quando almeno il 75% delle visite rientra nella soglia per ciascuna metrica.
Una media può nascondere una parte significativa di utenti con prestazioni molto peggiori. Occorre segmentare almeno mobile e desktop e osservare le pagine più importanti.
Dati reali e test di laboratorio
I dati sul campo provengono da visite reali e riflettono dispositivi, reti e interazioni effettive. PageSpeed Insights può mostrare dati CrUX aggregati degli ultimi 28 giorni quando esiste traffico sufficiente.
Lighthouse esegue invece un test controllato utile alla diagnosi. I risultati possono differire: il laboratorio offre ripetibilità e suggerimenti, mentre il campo descrive l’esperienza realmente osservata. Vanno usati insieme.
Pagina, gruppo di URL e origine
Search Console raggruppa URL con comportamenti simili, mentre PageSpeed Insights può mostrare dati della singola pagina o dell’origine. Se una pagina non ha campione sufficiente, possono apparire soltanto dati aggregati.
Non bisogna quindi attribuire automaticamente un dato dell’origine a ogni URL. Verificate template, contenuti e funzionalità differenti: home, articoli, servizi e checkout possono avere cause diverse.
Come diagnosticare correttamente
- Identificare metrica, dispositivo e gruppo di pagine problematico.
- Riprodurre il problema in laboratorio e negli strumenti di sviluppo.
- Individuare elemento LCP, attività lunghe o fonti di layout shift.
- Correggere la causa nel template o componente condiviso.
- Verificare regressioni e osservare i dati reali nel tempo.
Interventi tipici per LCP
Ridurre tempi del server, ottimizzare e dimensionare l’immagine principale, evitare lazy loading sull’elemento LCP, dare priorità alle risorse critiche e limitare CSS o JavaScript bloccante. Cache e CDN aiutano soltanto quando agiscono sul collo di bottiglia reale.
Interventi tipici per INP
Ridurre JavaScript, suddividere attività lunghe, limitare script di terze parti e fornire feedback immediato. Un’interfaccia visivamente caricata ma bloccata non offre una buona esperienza.
Interventi tipici per CLS
Definire dimensioni o aspect ratio di immagini e video, riservare spazio per banner e incorporamenti, controllare font e animare proprietà che non modificano il layout. Gli spostamenti provocati direttamente da un’azione dell’utente vanno interpretati nel loro contesto.
Core Web Vitals e SEO
Google usa i Core Web Vitals nei propri sistemi, ma un risultato buono non garantisce il primo posto. Rilevanza, qualità e utilità dei contenuti restano fondamentali. Cercare il punteggio perfetto sacrificando contenuti o funzioni può essere controproducente.
La priorità va data alle pagine che falliscono le soglie e influenzano utenti o conversioni. Dopo aver raggiunto una buona esperienza, il rendimento marginale di ulteriori ottimizzazioni può essere inferiore ad altri interventi.
Monitoraggio continuo
Nuove immagini, plugin, tag pubblicitari e modifiche al tema possono peggiorare le metriche. Inserite controlli prestazionali nel processo di pubblicazione e osservate periodicamente Search Console e dati RUM.
Per la visione progettuale leggete web design 2021; per l’ottimizzazione delle immagini consultate la guida alle immagini. LBCOMPANY diagnostica e migliora PageSpeed e Core Web Vitals: scoprite i servizi.
Domande frequenti
Quali sono i Core Web Vitals attuali?
LCP per il caricamento, INP per la reattività e CLS per la stabilità visiva. Nel 2021 al posto di INP veniva utilizzato FID.
Quali sono le soglie buone?
LCP entro 2,5 secondi, INP entro 200 millisecondi e CLS non superiore a 0,1, valutati al 75º percentile.
Perché PageSpeed cambia risultato?
Il test di laboratorio risente delle condizioni della singola esecuzione; i dati sul campo aggregano utenti reali. Anche rete, server e contenuti dinamici variano.
Un punteggio 100 garantisce una buona SEO?
No. È un risultato di laboratorio, mentre Google considera molti segnali e soprattutto la rilevanza del contenuto. Va interpretato, non usato come garanzia.
Quanto tempo serve per vedere i dati aggiornati?
I dati CrUX usati da PageSpeed e Search Console sono aggregati su una finestra mobile di 28 giorni, quindi il cambiamento sul campo non è immediato.
Bisogna ottimizzare ogni pagina separatamente?
Si parte dai template e gruppi di URL, poi si controllano pagine con contenuti o funzioni specifiche. Una correzione condivisa può risolvere molti URL.