Core Web Vitals nel 2026: INP, LCP e CLS spiegati bene

I Core Web Vitals sono le tre metriche con cui Google misura l'esperienza reale degli utenti sul tuo sito: LCP (velocità di caricamento del contenuto principale), INP (reattività alle interazioni) e CLS (stabilità visiva). Non sono un capriccio tecnico: incidono sul posizionamento, ma soprattutto sul tasso di conversione. In questa guida aggiornata al 2026 vediamo cosa misura ogni metrica, come leggere i dati giusti e quali interventi spostano davvero l'ago della bilancia su un sito PHP o WordPress.

Cosa sono i Core Web Vitals (e cosa non sono)

I Core Web Vitals fanno parte del segnale di page experience di Google. Sono un sottoinsieme volutamente piccolo di metriche, scelto perché copre le tre frustrazioni più comuni di chi naviga: "non si carica", "non risponde quando clicco", "mi salta il contenuto sotto il dito". Tutto il resto — TTFB, numero di richieste, peso della pagina — è diagnostica utile, ma non è un Core Web Vital.

Un chiarimento che evita mesi di lavoro sprecato: i Core Web Vitals sono un fattore di ranking di rifinitura, non un sostituto dei contenuti. Un sito velocissimo con contenuti deboli non scala la SERP. Un sito lento con contenuti eccellenti posiziona lo stesso, ma converte peggio e perde terreno a parità di rilevanza con i concorrenti. Il vero ritorno delle performance è commerciale prima che SEO: ogni secondo di attesa in più sulle pagine di conversione si traduce in carrelli e form abbandonati.

Le tre metriche e le soglie da rispettare

La soglia si considera superata quando il 75° percentile degli utenti reali rientra nel valore "buono", su mobile e desktop separatamente. Non conta la media: conta che tre utenti su quattro abbiano una buona esperienza. È una differenza sostanziale, perché la media nasconde proprio la coda lunga dei dispositivi lenti e delle connessioni mobili scadenti.

LCP: Largest Contentful Paint

LCP misura quanto tempo passa prima che l'utente veda il contenuto principale: di solito l'immagine hero, un video poster o un blocco di testo di grandi dimensioni. Si scompone in quattro sotto-fasi, e sapere quale pesa di più è metà del lavoro:

• TTFB (tempo di risposta del server): hosting, query al database, assenza di cache applicativa
• Resource load delay: quanto tardi il browser scopre la risorsa critica
• Resource load time: quanto pesa e quanto ci mette a scaricarsi
• Element render delay: CSS e JavaScript che bloccano il rendering

INP: Interaction to Next Paint

INP ha sostituito il vecchio FID e ha alzato l'asticella. Mentre FID misurava solo il ritardo della prima interazione, INP osserva tutte le interazioni della sessione e riporta di fatto la peggiore: dal click sul menu all'apertura di un accordion, fino all'invio di un form. Una pagina che apre bene ma diventa legnosa appena l'utente inizia a usarla oggi viene penalizzata, mentre prima passava indenne.

CLS: Cumulative Layout Shift

CLS quantifica quanto il layout "balla" durante il caricamento. Le cause sono quasi sempre le stesse quattro: immagini senza attributi width e height, banner cookie o promozionali iniettati via JavaScript, font web che sostituiscono il fallback con metriche diverse, contenuti pubblicitari o widget di terze parti senza spazio riservato.

Dati di campo e dati di laboratorio: non confonderli

L'errore più comune è ottimizzare inseguendo il punteggio di Lighthouse. Lighthouse produce dati di laboratorio: una simulazione su una macchina e una rete standardizzate, utilissima per il debug ma che non decide nulla ai fini del ranking. Quello che conta sono i dati di campo raccolti dal Chrome UX Report sugli utenti reali del tuo sito, aggregati su una finestra mobile di 28 giorni.

• Search Console > Segnali web essenziali: la fonte di verità, raggruppa gli URL per tipologia di problema
• PageSpeed Insights: mostra insieme campo (in alto) e laboratorio (in basso); leggi sempre prima la sezione in alto
• Lighthouse in locale: per verificare l'effetto di una modifica prima del rilascio
• RUM proprietario: la libreria web-vitals registra i valori reali e li invia al tuo endpoint. È l'unico modo per capire quale template o quale interazione specifica sta rovinando l'INP

Corollario operativo: dopo un intervento, la Search Console impiega fino a 28 giorni per riflettere il miglioramento. Non è il deploy che ha fallito, è la finestra di aggregazione che deve scorrere.

Come migliorare LCP: gli interventi che pagano

• Abbattere il TTFB lato server: OPcache attivo e dimensionato, query lente indicizzate, cache applicativa sulle pagine e sui frammenti costosi. Su un'applicazione PHP, un TTFB oltre 600 ms è quasi sempre un problema di database o di assenza di caching, non di banda
• Preload della risorsa LCP: <link rel="preload" as="image" fetchpriority="high"> sull'immagine hero, così il browser non aspetta di parsare il CSS per scoprirla
• Formati moderni: WebP o AVIF al posto di JPEG, con srcset e sizes per servire l'immagine giusta a ogni dispositivo. Su siti reali è spesso l'intervento con il miglior rapporto tra sforzo e risultato
• Mai lazy loading sull'immagine hero: è l'errore più frequente dopo l'installazione di un plugin di ottimizzazione automatica. Il lazy loading serve sotto la piega, non sopra
• CSS critico inline e resto del foglio di stile caricato in modo differito
• CDN e compressione Brotli: latenza di rete più bassa e payload più leggeri

