I Core Web Vitals sono tre metriche con cui Google misura l’esperienza reale degli utenti sulle tue pagine: la velocità con cui si carica il contenuto principale (LCP), la rapidità con cui la pagina risponde a un clic o a un tocco (INP) e la stabilità del layout durante il caricamento (CLS). Per superare la valutazione servono un LCP fino a 2,5 secondi, un INP fino a 200 millisecondi e un CLS fino a 0,1, misurati sui dati di utenti reali al 75° percentile. In questa guida trovi cosa significano davvero questi numeri, come leggerli senza farti ingannare dagli strumenti e quali interventi portano risultati misurabili.

In breve

• Tre metriche, tre problemi diversi: LCP misura il caricamento, INP la reattività, CLS la stabilità visiva. Ognuna ha cause e soluzioni proprie.
• Contano i dati di campo: Google valuta l’esperienza dei visitatori reali raccolta in 28 giorni, non il punteggio che vedi in un singolo test di laboratorio.
• Sono un segnale, non una scorciatoia: migliorano l’esperienza e aiutano a parità di qualità dei contenuti, ma non compensano pagine poco utili o poco pertinenti.
• Gli script di terze parti pesano: tag di analytics, pixel pubblicitari e banner del consenso sono tra le prime cose da verificare quando l’INP peggiora.
• Si lavora per gruppi di pagine: template, tipologie di pagina e dispositivi, non URL singoli.

Indice

• Le tre metriche e le soglie da rispettare
• Come Google calcola il risultato
• Dati di campo e dati di laboratorio: la differenza che cambia le priorità
• Quanto contano i Core Web Vitals per la SEO
• Come misurare la velocità del tuo sito
• Come migliorare ogni metrica
• Tracciamento, consenso e prestazioni
• I Core Web Vitals dentro un audit SEO tecnico
• Il nostro punto di vista
• Prestazioni, tracciamento e crescita in un unico progetto
• Domande frequenti
• Fonti

Le tre metriche e le soglie da rispettare

Ogni metrica ha tre fasce: buona, da migliorare, scarsa. Queste sono le soglie ufficiali indicate da Google Search Central:

Se hai letto guide più vecchie, troverai citato il FID (First Input Delay): oggi la metrica di reattività è l’INP, che osserva tutte le interazioni della visita e non solo la prima. Il ciclo di vita delle metriche, con le fasi sperimentale, in attesa e stabile, è descritto nella panoramica ufficiale dei Web Vitals. Le soglie non sono arbitrarie: Google ha pubblicato la metodologia con cui sono state definite, bilanciando la qualità percepita dagli utenti e la reale possibilità per i siti di raggiungerla.

Come Google calcola il risultato

Qui nasce gran parte della confusione. Il risultato non è la media dei tuoi test, ma il valore al 75° percentile delle visite reali, su una finestra mobile di 28 giorni. In pratica: perché una pagina sia considerata buona, almeno il 75% delle visualizzazioni deve rientrare nella soglia.

Tre conseguenze operative:

1. Le correzioni non si vedono subito: dopo un rilascio servono settimane prima che la finestra di 28 giorni rifletta il miglioramento.
2. Gli utenti più lenti contano: se un quarto del tuo traffico arriva da smartphone economici o da reti mobili deboli, sono loro a determinare il risultato.
3. Mobile e desktop sono valutati separatamente: una pagina può essere verde su desktop e rossa su mobile, e di solito il mobile è il fronte su cui lavorare.

Dati di campo e dati di laboratorio: la differenza che cambia le priorità

Gli strumenti di misura si dividono in due famiglie, e confonderle porta a decisioni sbagliate.

• Dati di laboratorio: test eseguiti in un ambiente controllato, con dispositivo e rete predefiniti. Lighthouse è l’esempio tipico. Servono per diagnosticare e riprodurre un problema durante lo sviluppo.
• Dati di campo: misure raccolte dalle visite reali. La fonte di riferimento è il Chrome User Experience Report (CrUX), che aggrega le esperienze degli utenti Chrome che hanno dato il consenso. In alternativa, o in aggiunta, puoi raccogliere i tuoi dati con una soluzione di Real User Monitoring (RUM).

