Web Performance

Core Web Vitals: cosa sono e perché contano per il ranking Google

I Core Web Vitals sono i segnali di ranking più importanti per Google. Questa guida spiega LCP, INP e CLS in modo semplice, come misurarli, e da dove iniziare a ottimizzarli per SEO e conversioni.

A cura di ContatPubblicato il 9 min di lettura
Dashboard web con indicatori per caricamento, interazione e stabilità visiva
Core Web Vitals sotto controllo

Tre metriche, una pagina più affidabile

LCP, INP e CLS descrivono tre momenti diversi della stessa esperienza: il contenuto che arriva, la risposta al gesto e la stabilità del layout. Misurarli insieme aiuta a scegliere interventi tecnici che migliorano anche la fiducia e le conversioni.

Cosa sono i Core Web Vitals

I Core Web Vitals sono tre metriche di performance che misurano come gli utenti percepiscono l'esperienza su una pagina web. Non è un'opinione soggettiva: sono numeri concreti che misura il browser.

Google ha reso questi KPI obbligatori per il ranking organico perché rispecchiano l'esperienza reale dell'utente. Un sito può avere contenuto di qualità, ma se è lento, instabile o non risponde agli input, gli utenti lo abbandonano.

I Core Web Vitals sono tre:

  • LCP (Largest Contentful Paint): Quanto velocemente carica il contenuto principale della pagina.
  • INP (Interaction to Next Paint): Quanto velocemente il browser risponde al click/touch dell'utente.
  • CLS (Cumulative Layout Shift): Quanto è stabile la pagina visivamente mentre si carica.

Se anche uno solo di questi tre è scarso, Google penalizza il ranking. Non puoi compensare un buon LCP con un cattivo INP.

Perché Google li usa come ranking signal

Google sa che le persone abbandonano i siti lenti. Se rimani su un sito lento, è perché il contenuto è talmente rilevante che compensi la lentezza. Ma nella maggior parte dei casi no: è semplicemente frustrazione.

Dal punto di vista di Google, premiare i siti veloci ha senso:

  • User satisfaction: Chi clicca su un risultato Google e atterra su una pagina lenta, ha cattiva esperienza. Google vuole che i risultati siano soddisfacenti.
  • Mobile-first index: La maggior parte del traffico web è da mobile. Su 3G, i millisecondi contano. Un sito che carica velocemente su desktop potrebbe essere lento su mobile.
  • Conversioni: La ricerca di settore mostra che siti veloci convertono meglio rispetto a siti lenti. Google sa questo e premia i siti performanti.
  • Ridurre spam: I siti spam spesso sono ospitati su hosting lento. Premiare i siti veloci è un modo indiretto di penalizzare i cattivi.

Quindi i Core Web Vitals non sono uno scherzo di Google: sono il segnale di ranking più importante dopo contenuto e backlink.

Le tre metriche principali

Ognuno dei tre Core Web Vitals misura un aspetto diverso dell'esperienza:

LCP (Largest Contentful Paint) misura il tempo fino a quando il pezzo più grande di contenuto (immagine, video, blocco di testo) non diventa visibile. È quello che l'utente percepisce come 'il sito si sta caricando?'.

INP (Interaction to Next Paint) misura il ritardo tra il momento in cui l'utente interagisce (clicca un bottone, scrive in un form) e il momento in cui il browser risponde visivamente. È la responsività percepita.

CLS (Cumulative Layout Shift) misura quanto il layout della pagina si sposta mentre si carica. Se clicchi un link e una pubblicità appare improvvisamente sopra, spostando il link di 100px, è un CLS negativo.

Tutte tre sono misure di percezione, non di velocità tecnica assoluta. Un sito può essere tecnicamente veloce su desktop ma terribile su mobile perché il JavaScript blocca l'interazione.

LCP: velocità di caricamento del contenuto principale

LCP misura quando il contenuto principale della pagina diventa visibile all'utente. Non il caricamento della pagina completa, solo la parte che l'utente vede.

Qual è il valore target?

  • Buono: Meno di 2.5 secondi
  • Deve migliorare: Tra 2.5 e 4 secondi
  • Scarso: Più di 4 secondi