Come migliorare INP: liberare il main thread

INP è un problema di JavaScript, quasi sempre. Il thread principale del browser è occupato a eseguire codice e non riesce a disegnare il fotogramma successivo all'interazione. Gli interventi efficaci:

• Spezzare i long task: qualunque funzione che occupi il main thread per più di 50 ms va suddivisa, cedendo il controllo al browser tra un blocco e l'altro
• Ridurre il codice di terze parti: chat, heatmap, pixel pubblicitari e tag manager sono i principali indiziati. Caricali dopo l'interazione o su richiesta esplicita, non nel blocco iniziale
• Delegare gli eventi invece di registrare centinaia di listener su singoli elementi
• Rimandare il lavoro non urgente: aggiorna subito ciò che l'utente vede, sposta analytics e calcoli accessori dopo il paint
• Evitare il reflow sincrono nei gestori di evento: leggere e scrivere il DOM alternativamente costringe il browser a ricalcolare il layout più volte

Come azzerare il CLS: cinque regole

• Dichiara sempre width e height (o aspect-ratio) su immagini, iframe e video
• Riserva lo spazio per banner, cookie bar e widget prima che vengano popolati
• Usa font-display: swap insieme a un fallback con metriche simili, e fai il preload dei font critici
• Non inserire elementi sopra contenuti già visibili: le notifiche vanno in overlay, non nel flusso
• Anima solo transform e opacity: le altre proprietà provocano ricalcoli di layout

Core Web Vitals su WordPress: il caso più frequente

Su WordPress il quadro si ripete con una regolarità impressionante: tema commerciale pesante, page builder che genera markup ridondante, dieci plugin che caricano ciascuno il proprio CSS e JavaScript su ogni pagina, e un plugin di cache configurato con le impostazioni predefinite. Il risultato tipico è LCP oltre i 4 secondi su mobile e INP nella fascia rossa.

L'ordine di intervento che funziona: prima la cache di pagina e l'ottimizzazione delle immagini, poi il caricamento condizionale degli asset per tipo di pagina, infine la sostituzione dei plugin ridondanti. Ho raccontato il percorso completo in WordPress lento: 7 cause comuni e come velocizzarlo. Quando il tema è talmente stratificato da rendere l'ottimizzazione più costosa della riscrittura, vale la pena valutare se WordPress sia ancora la scelta giusta.

Performance e AI search: perché conta ancora di più

Con la diffusione delle risposte generate da AI, i crawler che alimentano i motori conversazionali hanno budget di scansione e timeout stringenti. Una pagina che risponde lentamente ha meno probabilità di essere scansionata a fondo e citata come fonte. Velocità e struttura semantica lavorano insieme: sono due facce della stessa ottimizzazione, come spiego in GEO: ottimizzare il sito per ChatGPT, Google AI e Perplexity.

Domande frequenti sui Core Web Vitals

Quanto pesano davvero sul posizionamento?

Sono un fattore di rifinitura: a parità di rilevanza e autorevolezza, il sito con migliore esperienza utente vince. Su query molto competitive quella differenza si vede; su query di nicchia, contenuto e link contano molto di più.

Serve un punteggio 100 su PageSpeed Insights?

No, ed è una trappola costosa. Serve stare in fascia verde nei dati di campo per LCP, INP e CLS. Rincorrere gli ultimi punti del punteggio di laboratorio ha un costo crescente e un ritorno che tende a zero.

In quanto tempo si vedono i risultati?

Nei dati di laboratorio subito dopo il rilascio; nei dati di campo servono fino a 28 giorni per il ricambio completo della finestra. Gli effetti su traffico e conversioni sono in genere misurabili entro due mesi.

Meglio ottimizzare o rifare il sito?

Dipende dalla causa. Se il problema è configurazione, immagini e asset, si ottimizza. Se il problema è strutturale — tema o framework front-end sovradimensionato rispetto all'obiettivo — l'ottimizzazione diventa manutenzione perpetua e conviene rifondare il front-end.

Checklist operativa

• Esporta gli URL in fascia rossa da Search Console e raggruppali per template, non per singola pagina
• Misura il TTFB reale del template peggiore e verifica se il collo di bottiglia è server o front-end
• Identifica l'elemento LCP di ogni template: spesso non è quello che immagini
• Elimina il lazy loading sopra la piega e aggiungi il preload della risorsa critica
• Converti le immagini in WebP o AVIF con dimensioni responsive
• Fai l'inventario degli script di terze parti e rimanda tutto ciò che non serve al primo paint
• Fissa dimensioni e spazi riservati per ogni elemento che arriva in modo asincrono
• Attiva un monitoraggio RUM continuo: senza dati reali si lavora a sensazione

MameTech: performance misurate, non promesse

Ottimizzo le performance di siti e applicazioni PHP, Yii2 e WordPress partendo sempre dai dati di campo: analisi dei template critici, interventi mirati su server, asset e front-end, monitoraggio continuo dopo il rilascio. Lavoro da remoto con aziende, professionisti e web agency in tutta Italia. Se il tuo sito è in fascia rossa nella Search Console e non sai da dove cominciare, scrivimi: la prima analisi con priorità di intervento è gratuita.