Un test di laboratorio restituisce un solo numero, mentre i dati di campo descrivono una distribuzione: come spiega web.dev, il risultato di laboratorio è solo uno dei possibili esiti tra le esperienze dei tuoi utenti. Per questo un punteggio Lighthouse di 100 non garantisce che la pagina superi la valutazione, e un punteggio mediocre non significa per forza che i tuoi utenti reali soffrano.

La regola che applichiamo: i dati di campo decidono cosa correggere, quelli di laboratorio aiutano a capire come.

Quanto contano i Core Web Vitals per la SEO

Google è esplicito: i Core Web Vitals fanno parte dei segnali di esperienza della pagina, ma non esiste un unico segnale “page experience” e i sistemi di ranking premiano prima di tutto contenuti pertinenti e utili. Una pagina rilevante con metriche non perfette può comunque posizionarsi bene; una pagina tecnicamente impeccabile ma poco utile no.

Dove i Core Web Vitals fanno la differenza:

• A parità di qualità: quando i contenuti in competizione si equivalgono, un’esperienza migliore è un vantaggio.
• Sulle conversioni: una landing page che si carica lentamente o i cui pulsanti si spostano sotto il dito perde contatti indipendentemente dal ranking. Se lavori su pagine di acquisizione, la nostra guida al design di landing page che convertono parte proprio da qui.
• Sulle campagne a pagamento: ogni secondo perso tra il clic sull’annuncio e la pagina visibile è budget che non lavora.

Le stesse linee guida di Google invitano a non inseguire punteggi perfetti, ma a usare queste metriche come strumento diagnostico per individuare dove l’utente incontra attrito. È l’approccio corretto: i Core Web Vitals sono un mezzo, non l’obiettivo.

Come misurare la velocità del tuo sito

Gli strumenti ufficiali sono gratuiti e, usati insieme, coprono sia la diagnosi sia il monitoraggio. Ognuno accede ai dati CrUX con frequenze di aggiornamento e dettagli diversi, quindi è normale vedere piccole differenze tra uno strumento e l’altro.

Google Search Console

Il report Core Web Vitals di Search Console mostra lo stato del sito sui dati reali, diviso tra mobile e desktop, e raggruppa gli URL con comportamenti simili. Non elenca tutte le pagine indicizzate: lavora per campioni e gruppi. Usalo per capire quali template hanno problemi, non per controllare ogni singolo URL.

PageSpeed Insights

Unisce in una sola schermata i dati di campo CrUX (quando il traffico è sufficiente) e un test Lighthouse di laboratorio. È lo strumento più rapido per verificare una pagina specifica e ricevere indicazioni sugli elementi che rallentano LCP o causano spostamenti.

Chrome DevTools e Lighthouse

Per gli sviluppatori: il pannello Performance permette di registrare un caricamento o un’interazione e vedere esattamente quale script blocca il thread principale o quale elemento si sposta.

CrUX e RUM

Il CrUX offre dati per origine e per URL tramite API e dashboard. Se hai bisogno di segmentare per pagina, campagna, Paese o tipo di dispositivo, una soluzione RUM integrata nel tuo stack di analisi ti dà un controllo che i dati pubblici non offrono. È il tipo di configurazione che impostiamo nei progetti di dati e analisi, collegando le metriche di performance ai KPI di business.

Come migliorare ogni metrica

LCP: far arrivare prima il contenuto principale

L’LCP dipende da quattro fasi: risposta del server, scoperta della risorsa, download e rendering. Gli interventi con il miglior rapporto tra sforzo e impatto:

• Riduci il tempo di risposta del server: cache a livello di pagina, CDN, hosting adeguato al traffico. Un TTFB alto rende quasi impossibile un buon LCP.
• Rendi l’immagine principale scopribile subito: deve essere nell’HTML iniziale, non caricata da JavaScript o come sfondo CSS. Usa fetchpriority="high" sull’immagine LCP.
• Non applicare il lazy loading all’immagine above the fold: è uno degli errori più frequenti, soprattutto con plugin WordPress che lo attivano ovunque.
• Comprimi e ridimensiona: formati moderni come WebP o AVIF e dimensioni coerenti con il contenitore.
• Elimina le risorse che bloccano il rendering: CSS critico inline, JavaScript non essenziale con defer.

INP: liberare il thread principale

L’INP peggiora quando il browser è occupato a eseguire JavaScript nel momento in cui l’utente interagisce. Dove intervenire:

• Fai un inventario degli script di terze parti: chat, mappe di calore, pixel pubblicitari, widget social. Per ognuno chiediti se genera valore misurabile.
• Spezza i task lunghi: il codice che impiega più di 50 ms va suddiviso, così il browser può rispondere all’utente tra un blocco e l’altro.
• Riduci il lavoro nei gestori di eventi: aggiorna subito l’interfaccia e rimanda i calcoli non urgenti.
• Controlla la dimensione del DOM: pagine con migliaia di nodi rendono lento ogni aggiornamento visivo.

CLS: dare a ogni elemento il suo spazio

• Dichiara sempre larghezza e altezza di immagini, video e iframe, oppure usa aspect-ratio in CSS.
• Riserva lo spazio per banner, annunci ed embed prima che vengano caricati.
• Gestisci i font web: font-display e il precaricamento dei font principali riducono lo spostamento del testo.
• Non inserire contenuti sopra quelli esistenti dopo il caricamento, salvo in risposta a un’azione dell’utente.

Tracciamento, consenso e prestazioni

Chi lavora su marketing e analisi spesso scopre che il problema di performance non è nel codice del sito, ma nello strato di tracciamento: tag manager carichi di tag, più pixel pubblicitari che fanno lo stesso lavoro, banner del consenso che si caricano tardi e spostano il layout.

Tre interventi da valutare insieme al tuo team tecnico:

1. Pulizia del tag manager: rimuovi i tag inattivi, consolida quelli duplicati, imposta trigger precisi invece di attivare tutto su ogni pagina.
2. Tracciamento lato server: con un’architettura server side molte chiamate verso le piattaforme pubblicitarie e di analisi (incluso GA4) partono dal tuo server invece che dal browser. Meno JavaScript sul dispositivo dell’utente significa più margine per l’INP, oltre a un maggiore controllo sui dati raccolti.
3. Banner del consenso leggero e stabile: deve avere uno spazio riservato o comparire in sovrimpressione senza spostare i contenuti, e la logica del consenso (per esempio con Consent Mode) va configurata in modo che i tag si attivino solo quando consentito, senza caricare script inutili prima della scelta.

La scelta dell’architettura dipende dalle normative applicabili nei Paesi in cui operi e dai requisiti delle piattaforme che usi: su questi aspetti coinvolgi il tuo consulente privacy o il legale che segue la conformità dell’azienda. Ne parliamo anche nella guida su come sistemare il tracciamento nella strategia di paid media.

I Core Web Vitals dentro un audit SEO tecnico

Le metriche di performance sono un capitolo dell’audit tecnico, non l’audit intero. Una checklist essenziale, nell’ordine in cui la affrontiamo:

1. Scansione e indicizzazione: robots.txt, sitemap XML, pagine bloccate per errore, codici di stato 4xx e 5xx.
2. Canonicalizzazione: un solo URL di riferimento per ogni contenuto, tag canonical coerenti, gestione di parametri, versioni con e senza www e HTTP/HTTPS.
3. Architettura del sito: le pagine chiave devono essere raggiungibili in pochi clic dalla home, come spieghiamo nella guida all’architettura del sito per la SEO.
4. Core Web Vitals per template: partendo da Search Console, prima mobile poi desktop, prima i template con più traffico.
5. Mobile e accessibilità: contenuti equivalenti tra versioni, elementi toccabili ben distanziati.
6. Dati strutturati e metadati: markup valido, title e description unici.
7. Sicurezza e conformità: HTTPS ovunque e nessuna pratica in contrasto con le norme di Google contro lo spam.

