Core Web Vitals 2026: Cosa Sono, Perché Contano e Come Migliorarli

Hai mai abbandonato un sito perché ci metteva troppo a caricarsi? O perché mentre stavi per cliccare un pulsante, la pagina si è spostata e hai cliccato su qualcos’altro? Quelle esperienze hanno un nome tecnico — e da qualche anno Google le misura e le usa per decidere dove posizionare il tuo sito nella classifica dei risultati.

Si chiamano Core Web Vitals: tre metriche che fotografano la qualità dell’esperienza che un utente ha quando visita una pagina web. Non misurano se il sito è bello o se i contenuti sono validi — misurano se la pagina funziona bene nel momento in cui una persona reale la sta usando.

Sono diventati fattori di ranking ufficiali nel 2021. Nel 2026, con la progressiva integrazione dell’AI nei risultati di ricerca, il peso dell’esperienza utente nella valutazione complessiva di un sito è aumentato ulteriormente. Eppure la maggioranza dei siti italiani ancora non li ha ottimizzati — e lo vediamo ogni volta che facciamo un’analisi.

Indice

1. Le Tre Metriche: LCP, INP e CLS

LCP — Largest Contentful Paint

In parole semplici: quanto tempo impiega il contenuto principale della pagina a diventare visibile.

È la metrica che misura la velocità percepita dal punto di vista dell’utente. Non quando la pagina inizia a caricarsi, ma quando la parte più importante — l’immagine principale, il titolo, il blocco di testo centrale — è effettivamente visibile e leggibile.

Un LCP sotto i 2,5 secondi è considerato buono da Google. Tra 2,5 e 4 secondi è da migliorare. Oltre 4 secondi è un problema serio.

INP — Interaction to Next Paint

In parole semplici: quanto velocemente la pagina risponde quando l’utente fa qualcosa — clicca un bottone, apre un menu, compila un campo.

Questa metrica ha sostituito FID (First Input Delay) nel marzo 2024, perché misura la reattività in modo più completo: non solo il primo clic, ma tutte le interazioni durante la navigazione. Un sito che si carica veloce ma risponde lentamente ai clic è comunque una cattiva esperienza.

Un INP sotto i 200 millisecondi è considerato buono. Tra 200 e 500ms è da migliorare. Oltre 500ms è problematico.

CLS — Cumulative Layout Shift

In parole semplici: quanto la pagina “salta” mentre si carica, spostando elementi che l’utente stava guardando o su cui stava per cliccare.

È la metrica che cattura quell’esperienza frustrante in cui stai per cliccare su un link e all’improvviso si carica un banner pubblicitario che sposta tutto verso il basso — e finisci per cliccare sulla cosa sbagliata.

Un CLS sotto 0,1 è considerato buono. Tra 0,1 e 0,25 è da migliorare. Sopra 0,25 è un problema che Google penalizza.

2. Come Misurare i Core Web Vitals

Prima di agire, è necessario sapere dove si trova il problema. Gli strumenti principali sono accessibili gratuitamente:

Google Search Console — Se il tuo sito è verificato su Search Console, trovi il report “Esperienza pagina” con i dati reali degli utenti suddivisi per URL. È il punto di partenza obbligatorio: mostra i problemi reali su traffico reale, non simulazioni.

PageSpeed Insights (pagespeed.web.dev) — Analizza una singola URL e restituisce un punteggio da 0 a 100 separato per mobile e desktop, con l’indicazione precisa di ogni metrica e le cause principali dei problemi. È il tool più immediato per una diagnosi rapida.

Chrome DevTools — Per chi ha familiarità con gli strumenti per sviluppatori del browser, il pannello Performance permette un’analisi granulare di ogni millisecondo del caricamento della pagina.

Web Vitals Extension — Un’estensione di Chrome che mostra le metriche in tempo reale mentre navighi il sito, utile per identificare problemi su pagine specifiche.

Una distinzione importante: PageSpeed Insights mostra sia dati di laboratorio (simulati) che dati di campo (reali). I dati che Google usa per il ranking sono quelli reali, raccolti dagli utenti tramite Chrome. Se il tuo sito ha poco traffico, i dati reali potrebbero non essere disponibili.

3. Perché il Tuo Sito Probabilmente Non Va Bene

Nelle analisi che facciamo regolarmente su siti italiani, i problemi ricorrenti sono sempre gli stessi. Non perché chi ha costruito il sito fosse incapace, ma perché certe scelte vengono fatte senza pensare all’impatto sulle performance:

Immagini non ottimizzate — Immagini caricate nelle dimensioni originali della fotocamera (spesso 4-6MB) invece di versioni ridimensionate e compresse. Da sole, possono azzerare qualsiasi altro sforzo di ottimizzazione.

