Core Web Vitals 2026: La Guida Completa Dopo il Google Core Update di Marzo

Il 10 marzo 2026 Google ha lanciato un Core Update che ha rafforzato in modo significativo il peso dei Core Web Vitals nell'algoritmo di ranking. I primi dati post-update mostrano che i siti che superano i tre threshold "good" hanno guadagnato posizioni medie nei primi tre risultati, mentre quelli sotto soglia sono scivolati anche di 5-10 posizioni su query competitive. Eppure, secondo i dati del Chrome User Experience Report (CrUX), solo il 47% dei siti raggiunge attualmente i threshold "good" su tutte e tre le metriche. Questo significa che oltre la metà del web è in zona di rischio.

In questa guida vediamo le tre metriche del 2026 (con i nuovi threshold ufficiali), come misurarle correttamente, le 5 cause più comuni di fallimento per ogni metrica, e gli interventi tecnici con il miglior rapporto effort/risultato. Tutto basato su dati 2026, non su consigli generici del 2020.

Le tre metriche del 2026: LCP, INP, CLS

Google misura la performance percepita dell'utente attraverso tre metriche che insieme formano i Core Web Vitals. Dal marzo 2024 INP ha sostituito FID come metrica di responsiveness, e nel 2026 le soglie restano:

LCP (Largest Contentful Paint) – Misura quanto tempo serve perché il contenuto principale "above the fold" appaia all'utente. Target: sotto i 2,5 secondi. Tra 2,5 e 4 secondi è "needs improvement", oltre i 4 è "poor".

INP (Interaction to Next Paint) – Misura la responsiveness della pagina alle interazioni dell'utente (click, tap, tasto). Diverso da FID, INP cattura l'intero ciclo dell'interazione, non solo il primo input. Target: sotto i 200 millisecondi. Tra 200 e 500 ms è critico, oltre 500 è fail.

CLS (Cumulative Layout Shift) – Misura la stabilità visiva: quanto la pagina "salta" mentre carica. Target: sotto 0,1. Tra 0,1 e 0,25 è warning.

Un dettaglio cruciale: Google usa il 75° percentile dei dati reali del CrUX per giudicare. Significa che il 75% dei tuoi utenti reali deve avere un'esperienza sotto soglia, non la media. Una manciata di utenti su connessioni veloci non basta a salvare il punteggio se il resto naviga da 4G in mobilità.

Come misurare i Core Web Vitals nel 2026

Esistono due tipi di misurazione che spesso si confondono: lab data (simulato in condizioni controllate) e field data (dati reali aggregati dai browser Chrome degli utenti). Google ranking usa solo i field data via CrUX. I lab data servono al debugging.

Tool da usare (in ordine di importanza):

1) PageSpeed Insights (pagespeed.web.dev): combina lab e field data in un'unica dashboard. Verifica entrambi: se field data è buono ma lab è cattivo, il sito sta crescendo. Viceversa, hai un problema in arrivo.

2) Google Search Console > Core Web Vitals: report aggregato sulle pagine reali del tuo sito, con gruppi di URL "good", "needs improvement", "poor". È il dato più affidabile per capire l'andamento del tuo intero sito.

3) Chrome DevTools > Lighthouse + Performance tab: per il debug puntuale di una pagina problematica, con trace dettagliato di ogni elemento bloccante.

4) WebPageTest (webpagetest.org): per test su connessioni e dispositivi specifici (es. Moto G4 su 3G lento, scenario worst-case).

Fix LCP: i 5 colpevoli più frequenti

L'LCP è quasi sempre legato a un'immagine, un video, un blocco di testo o un elemento di background nella parte alta della pagina. Le cause più frequenti dietro un LCP fuori soglia:

1) Hero image non ottimizzata: una foto da 2 MB in JPEG senza compressione è una condanna. Soluzione: WebP o AVIF, dimensioni responsive con srcset, fetchpriority="high" sull'immagine LCP candidata.

2) Web font che bloccano il render: i font caricati senza font-display: swap ritardano il rendering del testo. In Next.js usa next/font che gestisce automaticamente il preload + fallback ottimale.

3) Server response time alto: TTFB (Time To First Byte) sopra i 600ms ti porta direttamente fuori dal target LCP. Causa principale: hosting condiviso lento o assenza di cache lato server (LSCache, Varnish, Cloudflare).

