Cosa sono i Core Web Vitals

I Core Web Vitals sono ormai uno standard consolidato del posizionamento su Google e nel 2026 hanno assunto un peso ancora maggiore nelle valutazioni dell’algoritmo. Eppure, secondo gli ultimi dati di settore, soltanto il 47% dei siti web nel mondo riesce a rispettare le tre soglie ritenute “buone” dal motore di ricerca. Significa che oltre la metà dei siti perde quotidianamente posizioni, traffico e conversioni per problemi di performance che si potrebbero risolvere. In questo articolo ti spiego cosa sono i Core Web Vitals oggi, quali sono le tre metriche aggiornate, perché INP ha cambiato le regole del gioco rispetto al vecchio FID, come si misurano correttamente e quali sono gli interventi più efficaci per migliorarli. Ti racconto anche il mio metodo di lavoro su questo aspetto specifico, che è uno dei più sottovalutati ma anche più redditizi della SEO tecnica.

Cosa sono i Core Web Vitals

I Core Web Vitals sono un insieme di tre metriche definite da Google per misurare la qualità dell’esperienza utente su un sito web. Furono introdotti ufficialmente come fattore di ranking nel 2021 e da allora sono diventati una componente strutturale dell’algoritmo, con un peso crescente di anno in anno.

Le tre metriche misurano tre aspetti diversi e complementari dell’esperienza di chi naviga il sito:

• la velocità di caricamento dei contenuti principali;
• la reattività della pagina alle interazioni dell’utente;
• la stabilità visiva degli elementi mentre la pagina si carica.

L’idea alla base è semplice ma potente: Google vuole premiare i siti che offrono un’esperienza fluida e piacevole alle persone, perché un utente che non riesce a navigare comodamente un sito tornerà sui risultati di ricerca per cercare un’alternativa. E questo, per il motore di ricerca, è un segnale che il primo risultato non era il migliore disponibile.

Nel mio metodo di lavoro l’ottimizzazione dei Core Web Vitals è una delle prime attività che svolgo quando prendo in carico un nuovo progetto. È una di quelle operazioni meno “spettacolari” della SEO ma con impatto enorme sui risultati, sia in termini di posizionamento sia in termini di tassi di conversione.

Le tre metriche dei Core Web Vitals nel 2026

Vediamo nel dettaglio cosa misura ciascuna delle tre metriche e quali sono le soglie da rispettare. Anticipo subito una cosa importante: FID non esiste più dal marzo 2024, è stato sostituito da INP. Se trovi articoli o guide che parlano ancora di FID, sono semplicemente datati.

LCP — Largest Contentful Paint

L’LCP misura il tempo che impiega l’elemento più grande visibile nella parte iniziale della pagina (la cosiddetta “above the fold”) a essere completamente caricato e mostrato all’utente. Tipicamente l’elemento misurato è un’immagine grande, un video oppure un blocco di testo significativo.

Le soglie definite da Google sono:

• buono: LCP ≤ 2,5 secondi;
• da migliorare: LCP tra 2,5 e 4 secondi;
• scarso: LCP > 4 secondi.

Un LCP alto significa che l’utente fissa una pagina sostanzialmente bianca per troppi secondi prima di vedere comparire qualcosa di significativo. È il modo migliore per perdere visitatori prima ancora di averli realmente acquisiti.

Le cause più comuni di un LCP scadente che mi capita di riscontrare nei progetti dei clienti sono:

• immagini pesanti non ottimizzate caricate above the fold;
• server lenti o hosting sottodimensionati;
• CSS e JavaScript che bloccano il rendering;
• font web caricati in modo inefficiente;
• mancanza di una strategia di caching adeguata.

INP — Interaction to Next Paint

L’INP è la metrica che ha sostituito FID nel marzo 2024 e che nel 2026 si è confermata come la più critica per la maggior parte dei siti web. Misura la reattività complessiva della pagina alle interazioni dell’utente, dal momento del click o del tap fino al successivo aggiornamento visivo dello schermo.

La grande differenza rispetto al vecchio FID è che mentre quest’ultimo misurava soltanto il ritardo iniziale prima della prima interazione, INP misura l’intero ciclo di tutte le interazioni durante la navigazione, restituendo un valore che riflette molto più fedelmente l’esperienza reale.

Le soglie sono:

• buono: INP ≤ 200 millisecondi;
• da migliorare: INP tra 200 e 500 millisecondi;
• scarso: INP > 500 millisecondi.

Nota: secondo i dati di settore aggiornati al 2026, il 43% dei siti web fallisce la soglia INP di 200 millisecondi. È la metrica più frequentemente non rispettata in assoluto, perché richiede interventi profondi sull’architettura JavaScript del sito. Non basta comprimere immagini o attivare una cache: bisogna ripensare il modo in cui il codice gestisce gli eventi dell’utente.