L’audit tecnico prepara il terreno, ma il traffico arriva quando la base tecnica sostiene una strategia SEO solida fatta di contenuti utili e ben posizionati.

Il nostro punto di vista

Nei progetti che seguiamo vediamo spesso lo stesso schema: un’azienda riceve un report con punteggi rossi, avvia una corsa al 100 su Lighthouse e dopo settimane di lavoro non registra alcun cambiamento né nel traffico né nelle conversioni. Il problema non è l’impegno, è l’ordine delle priorità.

Il nostro approccio parte dai dati: quali pagine generano contatti e vendite, quali template ricevono più traffico mobile, dove i dati di campo segnalano un attrito reale. Solo dopo decidiamo dove intervenire. Una scheda prodotto con un INP scarso su mobile vale più di dieci articoli del blog con un CLS appena sopra soglia.

Crediamo anche che la performance non sia un tema solo per sviluppatori. Le scelte che la peggiorano nascono spesso nel marketing: un nuovo pixel, un video in apertura, un widget aggiunto per una campagna. Per questo lavoriamo con un approccio integrato, in cui strategia, contenuti, sviluppo web e analisi parlano la stessa lingua e ogni scelta tecnica viene misurata sul suo impatto concreto.

— Xpert

Prestazioni, tracciamento e crescita in un unico progetto

Se il tuo sito ha metriche da migliorare, un tracciamento da riorganizzare o una landing page che non converte, possiamo affrontare tutto in un solo percorso: audit tecnico, ottimizzazione web, configurazione di analytics e dashboard KPI, collegati alla tua strategia di marketing digitale. Scopri tutti i nostri servizi di marketing, web e analisi e raccontaci su quale obiettivo vuoi lavorare.

Domande frequenti

I Core Web Vitals sono un fattore di ranking?

Sì, fanno parte dei segnali di esperienza della pagina che Google considera. Non sono però il fattore principale: i sistemi di ranking premiano prima di tutto contenuti pertinenti e utili. Migliorarli aiuta soprattutto quando la qualità dei contenuti è paragonabile a quella dei concorrenti.

Perché PageSpeed Insights e Search Console mostrano risultati diversi?

Perché misurano cose diverse o in momenti diversi. Il test Lighthouse di PageSpeed Insights è un singolo rilevamento di laboratorio, mentre Search Console mostra i dati reali degli utenti su 28 giorni, raggruppati per pagine simili. Per le priorità conta sempre il dato di campo.

Quanto tempo serve per vedere i miglioramenti?

I dati di campo si basano su una finestra mobile di 28 giorni, quindi dopo un intervento servono alcune settimane perché il miglioramento si rifletta completamente. In Search Console puoi avviare la convalida della correzione e monitorarne l’avanzamento.

Il mio sito ha poco traffico e non vedo dati: cosa faccio?

Se una pagina o un sito non raccoglie abbastanza visite, i dati CrUX non sono disponibili. In questo caso puoi usare i test di laboratorio come riferimento e, se vuoi dati reali, installare una soluzione RUM che misuri direttamente le visite al tuo sito.

Il tracciamento lato server migliora i Core Web Vitals?

Può aiutare, soprattutto l’INP, perché riduce il JavaScript di terze parti eseguito nel browser. Il beneficio dipende da quanti tag sposti e da come è configurato il resto del sito: va valutato con una misura prima e dopo l’intervento.

Fonti

• Google Search Central: Core Web Vitals e risultati di ricerca
• Google Search Central: esperienza della pagina
• Google Search Central: norme contro lo spam
• Guida di Search Console: report Core Web Vitals
• web.dev: Web Vitals
• web.dev: come sono state definite le soglie
• web.dev: differenze tra dati CrUX e RUM
• web.dev: differenze tra dati di laboratorio e di campo
• Chrome for Developers: strumenti CrUX

Raccomandati

• Design landing page: come creare pagine che convertono davvero