Nel 2026, chiunque gestisca un sito web non può più permettersi di trattare le performance come un tema secondario. Con il Google Core Update di marzo 2026, l’algoritmo ha consolidato ulteriormente il ruolo dei Core Web Vitals nel calcolo del ranking, introducendo una novità che cambia le regole del gioco: lo scoring olistico a livello di dominio. Ottimizzare solo le pagine principali non è più sufficiente.
In questa guida andiamo ad approfondire l’argomento e scopriamo cosa misurano esattamente LCP, INP e CLS, quali soglie occorre rispettare, come leggere i dati in modo corretto e, soprattutto, come intervenire in modo efficace senza inseguire punteggi di laboratorio che poco hanno a che fare con l’esperienza reale degli utenti.
Cosa sono i Core Web Vitals?
I Core Web Vitals sono un sottoinsieme delle metriche Page Experience definite da Google. La loro specificità, e il motivo per cui risultano essere più rilevanti di molti altri indicatori, è che non misurano condizioni simulate in laboratorio, ma l’esperienza effettiva degli utenti reali che navigano un sito attraverso il browser Chrome.
Google raccoglie questi dati tramite il Chrome User Experience Report (CrUX), un dataset aggregato e anonimizzato che alimenta strumenti come Google Search Console e PageSpeed Insights. La metrica di riferimento è il 75° percentile: un sito supera la soglia “Good” solo se almeno il 75% delle sessioni reali produce un valore rientrante nei parametri corretti. Non basta che la pagina sia veloce su una connessione in fibra ottica.
Dal maggio 2021 i Core Web Vitals sono fattori di ranking ufficiali e dal 12 marzo 2024, INP ha sostituito FID come metrica di reattività. Chi ha ottimizzato FID in passato non può considerare il lavoro concluso: le due metriche misurano fenomeni diversi e richiedono interventi tecnici distinti.
Le tre metriche: LCP, INP e CLS
| Metrica | Cosa misura | Buono | Da migliorare | Scarso |
|---|---|---|---|---|
| LCP | Velocità di caricamento | < 2,5 s | 2,5 – 4 s | > 4 s |
| INP | Reattività alle interazioni | < 200 ms | 200 – 500 ms | > 500 ms |
| CLS | Stabilità visiva del layout | < 0,1 | 0,1 – 0,25 | > 0,25 |
LCP – Largest Contentful Paint
L’indicatore LCP misura il tempo necessario affinché l’elemento di contenuto più grande visibile nella viewport iniziale venga renderizzato a schermo: quasi sempre l’immagine hero, il titolo principale above the fold o un blocco video. La percezione di “velocità” da parte dell’utente è legata proprio a questo momento: non a quando il browser ha finito di caricare tutto, ma a quando il contenuto più rilevante diventa visibile.
Le cause più frequenti di LCP deficitario si sommano raramente a una sola: TTFB elevato (server lento o assenza di caching), risorse che bloccano il rendering (CSS o JS non critici caricati in modo sincrono) e asset principale non ottimizzato nel formato o nel preload. Un errore tecnico particolarmente diffuso è applicare il lazy loading proprio all’immagine LCP: quell’immagine va caricata con la massima priorità, non differita.
INP – Interaction to Next Paint
INP è la metrica più complessa da ottimizzare perché non si risolve comprimendo immagini o cambiando hosting, ma misura la latenza di tutte le interazioni utente: click, tap, input da tastiera, durante l’intera sessione di navigazione, restituendo come punteggio il valore più alto registrato.
Il predecessore FID si limitava al ritardo della prima interazione, quindi un sito poteva avere un FID eccellente e un INP pessimo, perché la reattività degradava nel corso della navigazione sotto l’effetto di JavaScript in background o script di terze parti accumulati.
Le cause principali di INP elevato sono: task JavaScript lunghi (oltre 50ms) che bloccano il main thread, listener di eventi non ottimizzati, librerie di terze parti come chat widget, pixel pubblicitari e tool di A/B testing. Su dispositivi mobile di fascia media, la maggioranza del traffico italiano, un INP superiore a 300ms produce un calo misurabile dell’engagement.
CLS – Cumulative Layout Shift
CLS misura la stabilità visiva della pagina: quanto il contenuto si sposta in modo imprevisto durante il caricamento, un banner pubblicitario che appare e fa saltare il testo, un font che sostituisce il fallback di sistema spostando i paragrafi, un iframe senza dimensioni dichiarate: tutti questi fenomeni contribuiscono al punteggio.
La caratteristica che rende CLS particolarmente critico con il nuovo scoring olistico del 2026 è che i problemi di layout shift sono quasi sempre legati ai template, non alle singole pagine.
Se un tema WordPress genera immagini senza attributi width e height, o se gli annunci vengono iniettati dinamicamente senza spazio riservato, quel problema si replica su migliaia di URL simultaneamente.
La novità del 2026: scoring olistico a livello di dominio
Fino al Core Update di marzo 2026, Google valutava i Core Web Vitals su base URL. Superare le soglie sulle top landing page era sufficiente per ottenere il beneficio nel ranking. Questa strategia ossia di ottimizzare le pagine più trafficate ignorando il resto non funziona più.
Google aggrega ora le performance dell’intero dominio, producendo uno score ponderato a livello di sito. Le pagine ad alto traffico pesano di più, ma le URL con performance scadenti contribuiscono negativamente all’aggregato. Se il 30% delle pagine indicizzate presenta un LCP scarso, il sito subisce un impatto anche se homepage e category page sono ottimizzate.
Le implicazioni sono concrete ad esempio archivi di articoli datati, pagine di tag, URL generate da filtri e-commerce, landing page stagionali dimenticate: tutte entrano nel calcolo. La strategia corretta è lavorare per template, correggere il template che genera il maggior numero di URL con performance insufficienti significa risolvere centinaia di problemi con un singolo intervento.
Come misurare i Core Web Vitals
Prima di ottimizzare, bisogna misurare correttamente e per farlo è necessario comprendere la distinzione tra dati di campo e dati di laboratorio.
I dati di laboratorio (Lighthouse, simulazioni PageSpeed) riproducono un caricamento in condizioni controllate. Sono utili per la diagnostica ma non riflettono l’esperienza reale. I dati di campo provengono dal CrUX: sessioni reali, con device reali, connessioni reali.
Sono questi i dati che Google usa per il ranking. Quando un sito mostra un PageSpeed Insights eccellente ma fatica nelle SERP, la spiegazione è quasi sempre nei dati di campo.
Gli strumenti da utilizzare
Gli strumenti da usare per misurare correttamente i Core Web Vitals sono quattro: Google Search Console (sezione Esperienza > Segnali web essenziali) per avere una visione aggregata per template e dispositivo; PageSpeed Insights per combinare dati CrUX e dati di laboratorio su una singola URL; Chrome DevTools con il pannello Performance per la diagnostica avanzata e la profilazione del main thread; Web Vitals Extension per misurare LCP, INP e CLS in tempo reale durante la navigazione.
Una regola pratica: usa Google Search Console per identificare i template con problemi diffusi, PageSpeed Insights per diagnosticare le cause su una singola URL, Chrome DevTools per l’analisi tecnica profonda. Non inseguire il punteggio di laboratorio: ciò che conta sono i dati di campo al 75° percentile.
Come ottimizzare il INP
L’Interaction to Next Paint misura quanto velocemente il browser risponde a un’azione dell’utente. I problemi nascono quasi sempre sul main thread: se è occupato, l’interfaccia non reagisce. Le due aree principali su cui intervenire sono i task JavaScript pesanti e gli script di terze parti.
Long task e main thread
Ogni task JavaScript che blocca il main thread per più di 50ms ritarda la risposta del browser alle interazioni. Lo strumento di diagnosi è Chrome DevTools → Performance, che identifica i long task con la loro durata. La soluzione è suddividere i blocchi pesanti usando setTimeout, requestIdleCallback o, per i casi più avanzati, lo scheduler.postTask API. Le operazioni computazionalmente intensive andrebbero spostate su Web Worker, che girano in thread separati senza bloccare l’interfaccia.
Script di terze parti: il nemico nascosto
Chat widget, pixel pubblicitari, tag manager con decine di script, A/B test, gestori del consenso: ciascuno compete per il main thread. Un audit trimestrale degli script di terze parti è una pratica irrinunciabile. La domanda da porsi per ogni script è semplice: genera valore misurabile superiore al costo in millisecondi? Se la risposta non è un sì convinto, lo script va rimosso o posticipato con il pattern facade e caricare un’anteprima statica e lo script reale solo su interazione esplicita dell’utente.
Come ottimizzare il CLS
Il Cumulative Layout Shift misura quanto il contenuto si sposta inaspettatamente durante il caricamento della pagina. I colpevoli più comuni sono risorse senza dimensioni dichiarate e contenuti che appaiono in ritardo, dopo che il layout è già stato calcolato.
Dimensioni esplicite su immagini e video
La causa più frequente di CLS è un’immagine o un video senza attributi width e height dichiarati nell’HTML. Il browser non conosce le dimensioni prima di aver scaricato la risorsa, non riserva lo spazio e sposta il contenuto circostante all’arrivo. La soluzione è dichiarare sempre le dimensioni e usare la proprietà CSS aspect-ratio come ulteriore salvaguardia.
Web font e contenuti dinamici
Il caricamento dei web font provoca FOUT (Flash of Unstyled Text): il browser mostra prima il font di sistema, poi lo sostituisce con quello custom, spostando il layout. La soluzione è font-display: optional (nessun fallback visibile) oppure font-display: swap abbinato al preload del font critico. Per contenuti dinamici — banner cookie, notifiche, annunci — la regola è sempre riservare lo spazio prima dell’injection, mai inserirli sopra contenuti esistenti a meno che non sia in risposta a un’azione esplicita dell’utente.
| Intervento | Metrica | Difficoltà | Impatto |
|---|---|---|---|
| Ottimizzazione immagini (WebP/AVIF, srcset, compressione) | LCP, CLS | Bassa | Alto |
| CDN e caching server-side (riduzione TTFB) | LCP | Media | Alto |
Preload risorse critiche (link rel=preload) |
LCP | Bassa | Alto |
Dimensioni esplicite su img e iframe |
CLS | Bassa | Alto |
| Eliminare render-blocking CSS/JS | LCP | Media | Alto |
| Suddivisione long task JavaScript | INP | Alta | Alto |
| Riduzione script di terze parti | LCP, INP | Media | Medio |
Web font: preload + font-display |
CLS | Bassa | Medio |
Gli errori più frequenti
Dall’analisi di decine di progetti, questi sono i pattern sbagliati che ricorrono sistematicamente e sui quali bisogna lavorare per riuscire a migliorare i propri Core Web Vitals.
Errore 1 – Lazy loading sull’immagine LCP. L’elemento che deve caricare prima viene deliberatamente posticipato. È controintuitivo ma devastante per il punteggio.
Errore 2 – Controllare solo i dati di laboratorio. Il punteggio di PageSpeed è utile per la diagnostica, non per valutare lo stato reale del sito. I dati CrUX in Search Console sono l’unica fonte rilevante per il ranking.
Errore 3 – Ottimizzare solo le top landing page. Con lo scoring olistico del 2026, le URL dimenticate penalizzano l’intero dominio. I problemi si risolvono per template, non pagina per pagina.
Errore 4 – Ritenere che un buon FID equivalga a un buon INP. Sono metriche diverse che misurano fenomeni diversi e richiedono interventi diversi.
Errore 5 – Non monitorare nel tempo. I Core Web Vitals si degradano con ogni aggiornamento di plugin, tema o script di terze parti. Senza monitoraggio continuativo, le ottimizzazioni fatte oggi si perdono nel giro di mesi.
Core Web Vitals e business: il legame con le conversioni
I Core Web Vitals non sono una questione tecnica isolata: hanno un impatto diretto e misurabile sulle conversioni. Un ritardo di un secondo nel tempo di caricamento può ridurre le conversioni del 7%. Il 53% degli utenti mobile abbandona un sito che impiega più di tre secondi a caricarsi.
Per un e-commerce, ogni riduzione della latenza si traduce in un incremento delle transazioni. Per un sito di lead generation, una pagina lenta riduce il numero di form compilati. Per un sito editoriale, un CLS alto aumenta i clic accidentali e abbassa il tempo di permanenza. Ottimizzare i Core Web Vitals non è solo rispettare un parametro Google: è costruire un’esperienza che converte.
I Core Web Vitals agiscono come tiebreaker tra pagine con contenuto comparabile. Non sostituiranno mai qualità editoriale e autorevolezza del dominio, ma in mercati competitivi, dove chi cerca trova sempre diverse buone risposte, la performance tecnica fa la differenza tra la posizione 3 e la posizione 8.
Come si ottimizzano i Core Web Vitals su WordPress?
Le priorità sono: hosting performante con PHP 8.x e HTTP/3, tema leggero (Astra, GeneratePress, Kadence), plugin di caching affidabile (WP Rocket, LiteSpeed Cache), ottimizzazione immagini con conversione WebP automatica (ShortPixel, Imagify) e riduzione al minimo dei plugin attivi. Un plugin di terze parti mal ottimizzato può vanificare qualsiasi altra ottimizzazione.
Nel 2026 i Core Web Vitals non sono più uno dei tanti punti di una checklist SEO tecnica: sono un elemento strutturale della strategia di visibilità organica. Con l’introduzione dello scoring olistico di dominio, la soglia di attenzione si è alzata: non basta che le pagine principali siano veloci, deve esserlo l’intero sito.
L’approccio più efficace parte dai dati di campo in Google Search Console, identifica i template con le maggiori criticità, interviene per priorità di impatto e monitora continuamente per prevenire regressioni. Le performance non sono uno stato finale, ma un processo continuo — esattamente come la SEO nel suo complesso.
Domande frequenti
Quanto tempo ci vuole per vedere miglioramenti nel ranking dopo l’ottimizzazione?
Google Search Console aggiorna i dati CWV su base 28 giorni. Un miglioramento delle metriche è visibile entro 4-6 settimane dall’intervento. I riflessi sul posizionamento richiedono in genere 2-3 mesi di punteggi stabili, poiché l’algoritmo considera molti fattori in parallelo.
I Core Web Vitals contano di più su mobile o su desktop?
Google adotta il Mobile-First Indexing: le metriche mobile hanno priorità nell’indicizzazione e nel ranking. I dati desktop rimangono rilevanti per le SERP da computer. La pratica corretta è ottimizzare entrambe le versioni, partendo dal mobile.
È possibile superare i Core Web Vitals con un hosting lento?
No, o quasi. Un TTFB superiore a 600ms rende estremamente difficile centrare la soglia LCP. L’hosting è la fondamenta: nessuna ottimizzazione front-end può compensare un server lento in modo strutturale. Hosting condiviso ed economico è spesso la causa principale di LCP scarso.
Correggere i Core Web Vitals garantisce un miglioramento del ranking?
Non da soli. I Core Web Vitals sono un fattore di ranking, non il fattore di ranking. Contenuti di bassa qualità, assenza di backlink autorevoli o carenze di E-E-A-T non si compensano con metriche di performance eccellenti. Il loro valore emerge soprattutto in contesti competitivi, dove la qualità dei contenuti è comparabile tra i competitor.