Le cause più frequenti di un INP scadente sono task JavaScript troppo lunghi che bloccano il main thread del browser, script di terze parti (tag manager, pixel pubblicitari, chatbot, analytics) caricati in modo invasivo, framework JavaScript pesanti non ottimizzati. Sui siti WordPress questo problema si manifesta spesso con plugin di scarsa qualità che caricano script ovunque, indipendentemente dalla loro reale necessità.

CLS — Cumulative Layout Shift

Il CLS misura la stabilità visiva della pagina durante il caricamento. Quante volte ti è capitato di stare per cliccare un pulsante e veder comparire all’ultimo momento un banner pubblicitario che ti ha fatto cliccare qualcos’altro? Ecco, quello è esattamente ciò che il CLS è progettato per misurare e penalizzare.

Le soglie sono:

• buono: CLS ≤ 0,1;
• da migliorare: CLS tra 0,1 e 0,25;
• scarso: CLS > 0,25.

Le cause tipiche di un CLS problematico sono:

• immagini senza attributi width e height specificati;
• annunci pubblicitari che si inseriscono dopo il caricamento iniziale;
• web font che cambiano dimensione del testo durante il rendering;
• elementi inseriti dinamicamente da JavaScript (popup, banner, notifiche);
• iframe e widget di terze parti senza dimensioni esplicite.

Il CLS è una delle metriche su cui mi imbatto più spesso in problemi nei progetti che eredito da altri. La soluzione di base è semplice: ogni elemento visivo deve avere dimensioni dichiarate esplicitamente nel codice, in modo che il browser possa riservargli lo spazio corretto fin dal primo istante.

Come Google misura concretamente i Core Web Vitals

Questo è un punto che genera spesso confusione, ma è fondamentale capirlo bene. Google non valuta i Core Web Vitals in base al test che fai dal tuo computer, ma in base ai dati reali raccolti dagli utenti che hanno navigato il sito con Chrome negli ultimi 28 giorni.

Questo dataset si chiama CrUX (Chrome User Experience Report) e contiene le metriche di performance raccolte da decine di milioni di utenti reali in tutto il mondo. Quando uno strumento ti mostra “i Core Web Vitals del tuo sito”, in realtà ti sta mostrando l’aggregato dei dati CrUX raccolti.

Il criterio di valutazione è il 75esimo percentile: significa che almeno il 75% delle visite al tuo sito deve registrare punteggi nella fascia “buono” per superare il test. Non basta una media positiva, serve che la grande maggioranza degli utenti viva una buona esperienza.

Questa distinzione è cruciale perché ha conseguenze pratiche importanti:

• siti con poco traffico potrebbero non avere abbastanza dati CrUX per essere valutati;
• ottimizzare per lo scenario “ideale” del tuo computer non basta;
• il sito va testato su dispositivi mobili reali con connessioni medie;
• i miglioramenti tecnici impiegano fino a 28 giorni per riflettersi nei dati CrUX.

Gli strumenti per misurare i Core Web Vitals

Per misurare correttamente i Core Web Vitals di un sito ti consiglio di usare in combinazione più strumenti, perché ognuno offre una prospettiva diversa e complementare.

Quelli che utilizzo quotidianamente nel mio lavoro sono:

• Google Search Console: nella sezione “Esperienza” mostra i dati CrUX reali del tuo sito;
• PageSpeed Insights: combina dati di laboratorio e dati reali con suggerimenti operativi;
• Lighthouse: integrato in Chrome DevTools, ottimo per analisi tecniche approfondite;
• Chrome DevTools (pannello Performance): per il debugging dettagliato dei problemi specifici;
• CrUX Dashboard: per analizzare l’andamento storico delle metriche nel tempo;
• WebPageTest: per simulazioni avanzate con diverse condizioni di rete e device.

Una raccomandazione importante: diffida dei singoli punteggi misurati una sola volta. I dati di laboratorio possono variare significativamente da una misurazione all’altra in base a fattori come la velocità del server, la congestione della rete, gli script di terze parti caricati. Solo i dati CrUX aggregati su 28 giorni danno un quadro affidabile delle reali performance percepite dagli utenti.

L’impatto reale sui ranking e sulle conversioni

Nel 2026 i Core Web Vitals hanno acquisito un peso ancora maggiore nel sistema di ranking di Google. Il core update di marzo 2026 ha rafforzato l’influenza dei segnali di page experience nell’algoritmo, premiando significativamente i siti che rispettano le soglie e penalizzando quelli che le falliscono in modo persistente.

I numeri parlano chiaro:

• i siti che superano tutte e tre le metriche mostrano un vantaggio di posizionamento misurabile rispetto a quelli che ne falliscono almeno una;
• il passaggio da scarso a buono sui Core Web Vitals si associa a riduzioni del bounce rate intorno al 24%;
• case study su grandi e-commerce mostrano aumenti delle conversioni a doppia cifra dopo interventi mirati su LCP e INP.

