Tre metriche, tre esperienze
I Core Web Vitals descrivono aspetti distinti dell’esperienza reale. Largest Contentful Paint misura quando appare il contenuto principale. Interaction to Next Paint misura la latenza delle interazioni lungo la visita. Cumulative Layout Shift misura gli spostamenti visivi inattesi.
Google indica come soglie buone LCP entro 2,5 secondi, INP inferiore a 200 millisecondi e CLS inferiore a 0,1. La valutazione usa il 75° percentile: non basta che il dispositivo del team sia veloce.
Campo e laboratorio rispondono a domande diverse
I dati di campo aggregano esperienze reali con reti, dispositivi, cache e comportamenti differenti. Sono adatti a capire che cosa vivono gli utenti nel tempo, ma arrivano con ritardo e possono non essere disponibili per pagine con poco traffico.
Il laboratorio rende ripetibili condizioni e diagnostica. Lighthouse e strumenti di profiling aiutano a isolare risorse bloccanti, long task, layout shift e dipendenze. Un singolo punteggio non rappresenta tutta la popolazione: è un esperimento controllato.
Trova il responsabile del LCP
Prima identifica l’elemento LCP per template. Può essere un titolo, un’immagine hero o un blocco di testo. Poi separa tempo di risposta del server, scoperta della risorsa, download e rendering.
Le correzioni tipiche includono cache della risposta, HTML iniziale leggero, priorità corretta per l’immagine principale, compressione moderna, dimensioni adeguate e rimozione di CSS o script che bloccano inutilmente. Il lazy loading sull’immagine LCP può ritardarla: va usato sulle immagini fuori viewport.
Riduci il lavoro che blocca le interazioni
INP osserva molte interazioni, non soltanto il primo clic. Quando la risposta è lenta, misura input delay, tempo di elaborazione e ritardo di presentazione. JavaScript eccessivo, handler che fanno troppo lavoro e rendering di grandi porzioni di DOM sono cause frequenti.
Dividi i task lunghi, evita dipendenze per funzioni banali, rimanda il lavoro non necessario e mostra feedback immediato. La migliore ottimizzazione spesso è non spedire codice che la pagina non usa.
Prenota lo spazio per evitare CLS
Immagini, embed, banner e componenti asincroni devono avere dimensioni o contenitori prevedibili. Inserire contenuto sopra ciò che l’utente sta leggendo crea spostamenti; animare proprietà geometriche può fare lo stesso. Usa width e height, aspect ratio, placeholder e trasformazioni che non cambiano il flusso.
Controlla anche i font. Un fallback molto diverso dal font finale può spostare righe e pulsanti. Self-hosting, subset e fallback metricamente compatibili riducono rischio e dipendenze.
Trasforma le soglie in budget
Un performance budget assegna limiti prima del rilascio: peso totale, JavaScript iniziale, numero di richieste, dimensione dell’immagine hero e valori laboratorio per template. Inseriscilo nella revisione e nei test automatici. Le soglie di Google sono un riferimento esterno; il budget di progetto deve impedire regressioni prima di raggiungerle.
Segmenta i dati per template e dispositivo. Una media del dominio può nascondere un checkout rapido e articoli lenti, o viceversa. Dopo ogni rilascio materiale, controlla laboratorio subito e campo quando la finestra statistica lo consente.
Fonte
Domande frequenti
Quali sono le soglie buone dei Core Web Vitals?
Google indica LCP entro 2,5 secondi, INP sotto 200 millisecondi e CLS sotto 0,1, valutati al 75° percentile delle visite.
Lighthouse e Search Console devono mostrare lo stesso risultato?
No. Lighthouse è un test di laboratorio in condizioni definite; Search Console usa dati reali aggregati nel tempo quando disponibili.