Core Web Vitals: Cosa Sono e Come Migliorarli

Pubblicato: 2026-02-27

Da quando Google ha introdotto i Core Web Vitals come segnale di ranking, la velocità e la reattività di un sito web non sono più un optional. Sono diventate metriche concrete, misurabili e, soprattutto, determinanti per il posizionamento nelle SERP. Il concetto di fondo è semplice: un sito che offre un'esperienza utente fluida merita di stare più in alto rispetto a uno che fa attendere, scatta o si sposta sotto le dita di chi lo naviga. Scopri di più sull'ottimizzazione velocità sito.

In questa guida analizziamo nel dettaglio cosa sono i Core Web Vitals, quali metriche li compongono, come misurarli e quali interventi pratici adottare per portare ogni parametro nella zona verde. Se lavorate sulla SEO tecnica, questa è una delle aree dove il vostro intervento può fare la differenza più visibile.

Cosa sono i Core Web Vitals

I Core Web Vitals sono un sottoinsieme delle metriche Web Vitals definite da Google per valutare l'esperienza utente reale su una pagina web. Non si tratta di punteggi teorici, ma di dati raccolti da utenti reali attraverso il Chrome User Experience Report (CrUX). Google li utilizza come parte dei segnali di page experience, insieme ad altri aspetti dell'esperienza sulla pagina, in linea con ciò che i sistemi di ranking cercano di premiare.

La documentazione ufficiale su web.dev/vitals definisce tre metriche fondamentali, ciascuna legata a un aspetto diverso dell'esperienza: la velocità di caricamento, la reattività all'interazione e la stabilità visiva del layout. Vediamole una per una.

LCP: Largest Contentful Paint

Il Largest Contentful Paint misura il tempo necessario affinché l'elemento di contenuto più grande visibile nel viewport venga renderizzato completamente. Può trattarsi di un'immagine hero, di un blocco di testo o di un video. In sostanza, LCP risponde alla domanda: quanto deve aspettare l'utente prima di vedere qualcosa di significativo sullo schermo?

I valori di riferimento sono:

• Buono: entro 2,5 secondi
• Da migliorare: tra 2,5 e 4 secondi
• Scarso: oltre 4 secondi

Come migliorare LCP

La causa più frequente di un LCP lento è il caricamento di risorse pesanti che bloccano il rendering. Ecco gli interventi più efficaci:

• Ottimizzate le immagini. Il formato WebP o AVIF riduce il peso fino al 30-50% rispetto a JPEG. Servite immagini nelle dimensioni corrette con l'attributo srcset. Per una guida completa, consultate il nostro articolo sulla SEO per immagini.
• Utilizzate il preload per le risorse critiche. Se l'elemento LCP è un'immagine hero, aggiungete <link rel="preload" as="image" href="..."> nell'head del documento.
• Riducete il tempo di risposta del server (TTFB). Un hosting lento penalizza tutto il resto. Considerate una CDN e assicuratevi che la cache lato server sia configurata correttamente.
• Eliminate le risorse che bloccano il rendering. CSS e JavaScript non critici dovrebbero essere caricati in modo asincrono. Inline il CSS critico above-the-fold e differite il resto.
• Evitate il lazy loading sull'elemento LCP. Se l'immagine hero ha l'attributo loading="lazy", il browser ritarderà il suo caricamento, peggiorando proprio la metrica che volete ottimizzare.

INP: Interaction to Next Paint

L'Interaction to Next Paint ha sostituito il FID (First Input Delay) come metrica di reattività a partire dal 12 marzo 2024. Mentre il FID misurava solo il ritardo del primo input, INP considera tutte le interazioni durante l'intera sessione dell'utente: clic, tap, pressioni di tasti. La metrica finale corrisponde alla latenza peggiore osservata, escludendo i valori anomali.

I valori di riferimento:

• Buono: entro 200 millisecondi
• Da migliorare: tra 200 e 500 millisecondi
• Scarso: oltre 500 millisecondi

Come migliorare INP

Un INP elevato indica che il thread principale del browser è troppo occupato per rispondere rapidamente alle interazioni dell'utente. Le cause tipiche:

• Riducete il lavoro del thread principale. Script di terze parti, analytics pesanti e widget social possono saturare il browser. Caricate solo ciò che serve e rinviate il resto con defer o async.
• Spezzate i long task. Un'operazione JavaScript che dura più di 50 ms blocca il thread principale. Utilizzate requestIdleCallback o setTimeout per suddividere i task lunghi in parti più piccole.
• Riducete la complessità dei selettori CSS. Su pagine con migliaia di elementi DOM, selettori CSS troppo complessi rallentano il ricalcolo degli stili dopo ogni interazione.
• Minimizzate il DOM. Un documento con più di 1.500 nodi inizia a mostrare problemi di performance. Semplificate la struttura HTML dove possibile.

CLS: Cumulative Layout Shift

Il Cumulative Layout Shift misura la stabilità visiva della pagina. Avete presente quando state per cliccare su un link e, un istante prima, un banner pubblicitario spinge tutto verso il basso? Quello è un layout shift, e per l'utente è una delle esperienze più frustranti che il web possa offrire.

I valori di riferimento:

• Buono: entro 0,1
• Da migliorare: tra 0,1 e 0,25
• Scarso: oltre 0,25