Non si tratta quindi solo di una questione SEO: i Core Web Vitals impattano direttamente sul business. Un sito lento o instabile perde clienti prima ancora di averli convertiti, e questo si traduce in ricavi mancati ogni singolo giorno. Le aziende che misurano il costo reale di una pagina lenta capiscono in fretta perché l’investimento sulle performance è uno dei più redditizi possibili.

Come migliorare concretamente i Core Web Vitals

Migliorare i Core Web Vitals non è un’operazione standardizzata: ogni sito ha le sue criticità specifiche e richiede un piano di intervento personalizzato. Ci sono però alcune azioni che producono benefici nella stragrande maggioranza dei casi e che rappresentano il punto di partenza di qualunque attività di ottimizzazione.

Interventi per migliorare LCP

Per ridurre il tempo di Largest Contentful Paint le azioni più efficaci sono:

• ottimizzare e comprimere le immagini, preferendo formati moderni come WebP e AVIF;
• preloadare l’immagine dell’elemento LCP per anticiparne il caricamento;
• inlineare il CSS critico necessario al rendering above the fold;
• caricare font in modo asincrono con font-display: swap;
• migrare a un hosting performante con tempi di risposta del server bassi;
• implementare una CDN per servire i contenuti vicino agli utenti;
• attivare un sistema di caching efficace a livello server e browser.

Interventi per migliorare INP

L’INP è la metrica più ostica da ottimizzare perché richiede interventi sulla logica JavaScript della pagina. Le azioni più efficaci sono:

• spezzare task JavaScript lunghi in operazioni più piccole;
• differire l’esecuzione di codice non critico con async e defer;
• eliminare o limitare drasticamente gli script di terze parti non essenziali;
• ottimizzare i listener degli eventi per evitare blocchi del main thread;
• caricare in lazy loading widget, chatbot e tracker non immediatamente necessari;
• su WordPress, rivedere criticamente i plugin che caricano JavaScript ovunque.

Interventi per migliorare CLS

Per stabilizzare il layout della pagina ed evitare spostamenti indesiderati le azioni chiave sono:

• specificare width e height espliciti su tutte le immagini e i video;
• riservare spazio fisso per banner pubblicitari, iframe ed embed;
• usare font-display: swap e precaricare i font critici;
• evitare di inserire contenuti dinamici sopra a quelli già visibili;
• posizionare correttamente popup, cookie banner e notifiche;
• testare il comportamento del layout su tutti i breakpoint responsive.

Core Web Vitals e Core Web Vitals 2.0: cosa sta cambiando

All’inizio del 2026 Google ha avviato i test di quello che molti chiamano già Core Web Vitals 2.0, una possibile evoluzione del set di metriche attuali. La novità più discussa è il Visual Stability Index (VSI), una metrica più sofisticata pensata per superare alcuni limiti del CLS attuale.

La differenza principale è che mentre il CLS misura tutti gli spostamenti visivi indistintamente, il VSI distingue tra spostamenti inattesi e spostamenti attesi dall’utente. Se clicco su un menu che si espande, lo spostamento di contenuti è una conseguenza prevista della mia azione e non dovrebbe essere penalizzato. Il CLS attuale non fa questa distinzione, il VSI sì.

Al momento il VSI è ancora in fase di test e non rappresenta un fattore di ranking ufficiale, ma è ragionevole aspettarsi che diventi parte integrante dei Core Web Vitals nei prossimi anni. Chi lavora sulle performance dovrebbe iniziare a tenerlo d’occhio.

L’errore più grave: pensare ai Core Web Vitals come a un progetto una tantum

Concludo con quella che è secondo me la considerazione più importante di tutto l’articolo. I Core Web Vitals non sono un audit da fare una volta sola, sono un parametro da monitorare costantemente nel tempo.

Ogni nuovo plugin installato, ogni script di tracking aggiunto, ogni modifica al tema, ogni cambio di hosting può introdurre regressioni che peggiorano le metriche senza che nessuno se ne accorga immediatamente. Le aziende che mantengono nel tempo punteggi nella fascia “buono” sono quelle che hanno integrato il monitoraggio delle performance nel proprio flusso di lavoro quotidiano.

Una pratica che consiglio sempre ai miei clienti è quella di impostare alert automatici su soglie più severe di quelle ufficiali (per esempio LCP > 2,0 secondi, INP > 160 millisecondi, CLS > 0,08) in modo da intercettare i problemi prima che impattino sui dati CrUX e quindi sui ranking. È un piccolo investimento iniziale che ripaga ampiamente nel tempo.

Se vuoi un approfondimento ancora più ampio sul ruolo dei Core Web Vitals nell’ambito di una verifica completa di un sito, la mia guida completa all’analisi SEO di un sito web li inquadra all’interno del quadro generale dei controlli da effettuare.