Su mobile, 2.5 secondi è incredibilmente veloce. La maggior parte dei siti italiani non la raggiunge.

Cosa influenza LCP

  • Immagini non ottimizzate: Un'immagine di 5MB che dovrebbe essere 500KB blocca il caricamento.
  • JavaScript bloccante: Se il browser deve eseguire JavaScript prima di renderizzare, LCP aumenta.
  • CSS grande: Stylesheet non compresse rallentano il rendering.
  • Server lento: Se il server impiega 2 secondi a rispondere, il contatore parte da lì.
  • Hosting lontano geograficamente: Se il tuo server è in USA e l'utente è in Italia, c'è latenza di rete.

Come ottimizzare LCP

Ottimizzazione immagini: Usa formato WebP, comprimi, usa le dimensioni giuste. Lazy loading per immagini sotto il fold.

Ridurre JavaScript: Non caricare script grandi e inutili. Defer o async per gli script non-critical.

Inline CSS critico: Il CSS necessario per renderizzare above-the-fold deve essere inline nel tag <head>, non in un file esterno.

CDN globale: Se serve a italiani, il server deve essere in Europa. Un CDN come Cloudflare accelera anche i server lontani.

INP: reattività alle interazioni dell'utente

INP misura il tempo tra il momento in cui l'utente clicca un bottone, scrive in un form, o interagisce con la pagina, e il momento in cui il browser risponde visivamente.

Qual è il valore target?

  • Buono: Meno di 200 millisecondi
  • Deve migliorare: Tra 200 e 500ms
  • Scarso: Più di 500ms

200ms è il tempo di percezione umano: oltre, l'interazione 'sente' lenta.

Cosa influenza INP

  • JavaScript che blocca il main thread: Se il browser sta eseguendo codice complesso e l'utente clicca, deve aspettare che JavaScript termini.
  • Event listener male ottimizzati: Decine di event listener su scroll o resize che non sono throttled/debounced.
  • Layout recalculation: Se un'interazione scatena un re-render di metà pagina, INP sale.
  • CPU lenta nel client: Su un telefono vecchio, lo stesso codice è più lento.

Come ottimizzare INP

Ridurre il lavoro nel main thread: Long tasks (JavaScript che impiega più di 50ms) bloccano le interazioni.

Usare Web Workers: Sposta il calcolo pesante su un thread separato, il main thread resta disponibile per rispondere agli utenti.

Debounce/throttle gli event listener: Se ascolti scroll, non reagire a ogni pixel. Aspetta che l'utente finisca di scrollare.

Ridurre DOM: Un DOM gigante (5000+ nodi) rende il browser lento. Virtualizza liste lunghe.

CLS: stabilità visiva della pagina

CLS misura quanto il layout della pagina si sposta visivamente dopo il caricamento. Se clicchi un link e una pubblicità appare spostandolo, è un cattivo CLS.

Qual è il valore target?

  • Buono: Meno di 0.1
  • Deve migliorare: Tra 0.1 e 0.25
  • Scarso: Più di 0.25

CLS è un numero (non millisecondi): 0.1 significa che il 10% della viewport si sposta.

Cosa causa layout shift

  • Immagini senza dimensioni fisse: Se un'immagine non ha width e height espliciti, il browser non sa quanto spazio allocare. Quando carica, sposta il resto del contenuto.
  • Pubblicità che carica in ritardo: Una pubblicità sotto la fold carica dopo 3 secondi e sposta il footer.
  • Font che cambiano: Se usi @font-face, il font personalizzato può caricare dopo il font di fallback, cambiando le dimensioni del testo.
  • Overlay e modali: Un modal che appare improvvisamente sposta il contenuto dietro.
  • Cookie banner: Un banner che appare in cima sposta il resto della pagina giù.

Come ottimizzare CLS

Sempre specificare dimensioni immagini: <img width='800' height='600' src='...' />

Preallocare spazio per gli ad: Usa un contenitore con altezza fissa per le pubblicità. Se non carica, lo spazio rimane vuoto, niente shift.

Usare font-display: swap nel CSS per i web font. Il testo appare con fallback subito, il font personalizzato si sostituisce quando carica.