Troppi plugin e script di terze parti — Ogni plugin aggiunge codice che il browser deve scaricare ed eseguire. Analytic tools, chat widget, pixel di tracciamento, font esterni: si sommano rapidamente e rallentano tutto.

Hosting di bassa qualità — Il tempo di risposta del server (TTFB, Time To First Byte) è la base su cui si costruisce qualsiasi ottimizzazione. Con un hosting lento, anche un sito perfettamente ottimizzato avrà un LCP scadente.

Nessun sistema di caching — Ogni pagina viene generata da zero ad ogni richiesta, invece di essere servita da una copia già pronta. Su WordPress, questo problema è amplificato.

Font web caricati in modo errato — I font custom sono una delle cause più comuni di CLS: la pagina mostra prima un font di sistema, poi il font custom si carica e sposta il layout.

4. Come Migliorare LCP

L’LCP dipende principalmente da due fattori: la velocità con cui il server risponde e la dimensione dell’elemento principale della pagina.

Ottimizza le immagini — è la priorità assoluta

Il formato WebP offre una qualità visiva equivalente al JPEG con file fino al 30% più leggeri. Il formato AVIF, supportato da tutti i browser moderni nel 2026, va anche oltre. Ridimensiona sempre le immagini alla dimensione massima in cui vengono effettivamente mostrate — non ha senso caricare un’immagine da 3000px di larghezza se il contenitore è largo 800px.

Su WordPress, plugin come ShortPixel o Imagify automatizzano questa conversione. Su siti statici o personalizzati, l’ottimizzazione va gestita nel processo di build.

Usa il lazy loading — ma con giudizio

Il lazy loading posticipa il caricamento delle immagini che non sono visibili nella finestra iniziale. È utile per tutto ciò che si trova in fondo alla pagina — ma non deve mai essere applicato all’immagine principale, quella che contribuisce all’LCP. Un errore comune è attivare il lazy loading globale su tutte le immagini e peggiorare involontariamente l’LCP.

Implementa il caching lato server

Un sistema di caching serve la pagina già costruita invece di rigenerarla ad ogni richiesta. La differenza in termini di TTFB può essere di 10-20 volte. Su server gestiti, questa configurazione va fatta a livello di web server (Nginx o Apache) o tramite soluzioni dedicate come Varnish.

5. Come Migliorare INP

L’INP misura la reattività alle interazioni, ed è quasi sempre un problema di JavaScript che blocca il browser.

Identifica gli script pesanti

Ogni pezzo di JavaScript che viene eseguito nel thread principale del browser è un potenziale ostacolo alla reattività. Script di analytics, widget di terze parti, librerie pesanti importate per usare una funzione su dieci: sono le cause più frequenti di un INP elevato.

Il tab Performance di Chrome DevTools mostra esattamente quali script impiegano più tempo. Spesso si scopre che il 90% del tempo di esecuzione è occupato da uno o due script di terze parti che potrebbero essere caricati in modo differito o rimossi.

Carica gli script di terze parti in modo differito

Pixel di tracciamento, widget di chat, tool di analisi: nella maggior parte dei casi non devono essere disponibili nell’istante in cui la pagina si apre. Caricarli con attributo defer o async, o attivarli solo dopo la prima interazione dell’utente, migliora l’INP senza sacrificare funzionalità.

Riduci il JavaScript inutilizzato

Un audit del codice JavaScript rivela spesso librerie importate interamente quando si usa solo una piccola parte delle loro funzionalità. In questi casi il tree shaking — la rimozione automatica del codice non utilizzato durante la build — può ridurre significativamente il peso degli script.

6. Come Migliorare CLS

Il CLS è quasi sempre causato da elementi che la pagina non sa dove mettere finché non ha finito di caricarsi.

Specifica sempre le dimensioni di immagini e video

Se il browser non conosce in anticipo le dimensioni di un’immagine, mostra prima lo spazio vuoto e poi la inserisce quando è scaricata — causando lo spostamento degli altri elementi. Aggiungere gli attributi width e height all’elemento <img> (o usare il CSS aspect-ratio) risolve la maggior parte dei casi di CLS da immagini.

Riserva lo spazio per i font custom

Quando un font web si carica dopo che il browser ha già mostrato il testo con un font di sistema, il cambio di tipografia può spostare il layout se i due font hanno metriche diverse. La proprietà CSS font-display: optional evita il problema usando il font custom solo se è già nella cache, senza mai causare re-layout. In alternativa, size-adjust permette di calibrare le dimensioni del font di fallback per corrispondere a quelle del font custom.

Attenzione ai banner e agli elementi inseriti dinamicamente