4) Render-blocking CSS/JS: file CSS o script di terze parti che bloccano il main thread. Inline il CSS critico, deferisci il resto, async per i JS non critici.

5) Mancanza di CDN: se i tuoi asset partono da un server europeo e l'utente sta in Brasile, l'LCP esplode. Cloudflare gratis o BunnyCDN a 1$/mese risolvono questo problema.

Fix INP: dove muore la responsiveness

INP è la metrica più ostica perché dipende dal JavaScript. Quando l'utente clicca un bottone e la pagina sembra "freezata" per mezzo secondo, l'INP esplode. Le cause tipiche:

1) Long Tasks JavaScript (task >50ms che bloccano il main thread). Tipico di librerie pesanti caricate sincrone, calcoli inutili in render, useEffect React mal gestiti.

2) Script di terze parti: Google Tag Manager mal configurato, pixel Facebook, chatbot caricati sincroni, tutti hanno un costo INP. Audit critico: quali tag servono davvero?

3) Hydration costosa in React/Next.js: pagine con troppi componenti client-side che si idratano simultaneamente. Soluzione: "use server" in Next.js 13+ App Router, server components dove possibile, lazy loading dei componenti pesanti.

4) Event handler sincroni pesanti: un onClick che apre un modal calcolando 1000 elementi prima è un disastro. Sposta i calcoli pesanti in requestIdleCallback o in un Web Worker.

5) CSS animations su properties costose (es. top, left, width): usa solo transform e opacity per animare, sono GPU-accelerati e non triggerano layout.

Fix CLS: stabilizza la pagina

CLS è di solito la metrica più facile da sistemare. Le cause sono quasi sempre quattro:

1) Immagini senza width/height esplicite: senza dimensioni il browser non sa quanto spazio riservare e shifta. Soluzione: width="800" height="450" nel tag <img>, sempre.

2) Web font che cambiano layout: se il font cambia a metà render, il testo cambia dimensioni e tutto sotto si sposta. Usa size-adjust + ascent-override nel @font-face, oppure next/font automatico in Next.js.

3) Pubblicità o iframe senza spazio riservato: ogni adv slot deve avere min-height esplicita per evitare shift quando l'ads viene caricato.

4) Cookie banner o modali che spingono il contenuto: il cookie banner deve essere in position: fixed sopra il contenuto, mai dentro il flow.

L'impatto sul ranking SEO

Una domanda ricorrente: quanto pesano davvero i Core Web Vitals nel ranking? Google li definisce ufficialmente uno dei page experience signals, ma il peso reale varia per query. Nel 2026, con il Core Update di marzo, abbiamo osservato due pattern chiari:

Per query competitive (es. "miglior CRM gestionale", "agenzia web milano"), CWV è un fattore decisivo tra siti con qualità contenutistica simile. A parità di contenuto, il sito veloce vince.

Per query informative o long-tail, il contenuto rimane prevalente, ma siti con CWV "poor" rischiano comunque ban da rich results e featured snippet.

Il dato concreto: nei nostri clienti che sono passati da CWV "poor" a "good" tra 2025 e 2026, la media crescita di traffico organico è stata del +43% a 6 mesi, senza alcun lavoro contenutistico aggiuntivo. È la prova che i CWV non sono "un tool tra tanti": sono un acceleratore moltiplicativo del lavoro SEO esistente.

Roadmap di lavoro 30-60-90 giorni

Per una PMI con un sito che oggi è in zona "needs improvement" o "poor", suggerisco questo ordine pratico:

Giorni 1-15: misurazione baseline, audit con PageSpeed Insights + Search Console, identificazione delle 3 pagine più trafficate con CWV peggiori (Pareto).

Giorni 16-30: fix LCP sulle pagine prioritarie (immagini, font, server, CDN). Tipicamente il fix LCP è quello a maggiore ROI iniziale.

Giorni 31-60: fix INP (audit script terze parti, hydration React, event handler), fix CLS (immagini con dimensioni, cookie banner fixed).

Giorni 61-90: monitoring continuo, expansion del lavoro alle altre pagine del sito, set up alerting se CWV peggiora oltre soglia.

A 6 mesi dovresti vedere il sito stabilmente in zona "good" sul 75° percentile e i benefici SEO accumulati. Da quel momento, il monitoring diventa preventivo: ogni nuovo modulo, ogni nuova integrazione, ogni nuovo deploy va testato per CWV prima di andare in produzione.