Core Web Vitals: come si misurano LCP, INP e CLS e cosa cambia sull'esperienza utente

I Core Web Vitals costituiscono l'insieme di metriche con cui Google valuta l'esperienza offerta da una pagina, confrontando i valori rilevati sul sito con i propri parametri di riferimento e con quelli dei concorrenti che si posizionano sulle stesse query.

Introdotti nel 2020, coprono tre dimensioni distinte: prestazioni di caricamento, reattività agli input, stabilità visiva del layout durante il rendering.

La scelta progettuale che li distingue da altri indicatori tecnici sta nel fatto che misurano ciò che l'utente percepisce mentre naviga, non parametri interni al codice il cui effetto sulla resa finale resta indiretto.

Poiché i valori concorrono al ranking accanto a segnali di rilevanza e qualità dei contenuti, la lettura corretta di queste metriche interessa due funzioni aziendali che raramente si parlano: chi presidia la SEO e chi sviluppa il front end.

La conformità richiede che tutte e tre le soglie vengano rispettate contemporaneamente, condizione che rende inefficace qualsiasi ottimizzazione mirata a un singolo indicatore, e che nella pratica sposta il lavoro dalla correzione puntuale alla revisione dell'architettura di caricamento della pagina.

Quanto segue analizza il contenuto informativo di ciascuna metrica, la differenza tra dati di laboratorio e dati raccolti sul campo, gli interventi che producono effetti misurabili e gli errori che ricorrono con maggiore frequenza nei progetti di ottimizzazione.

LCP, INP e CLS: cosa misura ciascuna metrica e quali soglie rispettare

Il Largest Contentful Paint registra il tempo necessario perché l'elemento di contenuto più grande visibile nella viewport, tipicamente un'immagine in evidenza o un blocco di testo, venga renderizzato: su un articolo di testata l'elemento LCP coincide di norma con la featured image o con il titolo principale, e la soglia considerata buona si colloca entro 2,5 secondi. La metrica cattura la velocità percepita, che non corrisponde al tempo di caricamento complessivo della risorsa.

L'Interaction to Next Paint ha sostituito il First Input Delay come indicatore di reattività, con un cambiamento di perimetro sostanziale: mentre il FID osservava soltanto la prima interazione, l'INP considera tutte le interazioni lungo l'intero ciclo di vita della pagina e misura l'intervallo tra l'azione dell'utente e la comparsa del frame successivo sullo schermo.

La soglia di riferimento è fissata a 200 millisecondi, e il passaggio da una misurazione singola a una distribuzione di eventi ha reso visibili criticità che restavano fuori dalla rilevazione precedente, in particolare sui template ricchi di componenti interattivi caricati in modo asincrono.

Il Cumulative Layout Shift quantifica l'ampiezza e la frequenza degli spostamenti di layout non richiesti dall'utente, con soglia di conformità a 0,1: il caso tipico è il banner pubblicitario che si inserisce sopra il testo già visibile spingendo verso il basso il resto della pagina, con il rischio di clic errati su elementi che si spostano nel momento in cui vengono premuti.

L'unità di misura non è temporale ma dimensionale, poiché combina la porzione di viewport interessata dallo spostamento con la distanza percorsa dagli elementi coinvolti.

Strumenti di misurazione: dati di laboratorio e dati sul campo

PageSpeed Insights restituisce entrambe le tipologie di dato per l'URL analizzato: quelli di laboratorio, prodotti in ambiente controllato, e quelli sul campo, aggregati dalle sessioni di utenti reali attraverso il Chrome User Experience Report.

La distinzione è alquanto rilevante perché una simulazione eseguita su rete e dispositivo standardizzati può segnalare valori accettabili mentre la distribuzione reale, che include hardware datato e connettività degradata, colloca il sito fuori soglia.

Il report dedicato in Google Search Console, raggiungibile dalla sezione Esperienza, organizza gli URL in tre classi di prestazione e li separa per versione mobile e desktop, offrendo il vantaggio della copertura su tutte le pagine indicizzate anziché sul singolo indirizzo sottoposto a test.

