Core Web Vitals nel 2026: cosa muove davvero LCP, INP e CLS

La maggior parte dei team tratta ancora i Core Web Vitals come un punteggio di Lighthouse da inseguire, non come un'architettura da correggere. Per questo un sito può ottenere 95 su PageSpeed Insights e comunque fallire la valutazione Core Web Vitals in Google Search Console. Quei due numeri misurano cose diverse, e solo uno dei due influisce sul ranking e sugli utenti reali.

Salteremo i consigli sui plugin. Se la tua soluzione a un problema di performance è "installa un plugin di caching", stai curando un sintomo, non la causa. Ecco cosa muove davvero ciascuna metrica, e perché i dati di laboratorio e quelli sul campo sono in disaccordo abbastanza spesso da non poterti fidare di uno solo dei due.

LCP è un problema di critical path, non di immagini

Largest Contentful Paint misura quando l'elemento visibile più grande — di solito un'immagine hero, un titolo o un banner — finisce di essere renderizzato. I team ripiegano di default su "comprimi l'immagine", e aiuta, ma raramente è il collo di bottiglia oltre un certo punto.

Il vero critical path è questo:

1. Time to first byte. Se il tuo server o la tua origine impiegano diverse centinaia di millisecondi a rispondere prima che il browser abbia qualcosa su cui lavorare, nessuna compressione di immagini ti salva. Il rendering all'edge, le read replica regionali e lo spostamento delle route sensibili al TTFB sul compute layer di una CDN (Cloudflare Workers, Vercel Edge, Lambda@Edge) possono ridurre sensibilmente quel tempo — quanto dipende molto dal tuo stack, dalla regione e dal punto di partenza.
2. CSS e JS che bloccano il rendering. Ogni foglio di stile e ogni script sincrono che il browser deve interpretare prima di poter dipingere la pagina ritarda l'LCP. Inserisci inline il CSS critico per il contenuto above-the-fold e rimanda il resto.
3. Individuabilità delle risorse. Il preload scanner del browser deve trovare presto la tua immagine LCP. Se viene iniettata via JavaScript, caricata da un `background-image` in CSS, o nascosta dietro una fetch di dati lato client, ne hai ritardato l'individuazione di centinaia di millisecondi. Usa `fetchpriority="high"` sul tag `<img>` effettivo e un `<link rel="preload">` dedicato.
4. Caricamento dei font. Se il tuo elemento LCP è testo e stai caricando un web font senza una strategia di fallback, stai aggiungendo un intero round-trip prima che quel testo possa essere dipinto. `font-display: swap` e il preloading risolvono due metà diverse del problema: `swap` dipinge subito un font di fallback così il round-trip non blocca l'LCP (ma può causare un reflow visibile — e un colpo al CLS — quando il font vero subentra), mentre il preloading del file del font ne accorcia il fetch così lo scambio avviene prima. Usali insieme, non uno al posto dell'altro.

Niente di tutto questo è un'impostazione da plugin. Sono scelte di routing, ordine del markup e resource hint — decisioni prese nella tua build pipeline e nel tuo HTML, non in una dashboard di WordPress.

INP è ciò che succede quando la tua architettura JavaScript non scala

Interaction to Next Paint ha sostituito First Input Delay come Core Web Vital a marzo 2024, ed è una metrica più difficile da manipolare perché campiona ogni interazione durante la visita alla pagina, non solo la prima. Un sito può avere un primo click veloce e comunque fallire l'INP perché un'interazione successiva, dopo che si sono montati abbastanza componenti e si è accumulato abbastanza stato, impiega abbastanza tempo a rispondere da trascinare giù il punteggio al p75 — anche se il primo click sembrava istantaneo.

L'INP è dominato dalla contesa sul thread principale. Il browser non può rispondere a un tap o a una battuta mentre è occupato a eseguire JavaScript. Le cause più comuni:

• Task lunghi. Qualsiasi cosa sopra i 50ms blocca il main thread dall'elaborare l'input. I grandi aggiornamenti di stato, i re-render non ottimizzati e gli script sincroni di terze parti (widget di chat, tag di analytics, ad exchange) sono i colpevoli più comuni.
• Costo dell'hydration. I framework client-heavy che fanno l'hydration dell'intera pagina al caricamento — invece che in modo progressivo o selettivo — occupano il main thread esattamente nel momento in cui gli utenti iniziano a interagire. L'architettura a isole (l'hydration selettiva di componenti isolati di Astro) e la resumability (l'approccio di Qwik, che serializza lo stato di esecuzione e riprende senza rieseguire affatto la logica dei componenti) sono due tecniche diverse che affrontano entrambe questo problema, insieme ai React Server Components. Se stai facendo girare una SPA completamente client-rendered per un sito marketing, l'INP è di solito il punto in cui il problema emerge per primo.
• Event handler non raggruppati. Un singolo input che innesca più re-render sincroni, ricalcoli di layout o chiamate API si accumula rapidamente. Il debouncing, `requestIdleCallback` per il lavoro non urgente e lo spostamento dei calcoli pesanti sui Web Worker aiutano tutti.
• Volume di script di terze parti. I tag manager che caricano una dozzina di script a valle sono tra i principali killer dell'INP perché non controlli il loro costo di esecuzione, solo se caricarli e quando.

