Core Web Vitals: cosa misurano e perché contano

Negli ultimi anni Google ha reso sempre più esplicito un messaggio: la qualità di un sito non si valuta solo da ciò che dice, ma da come viene vissuto. I Core Web Vitals nascono in questo contesto. Non sono una moda tecnica né un nuovo punteggio da inseguire, ma un tentativo — imperfetto ma concreto — di tradurre l’esperienza utente in segnali misurabili.

Questo articolo non è una guida operativa per sviluppatori e non promette miracoli SEO. L’obiettivo è un altro: capire cosa misurano davvero i Core Web Vitals, cosa escludono, perché contano e soprattutto come interpretarli senza cadere nei luoghi comuni. Oggi le metriche centrali sono tre — LCP, INP e CLS — ma il vero valore sta nel modo in cui vengono lette, non nel colore del report.

Cosa sono i Core Web Vitals (e cosa NON sono)

I Core Web Vitals, ci spiegano gli amici di Bithub.it, web agency specializzata nella realizzazione di ecommerce, sono un insieme specifico di metriche UX che Google considera fondamentali per valutare la qualità dell’esperienza di una pagina web. Non descrivono “tutta” l’esperienza, ma tre dimensioni che incidono in modo diretto sulla percezione dell’utente: quanto velocemente vede qualcosa di utile, quanto il sito risponde alle sue azioni e quanto l’interfaccia resta stabile nel tempo.

Sono una sotto-categoria delle Web Vitals e, come tali, non sono scolpiti nella pietra. Cambiano perché cambia il web e cambiano perché Google cerca di avvicinarsi sempre di più al comportamento reale delle persone.

Qui entra in gioco la prima distinzione cruciale: i Core Web Vitals non coincidono con un punteggio Lighthouse, non sono una checklist binaria e non vanno confusi con un “fattore SEO” classico. Lighthouse lavora su dati simulati, in condizioni controllate. È utile per individuare problemi, ma non descrive ciò che accade davvero agli utenti. I Core Web Vitals che contano per Google, invece, si basano soprattutto su dati reali, come quelli aggregati e mostrati in Google Search Console.

Quando si confondono questi due livelli — laboratorio e campo — si finisce spesso per prendere decisioni sbagliate: si ottimizza il test, non l’esperienza.

Le tre metriche principali: LCP, INP e CLS

La prima metrica, il Largest Contentful Paint, prova a rispondere a una domanda molto semplice: quando l’utente percepisce che la pagina è davvero caricata? L’LCP misura il tempo necessario affinché l’elemento principale — spesso un’immagine hero o un blocco di testo rilevante — diventi visibile. Non è il caricamento totale, ma il caricamento percepito.

Un LCP buono indica che l’utente vede rapidamente qualcosa di utile. Un LCP scarso, invece, genera quella sensazione di attesa vuota che porta a pensare che il sito sia lento, anche quando tecnicamente non lo è. Le cause più frequenti sono immagini pesanti, tempi di risposta del server elevati e risorse che bloccano il rendering. Ed è per questo che spesso piccoli interventi mirati producono risultati più concreti di grandi riscritture.

La seconda metrica, Interaction to Next Paint, segna un passaggio importante. Dal marzo 2024 ha sostituito il vecchio FID e ha cambiato il modo in cui viene valutata la reattività. INP non guarda solo alla prima interazione, ma a tutte le interazioni rilevanti durante la sessione. Misura quanto tempo passa tra un’azione dell’utente e il primo aggiornamento visivo coerente.

Questo rende la metrica più scomoda, ma anche più onesta. Un sito può caricarsi velocemente e poi diventare lento, scattoso, frustrante. INP serve proprio a intercettare questi problemi, spesso legati a JavaScript eccessivo, task troppo lunghi o script di terze parti che occupano il main thread. In altre parole, misura quanto il sito “regge” quando viene davvero usato.

La terza metrica, Cumulative Layout Shift, riguarda la stabilità visiva. È quella sensazione fastidiosa per cui stai per cliccare un elemento e, all’ultimo istante, tutto si sposta. Il CLS quantifica questi spostamenti inattesi e ripetuti, che non sono solo un problema estetico ma un vero ostacolo all’usabilità.

Layout instabili nascono quasi sempre da scelte prevedibili: immagini senza dimensioni dichiarate, font che cambiano aspetto dopo il caricamento, componenti inseriti dinamicamente sopra contenuti già visibili. Anche qui, il punto non è “fare zero”, ma ridurre le sorprese.

C’è un aspetto spesso sottovalutato: i Core Web Vitals non vengono valutati sulla media, ma sul 75° percentile. Questo significa che conta l’esperienza della maggioranza degli utenti, non quella ideale. E per essere considerata “buona”, una pagina deve rientrare nelle soglie per tutte e tre le metriche, non solo per una.

Come Google misura i Core Web Vitals: dati reali vs test di laboratorio

Per capire i Core Web Vitals bisogna capire da dove arrivano i dati. Quelli che Google utilizza per le valutazioni di Page Experience sono dati di campo, raccolti da utenti reali che navigano con Chrome. Questi dati vengono aggregati e restituiti in Search Console sotto forma di stati complessivi.

Le URL non vengono sempre analizzate singolarmente: spesso vengono raggruppate per template o tipologia, e il gruppo assume lo stato della metrica peggiore. È un dettaglio che spiega molte apparenti incongruenze e che rende inutile l’ossessione per la singola pagina “perfetta”.

I dati di laboratorio, invece, servono per capire perché qualcosa va male. Sono indispensabili per il debug, ma non raccontano l’esperienza reale. Se i test migliorano e i dati di campo restano invariati, il segnale è chiaro: si sta lavorando nel posto sbagliato.

Perché i Core Web Vitals contano davvero

Contano prima di tutto per l’esperienza utente, perché misurano frizioni concrete: attesa, lag, instabilità. Sono problemi che gli utenti percepiscono anche senza sapere cosa sia un LCP o un INP.

Dal punto di vista SEO, fanno parte dei segnali di Page Experience, ma non sostituiscono contenuti, intenti o autorevolezza. Non sono una leva magica, bensì un fattore di qualità che aiuta a distinguere esperienze buone da esperienze mediocri a parità di altri segnali.

Per il business, infine, sono uno strumento di priorità. Aiutano a decidere dove intervenire, a evitare ottimizzazioni cosmetiche e a parlare di esperienza con dati condivisibili tra team diversi.

Come migliorare i Core Web Vitals senza sprecare tempo e budget

L’errore più comune è partire dagli strumenti. La strada più efficace è l’opposto: partire dai dati reali, individuare le aree critiche e capire qual è il problema dominante. Spesso non servono decine di interventi, ma uno o due ben scelti.

Lavorare su una metrica alla volta, con obiettivi realistici, è quasi sempre più produttivo che inseguire il verde ovunque. Un’immagine principale ottimizzata, meno JavaScript inutile o uno spazio riservato correttamente possono fare più della riscrittura completa di un front-end.

Conclusione

I Core Web Vitals non servono a collezionare punteggi, ma a leggere la qualità dell’esperienza. Prima si capiscono, poi — solo poi — si ottimizzano.