Lighthouse, integrato nei DevTools di Chrome, condivide con PageSpeed Insights lo stesso motore di analisi e produce quindi risultati coerenti, con un output di diagnostica più adatto al lavoro di sviluppo: la scomposizione del tempo di esecuzione di JavaScript e del carico sul main thread indirizza l'intervento sui componenti responsabili del ritardo.

Affiancare uno strumento esterno all'ecosistema Google, come GTmetrix, ha un'utilità che va oltre il secondo parere: i punteggi sintetici in lettera e le valutazioni su struttura e prestazioni funzionano nella comunicazione verso interlocutori non tecnici, dove la lettura di una distribuzione percentilica risulta impraticabile.

La priorità va comunque assegnata al dato mobile, dato che l'indicizzazione è mobile-first e la quota di traffico da dispositivo mobile supera il 60%.

Interventi tecnici su caricamento, reattività e stabilità del layout

Sul LCP l'intervento a rendimento più alto riguarda il peso e il formato delle risorse visive: compressione delle immagini, adozione di formati moderni come WebP, lazy loading applicato esclusivamente agli elementi sotto la piega, poiché rimandare il caricamento della risorsa che costituisce l'elemento LCP produce l'effetto opposto a quello cercato.

Sul lato infrastrutturale, la configurazione della cache del browser e la distribuzione tramite CDN riducono la latenza per i visitatori di ritorno e per quelli geograficamente distanti dall'origine, mentre il tempo di risposta del server va aggredito attraverso l'analisi dei log di accesso prima di valutare un cambio di provider.

Il miglioramento dell'INP passa dalla frammentazione delle attività lunghe in unità più brevi, dal differimento del JavaScript non necessario al primo rendering e dalla rimozione del codice non utilizzato, con lo spostamento delle elaborazioni pesanti su Web Worker per liberare il main thread.

Sul CLS gli attributi di larghezza e altezza dichiarati su immagini e video permettono al browser di riservare lo spazio corretto prima che la risorsa arrivi, e l'uso delle transform CSS al posto delle proprietà che innescano un ricalcolo del layout mantiene stabile la pagina durante le animazioni.

"Nella maggior parte degli audit che eseguiamo, il problema non sta nella singola risorsa da comprimere ma nella stratificazione di script di terze parti aggiunti in momenti diversi, ciascuno con un impatto trascurabile preso da solo", osserva Brian Gjermeni esperto SEO di Wolf Agency. "Per questo la prima cosa che facciamo è l'inventario di cosa viene caricato e per quale scopo: nella maggior parte dei casi è lì che si trovano i margini più ampi, prima di qualsiasi intervento sul codice."

Quali sono gli errori ricorrenti nei progetti di ottimizzazione dei Core Web Vitals

La concentrazione degli sforzi su una metrica sola produce regressioni sulle altre: comprimere in modo aggressivo tutte le immagini per accelerare il LCP può introdurre degli spostamenti di layout e peggiorare il CLS, con un bilancio complessivo negativo rispetto alla situazione di partenza.

La valutazione va condotta sull'insieme dei tre valori, dato che la conformità dipende dal rispetto simultaneo delle soglie.

L'ottimizzazione condotta sulla sola versione desktop lascia scoperto il segmento su cui la valutazione avviene: i dispositivi mobili dispongono di capacità di elaborazione inferiore e operano su reti meno stabili, condizioni che amplificano l'effetto di ogni script aggiuntivo.

Sottovalutare gli effetti cumulativi appartiene alla stessa famiglia di errori, perché la somma di rallentamenti individualmente irrilevanti degrada l'INP in misura percepibile.

Infine, trattare l'ottimizzazione come attività una tantum ignora la dinamica reale del degrado: modifiche al layout, nuove sezioni, integrazioni di marketing e aggiornamenti di template riportano progressivamente i valori verso le soglie critiche, e il monitoraggio periodico serve a intercettare lo scostamento prima che questo si consolidi.