Animazioni controllate: Se usi CSS animations, assicurati che non causino layout shifts. Usa transform e opacity, che non causano ricalcolo.

Per approfondire CLS e le strategie di ottimizzazione, consulta l'articolo dedicato su CLS e cumulative layout shift.

Come misurare i Core Web Vitals

Non è indovinare. Ci sono strumenti ufficiali Google per misurare i Core Web Vitals su ogni pagina.

1. PageSpeed Insights

Lo strumento più semplice: vai su pagespeedinsights.web.dev, inserisci l'URL, e ottieni un report dei Core Web Vitals per mobile e desktop.

Pro: Gratuito, semplice, report visual e suggerimenti specifici.

Contro: Misura una sola volta, non vedi trend. I dati non sono i reali dati di utenti.

2. Google Search Console

Se il sito è verificato in Google Search Console, vai su 'Core Web Vitals' nel menu laterale. Vedrai:

  • Quante pagine hanno buoni Core Web Vitals
  • Quante hanno problemi
  • Quali metrica è il collo di bottiglia
  • Quali pagine specifiche hanno problemi

Pro: Dati reali da utenti che visitano il tuo sito. Trend nel tempo. Permette di identificare le pagine peggiori.

Contro: I dati hanno un ritardo di ~3 giorni.

3. Chrome UX Report

Google raccoglie dati da milioni di browser Chrome reali. Puoi visualizzare i dati in chromeuxreport.web.dev inserendo il tuo dominio.

Pro: Dati di utenti reali a livello di pagina e di device type. Puoi confrontare il tuo sito con i competitor.

Contro: Meno granulare di Search Console, più orientato all'analisi.

4. Lighthouse in Chrome DevTools

Apri Chrome, premi F12, vai su 'Lighthouse', e clicca 'Analyze page load'. Ottieni un report dettagliato con Core Web Vitals e suggerimenti specifici.

Pro: Locale, immediato, mostra ogni dettaglio di cosa rallenta la pagina.

Contro: I numeri dipendono dal tuo computer. Un Lighthouse su un MacBook M2 non è comparabile a uno su un vecchio telefono Android.

Quale strumento usare quando?

Prima volta: PageSpeed Insights per una misurazione veloce.

Monitoraggio continuo: Google Search Console per trend reali.

Debug specifico: Lighthouse per capire perché una pagina è lenta.

Benchmark vs competitor: Chrome UX Report per confronti pubblici.

Perché i Core Web Vitals contano per il tuo business

Non è solo un segnale di ranking. I Core Web Vitals influenzano direttamente il tuo fatturato.

Impact sulla SEO

Google ha confermato ufficialmente che i Core Web Vitals sono fattori di ranking. Un sito con buoni Core Web Vitals ottiene una migliore visibilità sui risultati di ricerca, a parità di contenuto. Se sei in posizione #2 con Core Web Vitals scarsi e il competitor in #3 li ha buoni, Google può promuovere il competitor.

Impact sulle conversioni

La ricerca di settore mostra che molti utenti mobile abbandonano un sito se la pagina impiega troppo tempo a caricare. Per e-commerce, ogni aumento di latenza causa una riduzione misurabile nelle conversioni. Un sito di e-commerce lento perde visitatori e fatturato potenziale rispetto a un sito veloce.

Impact su UX e retention

Un sito veloce, responsivo e stabile è un sito che l'utente visita di nuovo. Un sito lento e instabile genera frustrazione. La frustrazione diventa un'associazione mentale negativa con il tuo brand.

Impact operativo

Per chi sviluppa e mantiene il sito, i Core Web Vitals danno chiarezza. Non è più 'il sito è veloce?' ma 'LCP è 3 secondi, INP è 450ms, CLS è 0.15: dobbiamo migliorare INP e CLS'. È data-driven.

Primi passi pratici per ottimizzare i Core Web Vitals

Se il tuo sito ha Core Web Vitals scarsi, da dove inizi? Il rischio è affogare in mille cose da fare.

Fase 1: Misurazione

Non puoi ottimizzare quello che non misuri. Fai una misurazione baseline:

  • Apri Google Search Console, vai a Core Web Vitals, screenshot.
  • Apri PageSpeed Insights, misura le pagine principali (home, categoria, prodotto).
  • Annota i numeri in un foglio di calcolo.

