Core Web Vitals 2026: guida pratica ottimizzazione LCP INP CLS

Nel 2026 i Core Web Vitals sono ormai la base condivisa su cui Google misura la qualità tecnica di un sito: LCP, INP e CLS pesano sul ranking, sulla percezione del brand e sul tasso di conversione. Questa guida pratica raccoglie soglie aggiornate, strumenti di misurazione e i fix che, nella nostra esperienza su clienti reali, hanno spostato davvero l’ago.

Cosa sono i Core Web Vitals nel 2026

I Core Web Vitals sono tre metriche di esperienza utente che Google considera nel Page Experience signal. Secondo il report HTTP Archive 2025, solo il 43% delle pagine web mobile raggiunge la soglia “Buono” su tutte e tre le metriche contemporaneamente, il che significa che oltre la metà del web offre ancora un’esperienza tecnica insufficiente. Da quando, nel marzo 2024, INP ha sostituito FID, l’asse responsiveness è diventato decisamente più severo e ha riequilibrato il peso fra render, interattività e stabilità visiva. Nel 2026 le tre metriche restano queste, con soglie misurate al 75° percentile dei visitatori reali del sito, separatamente per mobile e desktop:

Una pagina si considera “Buona” soltanto se almeno il 75% delle visite reali rientra nella soglia migliore per tutte e tre le metriche. Nei dashboard di Search Console basta che una sola scivoli a “Scarso” per declassare l’intero gruppo di URL.

Perché contano per SEO e business

I Core Web Vitals influenzano il ranking organico dal 2021 e dal 2024, con la spinta del mobile-first definitivo, il loro peso relativo nelle SERP competitive è ulteriormente cresciuto. In contesti come e-commerce, lead generation locale o editoria verticale, due risultati con contenuti equivalenti vengono ordinati dal dato di campo CrUX: il sito veloce vince. C’è anche un effetto pre-ranking: gli utenti che tornano alla SERP perché la pagina è lenta inviano segnali comportamentali negativi che, nel tempo, peggiorano la posizione media.

Le metriche di performance restano necessarie ma non più sufficienti da sole: da quando Google genera risposte dirette in pagina, anche i dati strutturati Schema.org, cioè come i sistemi generativi leggono e citano un contenuto, pesano sulla visibilità — approfondito in questa guida su Schema.org per AI search.

Il valore vero però non è soltanto SEO. Un nostro cliente del settore e-commerce moda, dopo una sprint di ottimizzazione mirata, ha portato il LCP mobile da 4,2 s a 1,8 s. L’effetto misurato: +18% sul tasso di conversione e -12% sul bounce rate, a parità di traffico e budget media. La performance non è SEO contro UX: è la stessa cosa. Vale la pena considerare l’ottimizzazione come voce di budget fin dal preventivo: nella guida quanto costa un sito web in Italia nel 2026 spieghiamo dove collocare questo investimento.

Strumenti per misurare Core Web Vitals

Misurare bene è la metà del lavoro. Nel 2026 lo stack consigliato per una PMI o un team in-house è composto da pochi strumenti complementari:

• PageSpeed Insights: dati di laboratorio Lighthouse + dati di campo CrUX su singolo URL. Ottimo per debug puntuale.
• Search Console — Report Core Web Vitals: la fonte di verità ufficiale. Aggrega gli URL del sito per stato (Buono / Da migliorare / Scarso) su finestra mobile di 28 giorni.
• Chrome DevTools — pannello Performance: traccia dettagliata di main thread, long task e layout shift in locale. Indispensabile per attribuire la causa esatta di un INP alto.
• Web Vitals JS library: snippet ufficiale Google che invia i CWV reali della sessione utente al tuo analytics. Permette di costruire un Real User Monitoring (RUM) senza vendor terzi.
• WebPageTest: ottimo per stress test con device e network throttling realistici, soprattutto su mercati con copertura 4G eterogenea.

Ottimizzare LCP: il rendering iniziale

L’LCP misura il tempo necessario al rendering dell’elemento più grande visibile nel viewport iniziale. Quasi sempre è la hero image, un titolo testuale di grande dimensione o un blocco above-the-fold. Un LCP lento, nel 90% dei casi reali, dipende da una combinazione di TTFB elevato, hero non ottimizzata e risorse che bloccano il render.

• Preload della hero image: <link rel="preload" as="image" href="hero.webp" fetchpriority="high"> nel <head> taglia tipicamente 300-800 ms.
• CDN globale: Cloudflare, Bunny CDN o AWS CloudFront riducono il TTFB sulle visite internazionali e fanno cache edge degli asset statici.
• Formati immagine moderni: WebP è ormai standard, AVIF salva un ulteriore 25-35% di peso con qualità visiva equivalente. Servili con <picture> e fallback JPG/PNG.
• Hosting performante: Vercel, Kinsta, WP Engine, SiteGround GoGeek per WordPress. Il TTFB deve restare sotto i 300 ms da Milano, Roma e Napoli per non bruciare il budget di rendering.
• Lazy load disciplinato: loading="lazy" solo sotto la piega. Sulla hero usa loading="eager" + fetchpriority="high", altrimenti rischi di rallentare proprio l’elemento che conta.
• CSS critico inline e differimento del CSS non critico via media="print" onload: blocco render quasi azzerato.

Ottimizzare INP: rispondere alle interazioni

