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 come parte dei segnali dedicati all’esperienza di pagina.

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.

Dal 2021 fanno parte dei segnali di esperienza di pagina di Google. Le funzioni AI nei risultati non modificano le soglie documentate né dimostrano un aumento automatico del loro peso: vanno ottimizzati soprattutto perché descrivono problemi reali per gli utenti.

Indice

1. Le tre metriche: LCP, INP e CLS
2. Come misurare i Core Web Vitals
3. Perché il tuo sito probabilmente non va bene
4. Come migliorare LCP
5. Come migliorare INP
6. Come migliorare CLS
7. Il ruolo dell’infrastruttura server
8. FAQ

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 rientra nella fascia scarsa e richiede diagnosi.

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, il report Core Web Vitals raggruppa gli URL in base ai dati sul campo disponibili. È un punto di partenza utile per osservare problemi reali; per URL con traffico insufficiente occorrono anche misure di laboratorio o RUM coerenti.

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 — Il pannello Performance offre metriche in tempo reale e analisi dettagliate del caricamento. Queste funzioni hanno sostituito il ruolo della Web Vitals Extension, il cui supporto è terminato nel 2025.

Una distinzione importante: PageSpeed Insights mostra sia dati di laboratorio (simulati) sia dati di campo aggregati nel Chrome UX Report. I primi aiutano a diagnosticare; i secondi descrivono l’esperienza osservata nel tempo e possono non essere disponibili per URL con poco traffico.

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 — File multi-megabyte caricati nelle dimensioni originali invece di versioni ridimensionate e compresse per il contesto. Possono assorbire gran parte del budget di caricamento della pagina.

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 va scomposto nel percorso completo: risposta iniziale, scoperta e caricamento della risorsa principale, quindi ritardo di rendering dell’elemento. Il collo di bottiglia cambia da pagina a pagina.

Ottimizza la risorsa LCP quando la misura indica che è il collo di bottiglia

WebP e AVIF possono ridurre il peso rispetto ai formati tradizionali, ma il risultato dipende da immagine e compressione. Formato, dimensioni e fallback vanno scelti e misurati nel contesto reale del sito.

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 può servire una risposta già pronta invece di rigenerarla a ogni richiesta. Il beneficio dipende da applicazione, contenuto e strategia di invalidazione e va misurato senza assumere un guadagno fisso.

5. Come Migliorare INP

L’INP misura la reattività alle interazioni. JavaScript e attività lunghe sul thread principale sono cause frequenti, ma bisogna misurare anche ritardo dell’input, elaborazione e presentazione del frame successivo.

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 quali attività occupano il thread principale. La priorità va assegnata ai colli di bottiglia misurati, distinguendo codice proprietario, librerie e servizi di terze parti.

Carica gli script di terze parti in modo differito

Pixel di tracciamento, widget di chat e tool di analisi possono spesso essere caricati con defer o async, oppure attivati più tardi. La scelta dipende da consenso, dipendenze e funzione: va misurata e collaudata per evitare regressioni o perdita di dati necessari.

6. Come Migliorare CLS

Il CLS nasce da spostamenti inattesi del layout: immagini senza spazio riservato, contenuti inseriti dinamicamente, font e altre variazioni possono contribuire in modo diverso.

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. font-display: optional può ridurre il rischio evitando uno scambio tardivo; size-adjust aiuta a calibrare il fallback. La soluzione va verificata sul font e sui browser effettivi.

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.

Il TTFB va valutato per area geografica, tipo di pagina e infrastruttura. Un valore alto richiede di distinguere rete, cache, applicazione e database prima di intervenire:

• 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. Una risposta iniziale lenta consuma una parte importante del tempo disponibile per mostrare il contenuto principale; il suo impatto va misurato insieme a rete, cache, rendering e risorse della pagina.

FAQ

I Core Web Vitals influenzano davvero il ranking su Google?

Fanno parte dei segnali di esperienza di pagina e possono contribuire alla valutazione complessiva. Non esiste però una penalizzazione automatica indipendente dal contenuto né la garanzia di salire migliorando un singolo valore.

Qual è il punteggio PageSpeed minimo per stare tranquilli?

PageSpeed Insights assegna un punteggio di laboratorio da 0 a 100, utile per confrontare test eseguiti in condizioni coerenti. Non esiste però un punteggio minimo che garantisca ranking o conversioni: vanno letti separatamente LCP, INP e CLS, dati di campo, diagnostica e comportamento reale degli utenti.

Mobile e desktop contano allo stesso modo?

Google usa il crawling mobile-first, ma prestazioni mobile e desktop vanno osservate separatamente. Sul mobile emergono spesso più limiti per rete e potenza del dispositivo: è una priorità operativa, non una regola universale sul “peso” di una metrica.

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?

I dati CrUX usati per i Core Web Vitals aggregano una finestra mobile di 28 giorni; non si tratta di attendere 28 giorni per ogni aggiornamento. Per siti stabili è utile osservare l’andamento periodico, mentre dopo un cambiamento significativo conviene verificare subito in laboratorio e seguire poi l’evoluzione dei dati sul campo.

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.