Come migliorare CLS

• Specificate sempre le dimensioni delle immagini. Aggiungete gli attributi width e height ai tag <img> oppure riservate lo spazio tramite CSS con aspect-ratio. In questo modo il browser sa quanto spazio allocare prima ancora di scaricare l'immagine.
• Riservate spazio per gli annunci e gli embed. Se la pagina include banner pubblicitari, iframe o contenuti dinamici, assegnate loro un contenitore con dimensioni fisse.
• Evitate di inserire contenuto sopra quello già visibile. Un banner cookie che appare in cima alla pagina e spinge tutto verso il basso è una fonte classica di CLS. Preferite overlay o barre fisse che non spostano il contenuto.
• Caricate i font in modo ottimale. Il flash di testo invisibile (FOIT) o il flash di testo senza stile (FOUT) possono causare shift. Usate font-display: swap e precaricate i font con <link rel="preload">.

Come misurare i Core Web Vitals

Esistono diversi strumenti, ciascuno con un ruolo specifico. Ecco quelli che consigliamo:

• Google PageSpeed Insights: il punto di partenza. Mostra sia i dati di campo (utenti reali, dal CrUX) sia i dati di laboratorio (simulazione Lighthouse). I dati di campo sono quelli che Google utilizza per il ranking.
• Lighthouse: integrato in Chrome DevTools (tab "Lighthouse"), esegue un audit completo della pagina in ambiente controllato. Utile per diagnosticare problemi specifici e testare le correzioni prima della pubblicazione.
• Chrome DevTools - tab Performance: per un'analisi granulare. Potete registrare una sessione di navigazione e ispezionare ogni frame, ogni long task, ogni layout shift. È lo strumento più tecnico, ma anche il più potente.
• Google Search Console: la sezione "Esperienza con le pagine" mostra lo stato dei Core Web Vitals per l'intero sito, basandosi sui dati CrUX. Evidenzia le URL con problemi raggruppandole per tipo.
• Web Vitals Extension: un'estensione Chrome che mostra LCP, INP e CLS in tempo reale mentre navigate. Ideale per verifiche rapide durante lo sviluppo.

Un punto spesso frainteso: una pagina o un intero sito vengono classificati "buono", "da migliorare" o "scarso" sul 75° percentile delle visite reali (75% dei caricamenti deve rispettare la soglia "buono" perché la pagina risulti "buona"), non sulla singola misurazione che vedete in un test isolato. È per questo che un test Lighthouse impeccabile può comunque convivere con un giudizio "da migliorare" in Search Console: quest'ultimo riflette l'esperienza reale aggregata di utenti diversi, su reti e dispositivi diversi, non il singolo caricamento in laboratorio.

Problemi comuni e soluzioni rapide

Nella pratica, la maggior parte dei siti italiani che analizziamo presenta problemi ricorrenti. Ecco i più frequenti con le relative soluzioni:

• Immagini hero non ottimizzate. Spesso l'elemento LCP è un'immagine da 2-3 MB in formato PNG. La soluzione è convertirla in WebP, ridimensionarla e precaricarla. Per un e-commerce con molte immagini prodotto, la SEO per e-commerce richiede un'attenzione particolare a questo aspetto.
• Script di terze parti non gestiti. Chat widget, pixel di tracciamento, font esterni: ciascuno aggiunge latenza. Caricate solo quello che serve davvero e rinviate il caricamento dopo l'interazione iniziale.
• Assenza di caching. Senza una policy di cache adeguata, ogni visita ricarica tutte le risorse da zero. Configurate header Cache-Control con durate appropriate per asset statici.
• Font web caricati in modo sincrono. Google Fonts caricato con un semplice <link> nel head blocca il rendering. Usate il preconnect al dominio dei font e aggiungete font-display: swap nel CSS.
• Layout che dipende da JavaScript. Se il layout della pagina viene costruito o modificato da script, ogni ritardo nell'esecuzione si traduce in CLS. Preferite layout definiti interamente in HTML e CSS.

Conclusione

I Core Web Vitals non sono un capriccio di Google. Sono la traduzione in numeri di ciò che ogni utente percepisce: la pagina si carica velocemente? Risponde ai miei clic? Resta stabile mentre la uso? Lavorare su queste tre metriche significa migliorare l'esperienza reale delle persone che visitano il vostro sito, e come effetto collaterale, il posizionamento nei risultati di ricerca.

L'approccio migliore è sistematico: misurate, identificate i problemi peggiori, correggeteli e misurate di nuovo. Partite da LCP, perché è la metrica che ha l'impatto più visibile sia per l'utente sia per il ranking. Poi passate a CLS, che spesso si risolve con interventi semplici. Infine, affrontate INP, che richiede una comprensione più approfondita di come JavaScript interagisce con il browser.

Se volete approfondire gli aspetti tecnici che influenzano queste metriche, la nostra guida alla SEO tecnica copre argomenti come crawlability, rendering e architettura del sito che sono strettamente collegati alle performance.

Strumenti consigliati per la verifica

• Screaming Frog — Crawling con integrazione Core Web Vitals
• Sitebulb — Audit performance con hints CWV
• Confronto Screaming Frog vs Sitebulb
• Sitebulb vs Ahrefs
• Alternative a Screaming Frog

Domande Frequenti