Core Web Vitals 2026: cosa cambia davvero

Nel 2026, parlando di Core Web Vitals, girano tre voci: INP avrebbe smesso di essere il parente povero di LCP, le soglie verrebbero applicate con più severità, e Google non guarderebbe più la singola pagina ma la salute dell'intero sito. Una parte è documentata, una parte no, e la differenza cambia cosa ti conviene fare oggi.

C'è poi un fattore che gli articoli in circolazione citano di rado: una buona fetta di questi numeri dipende dal server su cui gira il tuo sito, non dal tema o dal plugin di turno.

Cosa sono i Core Web Vitals (e quali sono nel 2026)

I Core Web Vitals sono tre metriche con cui Google misura l'esperienza reale di chi visita una pagina. Nel 2026 sono queste, e le soglie "buone" le trovi nella documentazione ufficiale di Google Search:

La novità strutturale ha già due anni: INP ha sostituito il vecchio FID a marzo 2024. È nel 2026 però che le analisi di settore hanno iniziato a trattarlo alla pari di LCP. Tradotto: non basta che la pagina si carichi in fretta, deve anche rispondere in fretta quando l'utente ci clicca dentro.

INP: la reattività ora conta quanto la velocità

LCP misura quanto ci mette il contenuto ad apparire. INP misura una cosa diversa e spesso più fastidiosa per chi naviga: quanto tempo passa tra un'azione (un tap, un clic, l'apertura di un menu) e il momento in cui la pagina risponde visivamente.

È la metrica che punisce i siti pieni di JavaScript. Un tema WordPress carico di plugin, popup e script di terze parti può avere un LCP accettabile e un INP pessimo, perché il browser resta occupato a eseguire codice mentre tu stai cliccando. Chi naviga percepisce il sito come lento anche se la prima schermata è comparsa in fretta.

La soglia ufficiale resta 200 millisecondi: sotto quel valore sei a posto, tra 200 e 500 ms finisci nella fascia "da migliorare". Diverse analisi di settore pubblicate nel 2026 stimano che i siti fermi in quella fascia perdano in media meno di una posizione sulle query competitive. Sembra poco, finché non competi su query dove una posizione vale una fetta importante di clic.

Le soglie sono diventate più severe? Cosa è vero e cosa no

Qui serve parlare chiaro, perché è il punto su cui la maggior parte degli articoli ti porta fuori strada.

Alcune analisi SEO del 2026 sostengono che Google, con il Core Update di marzo, abbia abbassato la soglia "buona" di LCP da 2,5 a 2,0 secondi, e che la valutazione dei Core Web Vitals sia passata da pagina-per-pagina a una media su tutto il dominio. Ma quì sorge un problema: Google non le ha mai confermate. La pagina ufficiale di Search continua a indicare 2,5 secondi come soglia LCP e descrive il report di Search Console come una misurazione a livello di singola pagina.

Trattale quindi come uno scenario "probabile", non come una regola. Se progetti il sito per stare sotto i 2,0 secondi e per essere veloce in modo uniforme su tutte le sezioni, sei a posto sia che Google misuri pagina per pagina, sia che un domani aggreghi davvero a livello di dominio. È una scelta che non ti costa nulla se l'ipotesi è falsa e ti protegge se è vera.

Le rilevazioni concordano invece su un punto: la maggioranza dei siti non supera tutti e tre i Core Web Vitals su mobile.

Quanto conta il tuo hosting

I Core Web Vitals si misurano nel browser dell'utente, ma una buona fetta del risultato nasce molto prima, sul server. Qui smetti di ragionare su temi e plugin e inizi a guardare su cosa gira il sito.

• LCP parte dal TTFB. Il Largest Contentful Paint non può essere veloce se il server impiega tempo a rispondere alla prima richiesta (il Time To First Byte). Un hosting con molti utenti, con PHP obsoleto o senza cache lato server, ti regala mezzo secondo di ritardo prima ancora che il browser inizi a renderizzare la pagina.
• La versione di PHP. Versioni recenti di PHP eseguono lo stesso codice WordPress in modo più veloce. Un server che ti tiene su una versione vecchia ti sta rallentando TTFB e LCP senza che tu te ne accorga.
• HTTP/2 e compressione non sono opzionali. Il modo in cui il server consegna le risorse incide direttamente sui tempi di caricamento. Ne abbiamo parlato a suo tempo nei vantaggi di HTTP/2: multiplexing e compressione degli header migliorano LCP senza che tu tocchi una riga del sito.

Se sei su un piano hosting condiviso ben ottimizzato, con PHP aggiornabile e cache attiva, hai fatto già metà del lavoro. Se invece il tuo TTFB è alto e non riesci a portarlo giù per quanto ottimizzi le immagini, il problema non è il tuo sito: è dove lo tieni.

Da dove partire, in pratica

Niente panico e niente rivoluzioni.

1. Misura il dato reale, non il punteggio di laboratorio. Guarda il report Core Web Vitals in Search Console, che usa dati di campo (utenti veri), e affiancagli PageSpeed Insights per capire il perché.
2. LCP FIRST. Immagini pesanti non ottimizzate e TTFB alto sono le due cause più comuni.
3. INP. Riduci gli script di terze parti, togli i plugin che non usi, elimina il codice JavaScript non necessario. Ogni script in meno aumenta la velocità di renderizzazione.
4. Tieni CLS sotto controllo specificando sempre le dimensioni di immagini e iframe, così il layout non modifica la pagina mentre carica.

I Core Web Vitals sono un fattore di ranking, ma non il fattore. Un contenuto debole non scala le posizioni solo perché è veloce; vale il discorso fatto per l'ultimo core update di Google e per gli AI Overviews: senza contenuti che reggono, la tecnica da sola non cambia la tua situazione. La velocità ti serve a non perdere posizioni, raramente a guadagnarne.