Dal 2021, Google usa i Core Web Vitals come fattore di ranking diretto.
Non è una novità — ma le soglie sono cambiate, le metriche si sono evolute, e nel 2026 la differenza tra un sito che passa i Core Web Vitals e uno che non li passa si riflette in modo sempre più misurabile sul posizionamento nelle ricerche competitive.
Questa guida è tecnica. Spiega cos'è ciascuna metrica, come si misura correttamente, e cosa si fa concretamente per migliorarla. Senza consigli generici come "comprimi le immagini" o "usa un CDN" — con le cause reali e le soluzioni reali.
Le tre metriche dei Core Web Vitals nel 2026
Google misura l'esperienza utente attraverso tre metriche principali che compongono i Core Web Vitals. Dalla fine del 2024, INP ha sostituito FID come metrica ufficiale. Ecco cosa misura ciascuna.
LCP — Largest Contentful Paint
LCP misura il tempo che impiega l'elemento di contenuto più grande visibile nell'area iniziale della pagina a caricarsi completamente. L'elemento LCP è tipicamente un'immagine hero, un video, o un blocco di testo grande.
La soglia di Google: sotto 2,5 secondi è "buono", tra 2,5 e 4 secondi è "da migliorare", sopra 4 secondi è "scarso".
LCP è la metrica più impattante per il ranking perché misura direttamente la percezione di velocità dell'utente — quanto tempo passa tra il clic sul link e il momento in cui vede il contenuto principale della pagina.
CLS — Cumulative Layout Shift
CLS misura la stabilità visiva della pagina durante il caricamento. Ogni volta che un elemento si sposta dopo essere comparso — un'immagine che "spinge" il testo verso il basso, un banner che appare e riorganizza il layout, un font che cambia dimensione durante il rendering — si genera un layout shift con un punteggio di spostamento.
La soglia di Google: sotto 0,1 è "buono", tra 0,1 e 0,25 è "da migliorare", sopra 0,25 è "scarso".
CLS colpisce particolarmente gli utenti mobile — dove gli elementi tendono a spostarsi di più durante il caricamento — e i siti con pubblicità o contenuti caricati dinamicamente.
INP — Interaction to Next Paint
INP è la metrica più recente, che ha sostituito FID a marzo 2024. Misura la reattività della pagina alle interazioni dell'utente: clic, tap, pressioni di tasti. Più precisamente, misura il tempo tra l'interazione dell'utente e il momento in cui il browser aggiorna visivamente la pagina in risposta.
La soglia di Google: sotto 200ms è "buono", tra 200 e 500ms è "da migliorare", sopra 500ms è "scarso".
INP è più difficile da ottimizzare di FID perché misura tutte le interazioni durante la vita della pagina, non solo la prima. Un sito che risponde bene al primo clic ma rallenta dopo che l'utente ha interagito più volte — scenario comune su pagine con JavaScript pesante — viene penalizzato da INP ma non sarebbe stato penalizzato da FID.
Come misurare i Core Web Vitals correttamente
C'è una distinzione fondamentale che molti ignorano: i dati di laboratorio e i dati sul campo sono due cose diverse, e Google usa i dati sul campo per il ranking.
Dati di laboratorio vs dati sul campo
PageSpeed Insights mostra entrambi. I dati di laboratorio — la sezione "Diagnostica" — simulano le condizioni di un utente su connessione mobile 4G con dispositivo di fascia media. Sono riproducibili e utili per il debugging, ma non sono quelli che Google usa per il ranking.
I dati sul campo — la sezione "Dati del campo" — vengono dal Chrome User Experience Report (CrUX): misurazioni reali aggregate dagli utenti Chrome che visitano il tuo sito. Questi sono i dati che Google usa per valutare i Core Web Vitals ai fini del ranking. Se il tuo sito ha poco traffico, il CrUX potrebbe non avere dati sufficienti e la sezione "Dati del campo" apparirà vuota.
Gli strumenti giusti
PageSpeed Insights è il punto di partenza — gratuito, diretto, mostra entrambi i tipi di dato. Ma ha un limite: analizza una pagina alla volta.
Google Search Console ha una sezione "Esperienza" → "Core Web Vitals" che mostra il rendimento aggregato di tutte le pagine del sito, divise per URL con problemi. Questo è lo strumento giusto per capire lo stato complessivo del sito e identificare quali gruppi di pagine hanno problemi.
Per un'analisi più approfondita: WebPageTest permette test con condizioni personalizzabili e waterfall dettagliato del caricamento. Lighthouse (integrato in Chrome DevTools) è utile per il debugging locale.
Le cause reali di LCP scarso e come risolverle
Un LCP sopra 2,5 secondi ha quasi sempre una di queste cause. Vediamole in ordine di frequenza.
Server lento — TTFB alto
Il Time to First Byte è il tempo che il browser aspetta prima di ricevere il primo byte di risposta dal server. Se il TTFB supera 600ms, stai partendo già in svantaggio: il browser non può nemmeno iniziare a caricare le risorse della pagina finché non riceve la risposta iniziale.
Le cause di TTFB alto: hosting condiviso con risorse insufficienti, database non ottimizzato con query lente, mancanza di caching server-side, CMS che genera ogni pagina dinamicamente senza cache. Su WordPress con molti plugin, ogni richiesta può generare decine di query al database — il TTFB raramente scende sotto 800ms senza un sistema di caching aggressivo.
La soluzione strutturale è un hosting con PHP-FPM ottimizzato, OPcache attivo, e caching server-side configurato correttamente. La soluzione definitiva è un CMS con architettura ottimizzata per la velocità — dove il TTFB sotto 200ms non dipende dalla configurazione dell'hosting ma dall'architettura stessa dell'applicazione. Puoi vedere i benchmark di performance di KeideaCMS qui.
Immagine LCP non precaricata
Il browser scopre l'immagine LCP solo dopo aver analizzato l'HTML e il CSS della pagina. Se l'immagine hero è in un elemento CSS background-image, o se è caricata con lazy loading, il browser la scopre tardi e il LCP peggiora.
La soluzione: aggiungere un tag <link rel="preload"> nell'head della pagina per l'immagine LCP. Questo dice al browser di iniziare a scaricare l'immagine immediatamente, prima ancora di aver processato tutto il CSS.
```html ```
Attenzione: il preload deve essere usato solo per l'immagine LCP, non per tutte le immagini. Precaricare troppe risorse peggiora le performance invece di migliorarle.
Immagini non ottimizzate
Un'immagine da 2MB in formato JPEG è la causa più comune di LCP scarso su siti che non hanno mai fatto ottimizzazione. La soluzione ha tre componenti: formato (WebP o AVIF invece di JPEG/PNG), dimensioni (servire l'immagine alla dimensione in cui viene visualizzata, non più grande), e compressione (qualità 75-85 per WebP è sufficiente per la maggior parte dei casi d'uso).
L'attributo srcset permette di servire immagini diverse per schermi di dimensioni diverse — fondamentale per mobile dove le immagini desktop sono enormemente sovradimensionate.
Render-blocking resources
CSS e JavaScript caricati nell'head della pagina bloccano il rendering — il browser non può mostrare nulla finché non ha scaricato e processato queste risorse. Un sito con molti plugin CSS e JS nell'head può bloccare il rendering per 1-2 secondi prima che l'utente veda qualsiasi contenuto.
La soluzione: caricare il CSS critico inline nell'head e rimandare il resto, usare defer o async per i JavaScript non critici, eliminare risorse non utilizzate. Su WordPress con molti plugin, questo richiede intervento manuale o plugin di ottimizzazione — che a loro volta aggiungono complessità e potenziali conflitti.
Le cause reali di CLS scarso e come risolverle
Immagini senza dimensioni definite
Quando il browser carica una pagina, riserva spazio per gli elementi in base alle dimensioni dichiarate nell'HTML. Se un'immagine non ha gli attributi width e height definiti, il browser non sa quanto spazio riservare e quando l'immagine si carica il layout si sposta.
La soluzione è semplice: aggiungere sempre width e height a ogni tag immagine. Non servono in pixel esatti — servono per definire il rapporto d'aspetto che il browser usa per riservare lo spazio corretto.
Font web con FOUT o FOIT
Quando il browser deve scaricare un font esterno, mostra prima il testo con un font di sistema (FOUT — Flash of Unstyled Text) o lo nasconde finché il font non è pronto (FOIT — Flash of Invisible Text). Quando il font web arriva, se le metriche sono diverse dal font di sistema, il layout si sposta.
La soluzione: usare font-display: optional per font non critici (il browser usa il font di sistema se il font web non è pronto in tempo), o preloadare il font web critico per minimizzare il tempo di attesa. La proprietà CSS size-adjust permette di calibrare le metriche del font di fallback per minimizzare il layout shift quando il font web arriva.
Contenuto iniettato dinamicamente
Banner cookie, chat widget, elementi pubblicitari, popup — qualsiasi elemento che viene inserito nel DOM dopo il caricamento iniziale della pagina può causare layout shift se sposta elementi già visibili. La soluzione è riservare spazio fisso per questi elementi nel layout, oppure inserirli in posizioni che non spostano il contenuto esistente (overlay in posizione fissa, elementi in coda alla pagina).
Le cause reali di INP scarso e come risolverle
INP dipende quasi sempre da JavaScript. Quando l'utente interagisce con la pagina, il browser deve eseguire tutto il codice JavaScript associato a quell'interazione prima di poter aggiornare la visualizzazione. Se il JavaScript è pesante o mal strutturato, l'aggiornamento visivo ritarda.
Long tasks nel thread principale
Il thread principale del browser fa tutto: esegue JavaScript, calcola lo stile CSS, aggiorna il layout, dipinge i pixel. Se un task JavaScript occupa il thread principale per più di 50ms, si genera un "long task" che ritarda tutte le interazioni utente.
La soluzione è spezzare i long tasks in chunk più piccoli usando scheduler.postTask() o setTimeout() strategici, oppure spostare il lavoro pesante nei Web Workers che operano su thread separati.
Dipendenze JavaScript eccessive
Un sito che carica 500KB di JavaScript — scenario comune su WordPress con molti plugin — ha un budget di esecuzione limitato. Su dispositivi mobile di fascia media, il parsing e la compilazione di JavaScript richiedono molto più tempo che su un MacBook Pro. INP su mobile peggiora proporzionalmente alla quantità di JavaScript caricata.
La soluzione è ridurre il JavaScript totale eliminando le dipendenze non necessarie, usando code splitting per caricare solo il codice necessario per la pagina corrente, e preferendo soluzioni native del browser a librerie JavaScript pesanti.
Core Web Vitals e CMS: perché l'architettura conta più dell'ottimizzazione
C'è un pattern che emerge lavorando sui Core Web Vitals di siti WordPress: si ottimizza, si migliora, si raggiunge il verde su PageSpeed — e poi si installa un nuovo plugin o si aggiorna il tema e si torna al punto di partenza.
La ragione è che su WordPress l'ottimizzazione delle performance è un lavoro continuo su un sistema che tende strutturalmente verso la lentezza. Ogni plugin aggiunge CSS, JavaScript, query al database. Ogni tema ha il suo overhead. L'ottimizzazione compensa questa tendenza ma non la elimina.
Un CMS progettato con la velocità come requisito architetturale — non come ottimizzazione aggiunta — parte da una baseline diversa. TTFB sotto 200ms, zero JavaScript non necessario, immagini servite in formato moderno con dimensioni corrette, nessun render-blocking resource nell'head: queste non sono ottimizzazioni applicate sopra il sistema, sono caratteristiche del sistema stesso.
Il risultato pratico è che i Core Web Vitals rimangono nel verde anche quando aggiungi contenuti, anche quando il catalogo cresce, anche senza interventi periodici di ottimizzazione. Se stai valutando una migrazione da WordPress proprio per questo motivo, abbiamo scritto una guida tecnica completa sulla migrazione senza perdere il posizionamento SEO.
Se vuoi verificare lo stato dei Core Web Vitals del tuo sito attuale e capire cosa impatta di più sul tuo ranking, puoi richiedere un audit gratuito.