Il code splitting e il lazy loading basato sulle route riducono il JS totale spedito, ma l'INP in particolare premia il tenere libero il main thread durante le finestre di interazione — è un problema di scheduling tanto quanto uno di dimensione del bundle.

Il CLS resta soprattutto un problema di disciplina

Cumulative Layout Shift è la più risolvibile delle tre metriche, ed è l'unica che non ha nulla a che fare con l'infrastruttura server. È causata da:

• Immagini ed embed senza `width`/`height` espliciti o `aspect-ratio` riservato nel CSS.
• Web font che, al momento dello scambio, subentrano con un fallback metricamente diverso, spostando il reflow del testo — si mitiga con `size-adjust` in un blocco `@font-face` calibrato sul tuo font di fallback.
• Pubblicità, banner sui cookie e contenuti iniettati dinamicamente che spingono giù il contenuto esistente dopo che il layout iniziale è già stato dipinto.
• Contenuto inserito sopra il contenuto esistente (un errore comune di CMS/personalizzazione — un banner iniettato in cima dopo il caricamento della pagina).

Un CLS sotto 0.1 è raggiungibile su quasi qualsiasi stack una volta che ogni elemento dinamico ha uno spazio riservato. Non esiste una soluzione infrastrutturale per un attributo `width` mancante.

Perché i punteggi da laboratorio e i dati sul campo non coincidono

È la parte che la maggior parte dei report salta. Lighthouse e PageSpeed Insights eseguono i dati "da laboratorio" facendo girare un singolo caricamento di pagina su un dispositivo simulato di fascia media, con una connessione limitata artificialmente, con cache pulita e senza la variabilità reale degli utenti. È riproducibile, il che lo rende utile per i test di regressione — ma è uno snapshot sintetico.

I dati sul campo — quelli che compaiono nel report Core Web Vitals di Search Console e nel Chrome UX Report (CrUX) — sono un aggregato mobile su 28 giorni al settantacinquesimo percentile, raccolto da utenti Chrome reali su dispositivi reali, reti reali e stati di cache reali. È ciò che Google usa davvero come segnale di ranking.

Lo scarto si manifesta in modi prevedibili:

• Mix di dispositivi. Il tuo test da laboratorio gira su un dispositivo simulato fisso. I tuoi dati sul campo includono veri smartphone Android di fascia bassa su rete 4G, che mostreranno sempre un INP peggiore rispetto a un profilo sintetico di fascia media.
• Variabilità delle terze parti. I test A/B, le piattaforme di gestione del consenso e i tag pubblicitari spesso non si attivano in modo identico durante una scansione da laboratorio (che potrebbe non accettare i cookie, non attivare la geolocalizzazione o non caricare reti pubblicitarie specifiche per regione) rispetto a come fanno con il traffico reale.
• Stato della cache. I test da laboratorio spesso girano a freddo. Gli utenti reali colpiscono la cache della tua CDN, i font già caricati e le risorse già scaricate nelle visite ripetute, il che può far apparire i dati sul campo migliori rispetto al laboratorio — il contrario del pattern abituale.
• Dimensione del campione e percentile. Un singolo test da laboratorio è un solo punto dato. I dati sul campo al p75 significano che un quarto delle tue visite reali è peggiore del numero che vedi — che è esattamente la coda che le "soluzioni rapide" basate su plugin non toccano mai.

Tratta i dati da laboratorio come un gate di regressione in CI, non come un proxy del tuo punteggio reale. Tratta i dati sul campo come la verità di cui sei responsabile, e diagnosticali con un monitoraggio degli utenti reali, non con Lighthouse eseguito più volte.

Cosa prioritizzare davvero

Se stai facendo triage: correggi prima il CLS (il più economico, il più certo), poi l'LCP (cambiamenti infrastrutturali e di markup con numeri chiari prima/dopo), e tratta l'INP come una preoccupazione architetturale continua piuttosto che una correzione una tantum — degrada di nuovo ogni volta che pubblichi un nuovo script di terze parti o un albero di componenti più pesante.

È anche per questo che il lavoro sui Core Web Vitals appartiene a chi scrive e pubblica il tuo codice, non a una checklist di marketing. Il nostro team di SEO tecnica tratta le performance come un problema di ingegneria con un effetto collaterale sul ranking, non il contrario — perché è l'ordine in cui funziona davvero.

In sintesi: i punteggi da laboratorio ti dicono se hai rotto qualcosa da ieri a oggi. I dati sul campo ti dicono cosa hanno realmente vissuto i tuoi utenti e Google. Se questi due numeri non coincidono, credi ai dati sul campo — e vai a correggere l'architettura, non le impostazioni del plugin.