Pubblicità, cookie banner, notifiche: se vengono inseriti nella pagina dopo il caricamento iniziale e spostano il contenuto già visibile, contribuiscono negativamente al CLS. La soluzione è riservare in anticipo lo spazio che occuperanno, in modo che il layout non si sposti quando appaiono.

7. Il Ruolo dell’Infrastruttura Server

C’è un aspetto che viene spesso ignorato nel dibattito sui Core Web Vitals: tutte le ottimizzazioni front-end hanno un tetto massimo determinato dalla velocità del server sottostante.

Il TTFB (Time To First Byte) — il tempo che il browser aspetta prima di ricevere il primo byte di risposta dal server — è il pavimento su cui si costruisce qualsiasi altra ottimizzazione. Con un TTFB alto, anche un sito perfettamente ottimizzato non raggiungerà mai un LCP eccellente.

Un TTFB sotto i 200ms è l’obiettivo. Raggiungerlo richiede:

Un server geograficamente vicino agli utenti — O l’uso di una CDN (Content Delivery Network) che distribuisce i contenuti su nodi globali
Una configurazione server ottimizzata — Versione PHP aggiornata, OPcache attivo, configurazione di Nginx o Apache rivista per il carico specifico del sito
Un piano di hosting adeguato — Su hosting condivisi economici, il TTFB è strutturalmente alto perché le risorse vengono divise tra decine di siti

Questo è il punto in cui SEO e infrastruttura si incontrano inevitabilmente. Puoi ottimizzare ogni immagine e ogni riga di JavaScript, ma se il server risponde in 800ms sei già fuori dai parametri di un LCP buono prima ancora di iniziare.

FAQ

I Core Web Vitals influenzano davvero il ranking su Google?

Sì, sono fattori di ranking ufficiali dal 2021. Non sono il fattore dominante — la pertinenza del contenuto e l’autorevolezza del sito contano di più — ma in contesti competitivi dove due siti sono equivalenti per qualità del contenuto, i Core Web Vitals possono fare la differenza. Inoltre, un sito con metriche pessime può essere penalizzato direttamente indipendentemente dalla qualità dei contenuti.

Qual è il punteggio PageSpeed minimo per stare tranquilli?

PageSpeed Insights assegna un punteggio da 0 a 100, ma il numero in sé non è ciò che Google usa per il ranking — Google usa le singole metriche (LCP, INP, CLS) e le loro soglie. Detto questo, un punteggio sotto 50 su mobile è quasi sempre il segnale che ci sono problemi seri da risolvere. Sopra 70 su mobile è un buon punto di partenza. Sopra 90 è eccellente.

Mobile e desktop contano allo stesso modo?

Google usa prevalentemente il crawling mobile-first dal 2019 — valuta il tuo sito principalmente come lo vede uno smartphone. I Core Web Vitals su mobile hanno quindi più peso. È comune vedere punteggi molto diversi tra mobile e desktop: il mobile è generalmente più penalizzato perché le connessioni sono più lente e la potenza di calcolo dei telefoni è inferiore ai computer.

Posso migliorare i Core Web Vitals da solo o serve un tecnico?

Dipende dalla struttura del sito. Alcune ottimizzazioni di superficie — comprimere le immagini, rimuovere script non necessari — sono accessibili a chiunque con gli strumenti giusti. Le ottimizzazioni che producono i miglioramenti più significativi e duraturi — configurazione del server, gestione del TTFB, architettura del codice, ottimizzazione delle query al database — richiedono interventi sull’infrastruttura che necessitano competenze tecniche specifiche. La regola pratica: se PageSpeed Insights indica problemi lato server o di esecuzione JavaScript, non è territorio per il fai-da-te.

Con quale frequenza dovrei controllare i Core Web Vitals del mio sito?

Google Search Console aggiorna i dati con un ritardo di circa 28 giorni e mostra l’andamento nel tempo. Controllare mensilmente è sufficiente per siti stabili. Dopo ogni intervento significativo sul sito — aggiornamento del tema, aggiunta di nuovi plugin, cambio di hosting — vale la pena fare una verifica immediata con PageSpeed Insights.

Il mio sito ha un buon punteggio su desktop ma pessimo su mobile. Da dove inizio?

La differenza è quasi sempre causata da immagini non ottimizzate per schermi piccoli, JavaScript eccessivo che rallenta i dispositivi meno potenti, o font e risorse caricate senza priorità corretta. Il report di PageSpeed Insights per la versione mobile indica esattamente quali elementi contribuiscono di più ai problemi — è il punto di partenza più efficiente.

I Core Web Vitals del tuo sito sono nel range buono, da migliorare o problematico? Facciamo un’analisi completa: SEO tecnico, velocità, infrastruttura server e ottimizzazione delle performance. Contattaci per scoprire cosa sta frenando il tuo sito.