Core Web Vitals: i 3 segnali Google che valgono il 30% del traffico

Core Web Vitals (CWV) sono tre metriche standardizzate che Google usa come segnale di ranking dal 2021: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), Cumulative Layout Shift (CLS). Misurano rispettivamente velocità di caricamento, reattività agli input, stabilità visiva.

Il peso nel ranking non è enorme in isolamento (tipicamente 5-15%), ma diventa cruciale per pagine che competono ad armi pari su altri fattori. Tra due risultati con contenuto e backlink simili, vince quello con CWV nel verde.

LCP misura quando il più grande elemento above-the-fold è disegnato. Soglia verde: ≤2.5 secondi. Arancione: ≤4 secondi. Rosso: >4 secondi. Tipicamente l'elemento misurato è l'hero image o l'H1.

Ottimizzazioni con maggior ROI: priority hint sull'immagine hero (`fetchpriority="high"`), preconnect al CDN, eliminazione di JavaScript bloccante prima del LCP, formati immagine moderni (AVIF, WebP).

INP misura il tempo tra l'interazione dell'utente (click, tap, keypress) e il prossimo paint visibile. Sostituisce FID dal marzo 2024. Soglia verde: ≤200ms. Arancione: ≤500ms. Rosso: >500ms.

INP è la metrica più difficile da ottimizzare. Le cause tipiche: JavaScript di terze parti pesante (chat widget, analytics non ottimizzati), event handler che bloccano il main thread, hydration lenta su framework SSR. Soluzione: code splitting aggressivo, debounce, web worker per task pesanti.

CLS misura quanto gli elementi della pagina si spostano dopo il caricamento iniziale. Soglia verde: ≤0.1. Arancione: ≤0.25. Rosso: >0.25.

Le cause principali: immagini senza dimensioni esplicite (width/height), iframe e ad placeholder che cambiano dimensione, font caricati senza fallback (FOUT), elementi caricati lazily che invadono il viewport. Soluzione: dimensioni esplicite ovunque, `font-display: swap`, riserva spazio per contenuti dinamici.

Lab data: PageSpeed Insights, Lighthouse, WebPageTest. Misurano in condizioni standard di laboratorio. Utile per testing, ma non rappresentano l'esperienza reale degli utenti.

Field data: Chrome User Experience Report (CrUX), Search Console Core Web Vitals report. Misurano l'esperienza reale degli utenti negli ultimi 28 giorni. Google usa il field data per il ranking. Le decisioni di ottimizzazione vanno prese sui field data, non sui lab.

Framework consigliati per CWV nativi: Next.js 14+, Astro, Remix. Tutti supportano server components, image optimization, font subsetting out of the box. Sconsigliati per CWV: WordPress (default), Wix, Shopify (default theme) — tutti richiedono lavoro extra per arrivare a 95+.

Hosting consigliato per LCP basso: Vercel, Cloudflare Pages, Netlify (edge cdn nativo). Hosting standard PHP/MySQL fa fatica a stare sotto i 2 secondi di LCP per audience internazionale senza CDN aggressivo.

Un caso tipico misurato: sito che passa da LCP 4.5s a 1.8s vede crescita del traffico organico del 15-25% nei 90 giorni successivi, a parità di backlink e contenuto. L'effetto si vede prima sulle pagine con competizione media; per query molto competitive servono mesi di accumulo.

Il vero ROI dei CWV non è solo nel ranking: è nel bounce rate (cala del 8-15% in media) e nel conversion rate (cresce del 5-12% per ogni secondo di LCP risparmiato). L'investimento tecnico ripaga sui due fronti contemporaneamente.

Sono un fattore di ordinamento reale ma di secondo livello: a parità di pertinenza favoriscono la pagina più veloce, non ribaltano un risultato meno pertinente. Aspettarsi di superare un concorrente più autorevole solo migliorando i tempi di caricamento porta a delusioni prevedibili.

Il beneficio più grande non è il posizionamento: è la conversione. Su rete mobile ogni secondo di attesa in più costa una quota misurabile di visitatori che se ne vanno prima di vedere qualcosa. Quel numero si legge nel conto economico molto prima che nelle posizioni.

Immagini servite a risoluzione da monitor su schermi da telefono. È la causa singola più diffusa e la più semplice da correggere: formati moderni, dimensioni adeguate al contenitore, caricamento differito per tutto ciò che sta sotto la prima schermata.

Caratteri tipografici caricati da server esterni che bloccano la comparsa del testo. Si risolve precaricandoli e dichiarando un carattere di sistema come ripiego, così il testo appare subito.

Script di terze parti — chat, banner dei cookie, strumenti di analisi, pixel pubblicitari — che si accumulano perché nessuno li conta. Vanno caricati dopo il contenuto e va tenuto un elenco di quali sono attivi e perché.

Lo spostamento del contenuto durante il caricamento è quasi sempre colpa di elementi che arrivano senza uno spazio riservato: immagini senza dimensioni dichiarate, banner inseriti in cima alla pagina, caratteri che cambiano l'altezza delle righe quando si caricano.

La correzione è meccanica: larghezza e altezza dichiarate su ogni immagine, spazio riservato per banner e riquadri pubblicitari, e per i caratteri una scelta di ripiego con metriche simili a quella definitiva.

È l'indicatore più fastidioso per chi usa il sito — il pulsante che si sposta mentre si sta per premerlo — e il più semplice da portare a zero.

Gli strumenti di simulazione danno un punteggio in condizioni ideali e sono utili per il confronto prima e dopo un intervento. Ma il dato che Google usa per il posizionamento viene dagli utenti reali, con le loro connessioni e i loro telefoni.

Il rapporto sull'esperienza in Search Console mostra proprio quel dato, aggregato su ventotto giorni. È la fonte che conta, e comporta due conseguenze: i miglioramenti compaiono con settimane di ritardo, e non ha senso reagire a un punteggio di simulazione che oscilla di dieci punti tra due esecuzioni.