Solo il 48% dei siti web supera la valutazione dei Core Web Vitals nel 2026. Questo significa che più della metà dei siti italiani sta perdendo posizioni su Google, conversioni e clienti per problemi di performance facilmente risolvibili.
I Core Web Vitals sono tre metriche che Google utilizza per misurare l’esperienza utente reale sul tuo sito: velocità di caricamento (LCP), reattività alle interazioni (INP) e stabilità visiva (CLS). Dal 2021 fanno parte dei segnali di ranking, e nel December 2025 Core Update i siti con LCP superiore a 3 secondi hanno subito il 23% di perdita di traffico in più rispetto ai competitor più veloci.
In questa guida completa scoprirai cosa sono esattamente i Core Web Vitals, come misurarli con gli strumenti giusti, e le tecniche di ottimizzazione che ho testato su decine di siti WordPress per raggiungere punteggi “Good” su tutte e tre le metriche. Troverai anche checklist pratiche e priorità di intervento per ogni budget.
Cosa sono i Core Web Vitals: definizione e metriche 2026
I Core Web Vitals sono un insieme di metriche standardizzate che Google ha introdotto nel maggio 2020 per quantificare tre aspetti fondamentali dell’esperienza utente: quanto velocemente il contenuto principale diventa visibile, quanto rapidamente la pagina risponde alle interazioni, e quanto il layout rimane stabile durante il caricamento.
A marzo 2024, Google ha sostituito la metrica First Input Delay (FID) con Interaction to Next Paint (INP), rendendo la valutazione della reattività più accurata e completa. Le tre metriche attuali sono quindi LCP, INP e CLS.
LCP: Largest Contentful Paint
Il Largest Contentful Paint misura il tempo necessario affinché l’elemento di contenuto più grande nel viewport diventi visibile. Tipicamente questo elemento è un’immagine hero, un video o un blocco di testo principale. LCP indica quando l’utente percepisce che “la pagina è pronta”.
| Valutazione | Soglia LCP | Significato |
|---|---|---|
| Good (Verde) | ≤ 2,5 secondi | Esperienza ottimale |
| Needs Improvement (Arancione) | 2,5 – 4 secondi | Da migliorare |
| Poor (Rosso) | > 4 secondi | Esperienza negativa |
Secondo i dati di HTTP Archive di novembre 2025, solo il 62% delle origini passa la soglia LCP su desktop, mentre su mobile la percentuale scende ulteriormente. LCP è la metrica più difficile da superare per la maggior parte dei siti.
INP: Interaction to Next Paint
Interaction to Next Paint ha sostituito First Input Delay a marzo 2024, offrendo una misurazione più completa della reattività. Mentre FID misurava solo il ritardo della prima interazione, INP considera tutte le interazioni durante l’intera visita e riporta la peggiore.
INP misura tre fasi per ogni interazione:
- Input Delay: tempo dall’azione utente (click, tap, keypress) all’esecuzione dell’event handler
- Processing Time: tempo di esecuzione dell’event handler
- Presentation Delay: tempo per renderizzare il feedback visivo dopo il completamento dell’handler
| Valutazione | Soglia INP | Significato |
|---|---|---|
| Good (Verde) | ≤ 200 ms | Il sito risponde istantaneamente |
| Needs Improvement (Arancione) | 200 – 500 ms | Ritardo percepibile |
| Poor (Rosso) | > 500 ms | Il sito sembra “bloccato” |
Nell’analisi del December 2025 Core Update, i siti con INP superiore a 300ms hanno registrato un calo del 31% nel traffico organico, particolarmente su dispositivi mobile.
CLS: Cumulative Layout Shift
Cumulative Layout Shift quantifica la stabilità visiva misurando quanto gli elementi della pagina si spostano inaspettatamente durante il caricamento. Hai presente quando stai per cliccare un pulsante e improvvisamente la pagina “salta” facendoti cliccare qualcos’altro? Ecco, CLS misura esattamente questo.
| Valutazione | Soglia CLS | Significato |
|---|---|---|
| Good (Verde) | ≤ 0,1 | Layout stabile |
| Needs Improvement (Arancione) | 0,1 – 0,25 | Alcuni spostamenti |
| Poor (Rosso) | > 0,25 | Layout instabile, frustrante |
CLS è generalmente la metrica più facile da ottimizzare: il 65% dei siti analizzati presenta già un punteggio “Good”. Tuttavia, quando è scarso, l’impatto sull’esperienza utente è devastante.
Perché i Core Web Vitals sono importanti per la SEO
Google ha confermato ufficialmente che i Core Web Vitals sono fattori di ranking dal Page Experience Update del giugno 2021. Secondo ricerche di settore del 2025, rappresentano circa il 10-15% dei segnali di ranking. Non sono il fattore dominante (contenuto e autorevolezza rimangono centrali), ma funzionano come “tiebreaker” quando altri fattori sono comparabili.
In pratica, se il tuo contenuto è rilevante quanto quello di un competitor ma il tuo sito è più veloce e stabile, avrai un vantaggio competitivo nelle SERP. Come ha dichiarato Google:
“Ottimizzare per questi fattori rende il web più piacevole per gli utenti su tutti i browser e superfici. Crediamo che questo contribuirà al successo commerciale sul web, poiché gli utenti diventano più coinvolti e possono completare transazioni con meno frizioni.”
Correlazione tra Core Web Vitals e ranking
I dati parlano chiaro. Secondo studi condotti su milioni di URL:
- Le pagine in posizione 1 hanno il 10% di probabilità in più di superare i Core Web Vitals rispetto alle pagine in posizione 9
- Dalla posizione 1 alla 5 c’è un calo del 2% nel tasso di superamento per ogni posizione
- Dalla posizione 5 alla 9 il calo accelera al 10-11%
- L’84% delle URL nei top 10 risultati mobile USA ha punteggi “needs improvement” o “poor”
Quest’ultimo dato è particolarmente interessante: significa che c’è ancora un’enorme opportunità per chi ottimizza. Solo il 16% dei risultati in prima pagina ha Core Web Vitals ottimali.
Impatto sulle conversioni e metriche business
L’impatto dei Core Web Vitals va ben oltre il posizionamento organico. I case study di aziende che hanno ottimizzato le performance mostrano risultati impressionanti:
| Azienda | Miglioramento | Risultato business |
|---|---|---|
| -40% tempo percepito | +15% traffico SEO, +15% conversioni signup | |
| Vodafone | -31% LCP | +8% vendite, +15% tasso carrello-visita |
| Renault | -1 secondo LCP | -14% bounce rate, +13% conversioni |
| Yahoo! JAPAN | Ottimizzazione CLS | +15,1% pagine/sessione, +13,3% durata sessione |
Amazon ha calcolato che ogni 100ms di latenza costa l’1% delle vendite. Un ritardo di 100 millisecondi nella velocità della pagina può ridurre le conversioni del 7%. Con questi numeri, l’ottimizzazione dei Core Web Vitals diventa un investimento con ROI misurabile.
Come misurare i Core Web Vitals del tuo sito
Google offre diversi strumenti per misurare i Core Web Vitals, ciascuno con caratteristiche specifiche. La distinzione fondamentale è tra dati di laboratorio (lab data) e dati sul campo (field data).
I dati di laboratorio provengono da test sintetici in ambiente controllato (come Lighthouse), utili per diagnosticare problemi. I dati sul campo provengono da utenti reali attraverso il Chrome User Experience Report (CrUX), e sono quelli che Google utilizza effettivamente per il ranking.
Google Search Console: Core Web Vitals Report
Il punto di partenza migliore è il report Core Web Vitals in Google Search Console. Mostra le performance del tuo sito basate su dati reali degli utenti Chrome negli ultimi 28 giorni, raggruppando le URL per stato (Poor, Need improvement, Good).
Il report separa i dati per desktop e mobile, permettendoti di identificare dove concentrare gli sforzi. Per superare la valutazione, il 75° percentile di tutte le visite deve raggiungere la soglia “Good” per tutte e tre le metriche.
PageSpeed Insights
PageSpeed Insights combina dati field (quando disponibili) e lab in un’unica interfaccia. Inserisci un URL e ottieni:
- Dati sul campo (CrUX): metriche reali degli ultimi 28 giorni, quando il sito ha traffico sufficiente
- Dati di laboratorio (Lighthouse): test sintetico con raccomandazioni dettagliate
- Diagnostica: suggerimenti specifici per migliorare ogni metrica
Nota importante: il punteggio Lighthouse (0-100) non influenza direttamente il ranking. Google utilizza solo i dati field per la valutazione SEO. Un punteggio Lighthouse basso non significa necessariamente che i dati reali siano scarsi, e viceversa.
Chrome DevTools
Per diagnosi approfondite, Chrome DevTools offre il Performance panel che permette di registrare e analizzare il caricamento pagina, identificare long tasks che bloccano il main thread, e visualizzare nel dettaglio cosa causa ritardi in LCP e INP.
Premi F12, vai su Performance, registra un caricamento pagina e analizza il waterfall per identificare bottleneck specifici.
Altri strumenti utili
- WebPageTest: analisi dettagliata del caricamento con waterfall, test da location diverse e condizioni di rete variabili
- DebugBear: monitoraggio continuo con alert su regressioni
- Lighthouse CI: integrazione in pipeline CI/CD per verificare le metriche ad ogni deploy
Come migliorare il Largest Contentful Paint (LCP)
LCP è spesso determinato da immagini hero, video in background o blocchi di testo prominenti. Per ottimizzarlo, devi assicurarti che questo elemento critico carichi il più velocemente possibile.
1. Ottimizza le immagini (miglioramento atteso: 500-800ms)
Le immagini sono la causa più comune di LCP lento. Intervieni su più fronti:
- Formati moderni: usa WebP o AVIF invece di JPEG/PNG. WebP offre compressione 25-35% migliore
- Compressione: comprimi le immagini con TinyPNG, ShortPixel o Imagify mantenendo qualità accettabile
- Dimensioni responsive: usa srcset per servire immagini appropriate alla dimensione dello schermo
- Lazy loading intelligente: carica in lazy SOLO le immagini below-the-fold. L’immagine LCP deve caricare immediatamente
2. Precarica le risorse critiche (miglioramento: 300-500ms)
Usa il tag preload per dire al browser di prioritizzare le risorse critiche prima che il parser HTML le scopra:
<link rel="preload" href="hero-image.webp" as="image" fetchpriority="high">
<link rel="preload" href="critical-font.woff2" as="font" type="font/woff2" crossorigin>L’attributo fetchpriority="high" è particolarmente efficace per l’elemento LCP, indicando al browser di prioritizzarlo rispetto ad altre risorse.
3. Elimina risorse che bloccano il rendering (miglioramento: 400-600ms)
CSS e JavaScript sincronizzati nel <head> bloccano il rendering finché non sono completamente scaricati e processati:
- CSS critico inline: estrai il CSS necessario per il contenuto above-the-fold e inseriscilo direttamente nell’HTML
- Defer CSS non critico: carica il resto del CSS in modo asincrono
- Defer JavaScript: aggiungi
deferoasyncai tag script non critici - Rimuovi codice inutilizzato: Chrome DevTools Coverage può identificare CSS e JS non utilizzati
4. Migliora il Time to First Byte (miglioramento: 200-500ms)
Se il server risponde lentamente, tutto il resto è ritardato. Il TTFB ideale è sotto i 200ms. Per migliorarlo:
- Hosting performante: investi in hosting di qualità con server in Italia/Europa
- CDN: usa una Content Delivery Network come Cloudflare (piano free disponibile) per servire contenuti dal server più vicino all’utente
- Page caching: configura caching a livello server o usa plugin come WP Super Cache, W3 Total Cache o LiteSpeed Cache
- Database optimization: pulisci revisioni, transient e ottimizza le tabelle del database
5. Considera il Server-Side Rendering (SSR)
Per applicazioni JavaScript-heavy (React, Vue, Angular), il Server-Side Rendering può ridurre drasticamente LCP perché il contenuto HTML arriva già renderizzato dal server invece di essere costruito nel browser. Framework come Next.js (React) o Nuxt.js (Vue) facilitano questa implementazione.
Come migliorare Interaction to Next Paint (INP)
INP misura quanto velocemente il sito risponde alle interazioni utente. Il problema principale sono i “long tasks” che bloccano il main thread, impedendo al browser di rispondere ai click.
1. Spezza i long tasks (miglioramento: 150-300ms)
Un “long task” è qualsiasi operazione JavaScript che richiede più di 50ms. Durante l’esecuzione, il browser non può rispondere alle interazioni. Soluzione: spezza i task lunghi in chunk più piccoli usando setTimeout, requestIdleCallback o yielding al main thread.
// Invece di processare tutto in una volta
function processareTutto() {
// elaborazione lunga che blocca il main thread
}
// Spezza in chunk più piccoli
function processareInChunk(items, chunkSize = 50) {
let index = 0;
function processChunk() {
const chunk = items.slice(index, index + chunkSize);
// processa il chunk
index += chunkSize;
if (index < items.length) {
setTimeout(processChunk, 0); // yield al main thread
}
}
processChunk();
}2. Riduci JavaScript (miglioramento: 100-200ms)
- Rimuovi codice inutilizzato: analizza il bundle con strumenti come Webpack Bundle Analyzer
- Code splitting: carica solo il JavaScript necessario per la pagina corrente
- Defer script non critici: carica analytics, chat widget e tracking dopo il caricamento iniziale
- Valuta ogni script third-party: ogni tag manager, pixel e widget ha un costo. Elimina quelli non essenziali
3. Ottimizza gli event handler (miglioramento: 50-150ms)
- Debounce/throttle: per eventi frequenti come scroll e resize, limita la frequenza di esecuzione
- Passive event listeners: per eventi touch e wheel, usa
{ passive: true }per migliorare lo scrolling - Evita reflow forzati: leggere proprietà di layout (offsetHeight, getBoundingClientRect) dopo modifiche forza il browser a ricalcolare il layout
4. Riduci la dimensione del DOM
Un DOM troppo grande (oltre 1.500 nodi) rallenta rendering e interazioni. Semplifica la struttura HTML, evita nidificazioni eccessive e usa virtualizzazione per liste lunghe.
Come migliorare Cumulative Layout Shift (CLS)
CLS è generalmente la metrica più facile da ottimizzare perché le cause sono ben definite e le soluzioni dirette.
1. Specifica sempre dimensioni per immagini e video
Quando un’immagine carica senza dimensioni specificate, il browser non sa quanto spazio riservare. Quando l’immagine appare, il contenuto sottostante si sposta. Soluzione:
<!-- ❌ Causa layout shift -->
<img src="foto.jpg" alt="Descrizione">
<!-- ✅ Previene layout shift -->
<img src="foto.jpg" alt="Descrizione" width="800" height="600">
<!-- ✅ O con CSS aspect-ratio -->
<style>
.responsive-img {
width: 100%;
aspect-ratio: 4/3;
object-fit: cover;
}
</style>WordPress dalla versione 5.5 aggiunge automaticamente width e height alle immagini, ma verifica che non vengano sovrascritti dal tema o da CSS.
2. Riserva spazio per contenuti dinamici
Annunci, embed e contenuti che caricano dopo il rendering iniziale sono cause comuni di CLS. Riserva spazio con un contenitore di dimensioni fisse:
<!-- Contenitore per annuncio con dimensioni riservate -->
<div class="ad-container" style="min-height: 250px; min-width: 300px;">
<!-- L'annuncio caricherà qui senza causare shift -->
</div>3. Precarica i web font
I font che caricano dopo il rendering causano Flash of Unstyled Text (FOUT) o Flash of Invisible Text (FOIT), entrambi contribuiscono a CLS:
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>
<style>
@font-face {
font-family: 'MioFont';
src: url('font.woff2') format('woff2');
font-display: swap; /* Mostra subito il fallback, poi swap */
}
</style>4. Evita di inserire contenuto sopra contenuto esistente
Non inserire mai banner, alert o elementi dinamici sopra il contenuto che l’utente sta già visualizzando. Se necessario, usa animazioni che non modifichino il layout (transform invece di margin/padding) o inserisci il contenuto sotto lo scroll.
Core Web Vitals per WordPress: guida pratica
WordPress alimenta il 43% del web, ma solo il 46% dei siti WordPress mobile supera i Core Web Vitals. La buona notizia: le ottimizzazioni sono relativamente semplici con i plugin giusti.
Tema e page builder
Il tema ha un impatto enorme sulle performance. Temi leggeri come Astra, GeneratePress o Kadence sono ottimizzati per i Core Web Vitals. I page builder pesanti come Elementor, Divi o WPBakery generano molto codice aggiuntivo. Se usi un page builder, Gutenberg (l’editor nativo) è la scelta più performante.
Plugin di performance consigliati (gratuiti)
- LiteSpeed Cache: se il tuo hosting usa LiteSpeed, è la scelta migliore. Caching, ottimizzazione immagini, CSS/JS combine
- WP Super Cache o W3 Total Cache: caching page per hosting non-LiteSpeed
- Autoptimize: ottimizzazione e combine CSS/JS
- EWWW Image Optimizer o Smush: compressione immagini automatica
- Perfmatters (premium): disabilita script non necessari per pagina, lazy load avanzato
Configurazione base raccomandata
- Attiva page caching (qualsiasi plugin di cache)
- Abilita compressione GZIP/Brotli (solitamente a livello server/hosting)
- Ottimizza le immagini con lazy loading (escludi immagine hero)
- Minifica CSS e JavaScript
- Defer JavaScript non critico
- Genera CSS critico inline
- Usa un CDN (Cloudflare free è un ottimo punto di partenza)
Checklist ottimizzazione Core Web Vitals
Ecco una checklist completa di interventi, ordinata per priorità e impatto:
Quick wins (implementabili in 1 giorno)
- ☐ Attiva page caching
- ☐ Comprimi tutte le immagini esistenti
- ☐ Converti immagini in WebP
- ☐ Aggiungi width e height a tutte le immagini
- ☐ Attiva lazy loading (escludi immagine hero)
- ☐ Attiva CDN (Cloudflare free)
Ottimizzazioni intermedie (1 settimana)
- ☐ Preload dell’elemento LCP (immagine hero)
- ☐ Genera e inline CSS critico
- ☐ Defer JavaScript non critico
- ☐ Rimuovi plugin WordPress non utilizzati
- ☐ Preload web font
- ☐ Riserva spazio per annunci ed embed
- ☐ Ottimizza database WordPress
Ottimizzazioni avanzate (1 mese)
- ☐ Audit completo script third-party ed eliminazione non essenziali
- ☐ Implementa code splitting per JavaScript
- ☐ Valuta cambio tema se molto pesante
- ☐ Considera upgrade hosting se TTFB alto
- ☐ Implementa resource hints (preconnect, prefetch)
- ☐ Configura Service Worker per caching avanzato
Errori comuni da evitare
Nella mia esperienza con l’ottimizzazione di siti, questi sono gli errori più frequenti:
1. Lazy loading dell’immagine LCP
Se applichi lazy loading all’immagine hero (che spesso è l’elemento LCP), ritardi proprio l’elemento che dovrebbe caricare per primo. Escludi sempre l’immagine above-the-fold dal lazy loading.
2. Ossessione per il punteggio Lighthouse
Il punteggio Lighthouse non è usato per il ranking. Puoi avere 100/100 in Lighthouse ma dati field scarsi, o viceversa. Concentrati sui dati reali in Search Console.
3. Troppi plugin di ottimizzazione
Usare 5 plugin di cache e ottimizzazione contemporaneamente spesso crea conflitti e peggiora le performance. Scegli uno stack minimo e configuralo correttamente.
4. Ignorare il mobile
Google usa mobile-first indexing. Le performance mobile contano più di quelle desktop per il ranking. Testa sempre su dispositivi reali o con throttling appropriato.
5. Aspettarsi risultati immediati
I dati field in Search Console hanno una finestra di 28 giorni. Dopo un’ottimizzazione, servono 4-8 settimane per vedere l’impatto completo nei dati Google.
Domande frequenti sui Core Web Vitals
I Core Web Vitals influenzano davvero il ranking?
Sì, Google ha confermato che sono fattori di ranking. Tuttavia, non sono il fattore dominante. Contenuto di qualità, rilevanza e autorevolezza rimangono più importanti. I Core Web Vitals funzionano come “tiebreaker” quando altri fattori sono comparabili, e i dati mostrano che i siti in posizione 1 hanno maggiore probabilità di superarli rispetto a quelli in posizioni inferiori.
Quanto tempo serve per vedere miglioramenti nel ranking dopo l’ottimizzazione?
I dati Core Web Vitals in Search Console usano una finestra di 28 giorni, quindi i miglioramenti diventano visibili dopo 4-8 settimane. L’impatto sul ranking può richiedere 1-3 mesi, assumendo che altri fattori rimangano costanti.
Posso posizionarmi bene senza superare i Core Web Vitals?
Sì, molte pagine ben posizionate non superano le soglie. Contenuto eccellente può compensare performance mediocri. Tuttavia, stai rinunciando a un vantaggio competitivo. In nicchie competitive dove la qualità del contenuto è simile, i Core Web Vitals possono fare la differenza.
Devo ottimizzare prima per mobile o desktop?
Mobile first. Google usa mobile-first indexing, quindi le performance mobile sono più importanti per il ranking. Il 60%+ delle ricerche avviene da mobile. Ottimizza prima mobile, poi desktop.
Qual è la differenza tra dati lab e dati field?
I dati lab (Lighthouse) provengono da test sintetici in ambiente controllato, utili per diagnosticare problemi. I dati field (CrUX) provengono da utenti reali Chrome. Google usa SOLO i dati field per la valutazione ranking. Usa i dati lab per trovare le cause, ma giudica il successo dai dati field.
Core Web Vitals e il futuro: cosa aspettarsi
Le metriche Core Web Vitals evolvono nel tempo. INP ha sostituito FID nel 2024, e Google continua a raffinare le metodologie di misurazione. Nel 2025-2026, abbiamo visto:
- Firefox ha aggiunto supporto per LCP e INP, espandendo la raccolta dati oltre Chrome
- Safari sta implementando supporto per LCP e INP (disponibile in Safari Technology Preview)
- Il supporto per CLS è proposto per Interop 2026
- Le soglie rimangono stabili (LCP ≤2,5s, INP ≤200ms, CLS ≤0,1)
L’espansione del supporto cross-browser significa dati più rappresentativi dell’esperienza reale degli utenti. Per i proprietari di siti, la strategia rimane la stessa: costruire esperienze veloci, reattive e stabili.
I Core Web Vitals come vantaggio competitivo
Con solo il 48% dei siti che supera la valutazione Core Web Vitals nel 2026, ottimizzare le performance rappresenta un’opportunità concreta di differenziazione. Non si tratta solo di SEO: siti più veloci convertono meglio, riducono il bounce rate e migliorano la soddisfazione degli utenti.
L’approccio migliore è sistematico: inizia misurando con Search Console e PageSpeed Insights, identifica la metrica peggiore, applica le ottimizzazioni appropriate partendo dai quick wins, e monitora i progressi nel tempo.
Ricorda: i Core Web Vitals non sono l’unico fattore di ranking, ma sono tra i pochi completamente sotto il tuo controllo e con impatto misurabile sia sul posizionamento che sui risultati di business. In un panorama dove i contenuti di qualità sono sempre più comuni, l’eccellenza tecnica diventa il differenziatore che separa i leader dai follower.