Fase 2: Identificare il collo di bottiglia

Non devi ottimizzare tutti e tre i Core Web Vitals contemporaneamente. Identifica quale è il peggiore e inizia da quello.

Se il peggiore è LCP: Ottimizza immagini, ridurci JavaScript bloccante, usa CDN.

Se il peggiore è INP: Ridurci JavaScript nel main thread, debounce event listener, virtualizza DOM grandi.

Se il peggiore è CLS: Specifica dimensioni immagini, preallocare spazio per ad, font-display: swap.

Fase 3: Implementare fix rapidi

Ci sono fix che si implementano in 1-2 giorni:

  • Comprimere immagini: Usa Squoosh.app o ImageOptim per ridurre il peso.
  • Aggiungere width/height alle immagini.
  • Attivare gzip/brotli sul server (hosting provider lo fa di solito).
  • Attivare caching browser: Cache-Control headers per immagini statiche.

Fase 4: Fix strutturali

Questo impiega 1-2 settimane:

  • Ridisegnare il layout per ridurre CLS.
  • Refactor JavaScript per ridurre il peso.
  • Migrare su hosting migliore o CDN.

Fase 5: Monitoraggio continuo

Dopo 2-3 settimane, rimisura. Google Search Console aggiornerà i dati ogni 3 giorni.

Checklist: da dove iniziare per migliorare i tuoi Core Web Vitals

Questa checklist ti guida passo dopo passo:

  • ☐ Misuro i Core Web Vitals actuali su Google Search Console
  • ☐ Apro PageSpeed Insights per la homepage
  • ☐ Annoto i tre numeri (LCP, INP, CLS) in un foglio
  • ☐ Identifico quale metrica è la peggiore
  • ☐ Leggo i suggerimenti di PageSpeed per quella metrica
  • ☐ Implemento almeno 3 fix dal report
  • ☐ Compongo le immagini principali con Squoosh/ImageOptim
  • ☐ Aggiungo width/height a tutte le immagini sopra il fold
  • ☐ Chiedo al mio hosting se ha attivo gzip/brotli
  • ☐ Attivo caching browser nel file .htaccess o web.config
  • ☐ Rimisuro dopo 2 settimane
  • ☐ Se ancora scarso, approfondisco con Lighthouse per i dettagli
  • ☐ Coinvolgo uno sviluppatore per fix JavaScript/strutturali

Questo piano riduce il caos. Inizi da misurazioni concrete, poi fix rapidi, poi miglioramenti più grandi.

I Core Web Vitals non sono dettagli tecnici astratti. Sono il ponte tra il tuo codice e l'esperienza concreta dell'utente. Velocità, reattività, stabilità: sono quello che ogni utente sente quando usa il tuo sito.

Domande su Core Web Vitals

No. Google osserva i dati di Search Console per ~28 giorni. Se rimangono scarsi, inizia a penalizzare il ranking. Se migliori in 2 settimane, Google nota e aumenta il ranking in fretta.
Sì. Anche un WordPress del 2015 può avere buoni Core Web Vitals se le immagini sono ottimizzate, il server è veloce, e il plugin di cache è attivo. Non è il CMS che conta, è l'ottimizzazione.
Google indicizza principalmente per mobile (mobile-first index). Mobile è la priorità. Se il desktop è lento ma il mobile è veloce, stai bene per ranking. Ma ovvio: ottimizza entrambi se puoi.
Elementor aggiunge parecchio JavaScript. INP sarà sempre un po' compromesso. Ma puoi ancora ridurre il blocco: disabilita plugin inutili, lazy-load le immagini, riduci il DOM con plugin di cache come Autoptimize.
Statico aiuta: non c'è server-side rendering che rallenta. Ma puoi comunque avere immagini grosse, CSS non ottimizzato, CLS da layout instabile. Statico è un vantaggio, non una garanzia.

Ottimizza i Core Web Vitals del tuo sito

LCP, INP, CLS: la velocità conta per ranking e conversioni. Ti aiutiamo a misurare, diagnosticare e ottimizzare i Core Web Vitals del tuo sito per SEO e user experience.