INP è la metrica che ha messo in difficoltà più siti nel 2024-2025. Misura il tempo dalla singola interazione (click, tap, key) all’aggiornamento visivo successivo, e considera il valore peggiore di tutta la sessione. Un solo handler pesante può rovinare l’INP della pagina.

• Code splitting JavaScript: dividi il bundle per route. Con Vite, Next.js o Remix è dichiarativo: ogni pagina carica solo il codice che serve.
• Defer di tutto il JS non critico: chat live, pixel marketing, A/B testing, widget social. Caricali con defer, o ancora meglio con scheduler.yield() dopo l’idle del main thread.
• Web Workers per task pesanti: parsing JSON grandi, ricerca client-side, calcoli matematici. Sposta il lavoro fuori dal main thread; il rendering resta reattivo.
• Debounce sugli input handler: input di ricerca, scroll listener e resize devono essere debounced o throttled (250-300 ms tipici). Evita event handler sincroni che forzano reflow.
• Long task chirurgici: rompi i task > 50 ms con scheduler.yield(), requestIdleCallback o setTimeout(0). In React 18+, useTransition e useDeferredValue sono alleati nativi.

Ottimizzare CLS: stabilità visiva

Il CLS misura quanto il layout “salta” durante il caricamento. Per chi legge è frustrante: clicchi su un pulsante e parte un banner ad, la riga si sposta, finisci sul link sbagliato. Google penalizza, e il problema spesso è chirurgicamente risolvibile.

• Width e height espliciti su immagini e iframe: anche se poi li ridimensioni in CSS responsive, il browser sa quanto spazio riservare. aspect-ratio CSS è l’alternativa moderna.
• Reserve space per gli annunci: dichiara dimensioni minime con CSS. L’ad network inserisce il contenuto dentro un placeholder già dimensionato. Mai injection tardiva senza spazio riservato.
• Font loading controllato: font-display: swap con size-adjust, ascent-override e descent-override per allineare il font di fallback al font finale. FOIT/FOUT ridotti a quasi zero.
• Skeleton screen: nei componenti che caricano in modo asincrono, mostra placeholder con le dimensioni reali. L’utente percepisce velocità e il layout non salta.
• Banner cookie e consent: collocali in overlay position: fixed oppure riservagli spazio sticky. Mai sopra il contenuto sotto forma di blocco che spinge il body.

Caso reale: e-commerce moda da LCP 4,2 s a 1,8 s

Cliente: catalogo fashion 8.000 SKU, 70% traffico mobile, hosting condiviso storico, WordPress + WooCommerce con accumulo di plugin. Punto di partenza: LCP mobile 4,2 s (Scarso), INP 480 ms, CLS 0,18.

In tre sprint siamo intervenuti: migrazione su hosting managed con TTFB sotto 250 ms, hero in AVIF + preload, CSS critico inline e resto differito, lazy load sotto la piega, code splitting del JS WooCommerce, font auto-hosted con size-adjust. Dopo le 6 settimane di rolling CrUX: LCP 1,8 s, INP 190 ms, CLS 0,06. Tutte e tre “Buono”, conversioni mobile +18%, ricavo per utente +14%, posizione media keyword brand +1,3 in Search Console. Quando i limiti di performance di WordPress diventano strutturali vale la pena valutare anche l'alternativa architetturale, come analizziamo nella guida WordPress vs custom development.

Errori comuni da evitare nel 2026

1. Fidarsi solo del punteggio Lighthouse: è laboratorio, non campo. Un 95 a sintetico può convivere con CrUX scadente. Decidi sul campo.
2. Ottimizzare la home e dimenticare le pagine prodotto: Search Console raggruppa gli URL per pattern. Una sezione lenta penalizza tutto il gruppo.
3. Mettere troppi plugin di caching insieme: si pestano i piedi, generano flush continui, peggiorano il TTFB. Scegline uno e configuralo bene.
4. Lazy load anche sopra la piega: dimezza la velocità percepita e il LCP esplode. Eager + fetchpriority sulla hero, lazy solo sotto.
5. Ignorare l’INP perché “la pagina è veloce”: un singolo bundle pesante o un handler bloccante rovinano l’INP anche su una pagina con LCP ottimo. Le tre metriche vanno trattate insieme.

Checklist operativa Core Web Vitals 2026

1. Esporta da Search Console l’elenco URL “Scarso” e “Da migliorare”.
2. Esegui PageSpeed Insights su un URL rappresentativo per gruppo: home, categoria, prodotto/articolo.
3. Identifica la metrica peggiore di ogni gruppo; risolvi prima quella, non distribuire energie a pioggia.
4. Attiva un CDN globale e verifica TTFB < 300 ms dai principali POP italiani.
5. Implementa preload + WebP/AVIF sulla hero di ogni template.
6. Audita il bundle JS con Coverage di DevTools: rimuovi librerie usate al < 30%.
7. Installa la web-vitals JS library e logga i valori reali in Analytics 4 o nel tuo product analytics.
8. Setta un budget di performance in CI (Lighthouse CI o WebPageTest API) e blocca i merge che lo sforano.
9. Attendi 4-6 settimane e ricontrolla Search Console: la finestra CrUX è 28 giorni.
10. Documenta i risultati e congela lo standard: ogni nuova feature deve dimostrare di rispettare il budget.