I Core Web Vitals sono tre metriche con cui Google misura la qualità dell'esperienza utente di ogni pagina web: LCP (Largest Contentful Paint) valuta la velocità di caricamento, INP (Interaction to Next Paint) misura la reattività ai clic, e CLS (Cumulative Layout Shift) quantifica la stabilità visiva. Per passare la soglia "Good" servono rispettivamente ≤2,5 s, ≤200 ms e ≤0,1. Questi valori non sono arbitrari: Google li ha derivati da ricerche su migliaia di siti reali, correlando le metriche con tassi di abbandono e conversione.
LCP: il contenuto principale deve caricare in meno di 2,5 secondi
LCP misura il tempo che impiega l'elemento più grande visibile nella viewport — di solito un'immagine hero o un titolo H1 — a diventare visibile. Un LCP sopra i 4 secondi è considerato "Poor" da Google. Quando realizziamo siti web prelodiamo l'immagine hero con `<link rel="preload">`, la serviamo in formato AVIF o WebP, e usiamo una CDN come Vercel Edge Network per ridurre la latenza geografica.
Nei progetti che seguiamo a Milano, il LCP è quasi sempre il primo problema da risolvere. Le cause più frequenti sono tre: immagini hero in formato JPEG da 2-4 MB senza compressione, assenza di preload esplicito sull'elemento LCP, e server con TTFB superiore a 600ms che introduce un ritardo fisso prima ancora di iniziare a scaricare qualsiasi risorsa. Risolvere questi tre punti porta quasi sempre il LCP sotto 2,5 secondi.
Un dato che sorprende spesso i clienti: secondo le analisi del CrUX dataset italiano, il 54% delle pagine web italiane ha un LCP classificato "Needs Improvement" o "Poor" su mobile. Questo significa che più della metà dei siti nel nostro paese sta perdendo potenziale di ranking per un problema tecnico risolvibile in pochi giorni di lavoro.
INP: la nuova metrica che ha sostituito FID nel 2024
INP misura il ritardo tra qualsiasi interazione utente (clic, tap, pressione tasto) e il momento in cui il browser aggiorna la pagina. A differenza del vecchio FID che misurava solo il primo clic, INP considera tutto il ciclo di vita della pagina. La soglia "Good" è ≤200 ms. Bloccare il thread principale con JavaScript pesante è il nemico numero uno dell'INP.
Da marzo 2024, INP ha ufficialmente sostituito FID come metrica Core Web Vitals. Il cambiamento è significativo: FID era relativamente facile da soddisfare anche con siti non ottimizzati, perché misurava solo il primo click. INP invece prende il percentile 98 di tutte le interazioni durante l'intera visita: una singola interazione lenta — ad esempio l'apertura di un menu dopo 5 secondi di navigazione — può abbattere l'intero punteggio.
Nella nostra esperienza a Milano, i siti React e Vue con molti componenti non ottimizzati sono i più colpiti da un INP alto. Componenti che rieseguono render su ogni keydown in un campo di ricerca, eventi di scroll con handler sincroni pesanti, e librerie di animazione che bloccano il thread principale sono le cause più comuni che identifichiamo negli audit. La soluzione quasi sempre passa per `React.memo`, `startTransition`, e lo spostamento dei calcoli pesanti in Web Workers.
CLS: le sezioni non devono saltare durante il caricamento
Il CLS misura quanto i contenuti si spostano visivamente durante il caricamento. Un valore sopra 0,25 è "Poor". Le cause più comuni sono immagini senza dimensioni esplicite, font web che si sostituiscono al fallback, e banner cookie che compaiono sopra il contenuto. Specificare sempre `width` e `height` sugli `<img>` e usare `font-display: optional` riduce drasticamente il CLS.
Il CLS è la metrica più "invisibile" delle tre: l'utente spesso non nota consciente lo spostamento dei contenuti, ma lo percepisce come un'esperienza frustrante e poco professionale. I dati di Google mostrano che le pagine con CLS alto hanno tassi di abbandono significativamente superiori. I banner GDPR che compaiono dopo il caricamento sono la causa più diffusa di CLS elevato nei siti italiani, dove la normativa europea impone il consenso esplicito.
La soluzione per i banner cookie è riservare lo spazio in anticipo tramite un elemento placeholder con altezza fissa, oppure mostrare il banner sopra il contenuto con `position: fixed` (che non causa CLS perché non sposta il layout). Per gli iframes dinamici (annunci AdSense, embed video) specificare sempre `width` e `height` sugli attributi, non solo via CSS, permette al browser di calcolare l'aspect ratio prima ancora di scaricare il contenuto.
Come Google usa i Core Web Vitals nel ranking
Dal 2021 i Core Web Vitals sono un segnale di ranking confermato da Google. Non è il segnale più forte (la rilevanza del contenuto rimane dominante), ma a parità di qualità dei contenuti un sito con metriche "Good" ha un vantaggio su un sito con metriche "Poor". Per le SERP mobile l'impatto è ancora più significativo, dato che oltre il 60% delle ricerche avviene da smartphone.
Google ha confermato che i Core Web Vitals influenzano sia il ranking organico che il Quality Score nelle campagne Google Ads: una landing page lenta paga di più per ogni clic e raggiunge meno utenti. Nei progetti di agenzia di web marketing che gestiamo, ottimizzare le performance della landing page è sempre tra le prime azioni prima di attivare campagne a pagamento — il ROI dell'ottimizzazione tecnica supera spesso quello dell'aumento del budget pubblicitario.
Strumenti per misurare i Core Web Vitals
- Google Search Console → sezione "Esperienza pagina": dati reali aggregati su 28 giorni (CrUX dataset), suddivisi per mobile e desktop
- PageSpeed Insights: combina dati di campo (CrUX) e dati di laboratorio (Lighthouse) in un unico report per URL
- Lighthouse in Chrome DevTools: utile in sviluppo per test sintetici, simula dispositivo Moto G4 su 3G lento
- Web Vitals Extension (Chrome): mostra LCP, INP e CLS in tempo reale mentre navighi, con breakdown delle fasi
- GTmetrix: ottimo per analisi approfondita waterfall e comparazioni nel tempo con grafici di tendenza
- WebPageTest: test da location specifica (inclusa Italia), filmstrip video del caricamento, test A/B
- Vercel Analytics: Web Vitals per deployment in produzione, segmentati per pagina e dispositivo
Dati di campo vs dati di laboratorio
Lighthouse (laboratorio) simula un dispositivo Moto G4 su connessione 3G lenta: utile in sviluppo, non riflette la realtà. I dati di campo provengono dal Chrome User Experience Report (CrUX) e misurano utenti reali. Google usa i dati di campo per il ranking. Se hai poche visite, CrUX potrebbe non avere dati sufficienti: in quel caso Lighthouse è l'unica opzione fino a quando il traffico cresce.
Una trappola comune: il punteggio Lighthouse di 95 sul MacBook dello sviluppatore non riflette affatto l'esperienza dell'utente reale su uno smartphone Android mid-range connesso a 4G instabile in metropolitana. I dati che raccogliamo mostrano che la divergenza tra punteggio laboratorio e dati di campo può essere di 20-40 punti per siti con JavaScript pesante. Usa sempre i dati di campo come punto di riferimento primario per le decisioni di ottimizzazione.
Le priorità di ottimizzazione
Nella nostra esperienza di realizzazione siti web, l'ordine di priorità più efficace è: prima eliminare il render-blocking (CSS e JS che bloccano il render iniziale), poi ottimizzare le immagini sopra la piega, poi ridurre il JavaScript che blocca il main thread, e infine stabilizzare il layout con dimensioni esplicite. Questo percorso porta la maggior parte dei siti da "Poor" a "Good" in 2-4 sprint.
Una nota importante sulla prioritizzazione: non tutte le ottimizzazioni hanno lo stesso impatto su tutti i siti. Un e-commerce con molte immagini di prodotto beneficia enormemente dall'ottimizzazione delle immagini; un sito applicativo con poco contenuto visivo ma molte interazioni beneficia di più dalla riduzione del JavaScript. Per questo il nostro processo inizia sempre con un audit baseline che identifica i colli di bottiglia specifici del sito in questione, non da una lista generica di best practice.
Next.js e i Core Web Vitals
Next.js è il framework che usiamo per costruire siti ad alte performance perché incorpora automaticamente molte best practice: ottimizzazione delle immagini con `next/image` (WebP/AVIF automatico, lazy loading, dimensioni esplicite), font ottimizzati con `next/font` (zero CLS da font swap), code splitting per route automatico, e prefetching dei link visibili. Queste feature abbattono ore di ottimizzazione manuale.
I dati che raccogliamo dai progetti Next.js che seguiamo mostrano punteggi medi di 92/100 su mobile e 97/100 su desktop misurati con Lighthouse, con Core Web Vitals tutti nella fascia "Good" sui dati reali CrUX. Il segreto non è solo il framework: è la combinazione di Next.js con una CDN come Vercel Edge Network, immagini AVIF ottimizzate, e font self-hosted. Ogni componente contribuisce a risultati che nessuno strumento da solo può ottenere. Se stai valutando una realizzazione di siti web ex novo, Next.js è la scelta che garantisce la base tecnica più solida per le performance.
Monitoraggio continuo: non basta ottimizzare una volta
I Core Web Vitals peggiorano nel tempo: nuovi plugin, aggiornamenti di terze parti, campagne marketing con script pesanti possono degradare le metriche senza che nessuno se ne accorga. Impostiamo sempre un alert su Google Search Console per i nostri clienti e usiamo Vercel Analytics per monitorare i Web Vitals in produzione ad ogni deploy.
Dalla nostra esperienza a Milano, il 40% dei siti che ottimizziamo e poi rilasciamo al cliente senza monitoraggio ritorna a metriche "Poor" entro 6-12 mesi. Le cause principali: installazione di nuovi plugin non ottimizzati, aggiunta di script di tracking per campagne stagionali mai rimossi, e aggiornamenti di tema che reintroducono CSS non ottimizzati. Il monitoraggio continuo non è un costo aggiuntivo: è il modo per proteggere l'investimento nell'ottimizzazione. Per chi vuole mantenere le performance nel tempo, il nostro piano di gestione siti web include monitoraggio mensile dei Core Web Vitals con alert e intervento proattivo.
Core Web Vitals e conversioni: il ROI dell'ottimizzazione
Google ha pubblicato case study che mostrano correlazioni dirette tra miglioramento dei Core Web Vitals e aumento delle conversioni. Vodafone ha registrato un +8% di vendite dopo aver migliorato il LCP. Tokopedia ha visto +23% di sessioni e +35% di conversioni. Nuzzel ha registrato +15% di visualizzazioni di pagina. I dati che raccogliamo internamente mostrano pattern simili: nei progetti di e-commerce italiani che abbiamo ottimizzato, il miglioramento del tasso di conversione medio dopo l'ottimizzazione delle performance è stato del 12-18%.
Il calcolo del ROI dell'ottimizzazione è spesso immediato: se un e-commerce genera 50.000€/mese e l'ottimizzazione porta un +15% di conversioni, il ritorno è di 7.500€/mese da un investimento una-tantum in ottimizzazione tecnica. Per le landing page delle campagne pubblicitarie il beneficio è doppio: migliore Quality Score Google Ads (meno costo per clic) e più conversioni una volta che l'utente arriva. Se vuoi capire il potenziale impatto per il tuo sito specifico, contattaci per una valutazione gratuita.
