Google INP 2026: Cosa Significa per il Tuo Sito

A marzo 2024, Google ha ufficialmente sostituito il First Input Delay (FID) con Interaction to Next Paint (INP) come Core Web Vital. Ad agosto 2026, non è più solo un segnale “nuovo” — è la metrica di reattività più determinante nel SEO moderno, e il modello di scoring di Google ha silenziosamente ridefinito il peso del segnale due volte dall’adozione. Se il tuo sito non è stato ottimizzato attivamente per INP, è molto probabile che stia perdendo posizioni adesso, in tempo reale.

In breve: INP misura quanto velocemente la tua pagina risponde visivamente a ogni interazione dell’utente — non solo alla prima. Un punteggio inferiore a 200 ms è considerato “Buono.” La maggior parte dei siti WordPress e di e-commerce nel 2026 è ancora nella banda “Da migliorare” (200–500 ms), perdendo silenziosamente terreno rispetto ai concorrenti più veloci — senza nemmeno saperlo.

Perché INP È Più Difficile di LCP — e Perché la Maggior Parte dei Siti Fallisce Ancora

Largest Contentful Paint (LCP) dice a Google quanto velocemente i tuoi contenuti si caricano. INP dice quanto velocemente la pagina reagisce dopo il caricamento. Il problema? La velocità di reazione dipende da cosa sta succedendo nel thread principale durante l’interazione — e il thread principale è un campo di battaglia sulla maggior parte dei siti web moderni.

Ogni script di terze parti, ogni pixel di analytics, ogni widget caricato in modo lazy compete per quel thread. Clicca un pulsante e, se il browser è occupato a eseguire un bundle JavaScript gonfio, non mostrerà la risposta visiva finché non ha finito. L’utente non vede nulla per 400 ms. Clicca di nuovo. Questo è un cattivo evento INP — e i dati CrUX di Google registrano ognuno di essi dagli utenti reali su dispositivi reali, ventiquattro ore su ventiquattro.

Cosa è cambiato tra il 2024 e l’agosto 2026? Google ha:

• Aumentato il peso di INP nel cluster complessivo dei segnali di page experience, rendendolo il fattore di reattività dominante rispetto a CLS e FID (ora dismesso)
• Espanso il campionamento CrUX per includere dispositivi Android di fascia media a livello globale — non solo sessioni desktop o flagship — rendendo strutturalmente più difficile mantenere buoni punteggi
• Integrato i dati di campo INP più prominentemente nel report Page Experience di Search Console, con avvisi granulari a livello di URL e cluster di pagine
• Iniziato a utilizzare segnali INP aggregati per differenziare siti con contenuti simili nelle SERP competitive, in particolare nel verticale e-commerce e nelle query informazionali ad alto volume

Cosa Significano Davvero le Soglie INP 2026 di Google

Il grafico riflette la distribuzione globale approssimativa tra i siti tracciati in CrUX al Q3 2026. Circa il 55% dei siti è ancora nella fascia “Da migliorare” — un dato che dovrebbe preoccupare chiunque operi nell’e-commerce o nei servizi, dove ogni millisecondo in più di latenza percepita costa conversioni misurabili. La soglia “Buono” (≤ 200 ms) non è un obiettivo teorico: è il livello minimo per non essere penalizzati nel confronto con i competitor che l’hanno già raggiunto.

Cosa conta come “interazione” per INP?

INP cattura tre tipi di interazione: clic, tocchi e pressioni di tasti. Il browser registra il ritardo tra l’evento fisico e la successiva pittura visiva del frame. Poi emerge la peggiore interazione nell’intera sessione dell’utente (con un piccolo buffer statistico per scartare i veri valori anomali). Questo è fondamentalmente diverso da FID, che catturava solo il ritardo sulla primissima interazione di una visita. INP è implacabile — osserva tutto, per tutta la sessione. Una singola interazione lenta — ad esempio, aprire un menu a discesa dopo 3 minuti di navigazione — può rovinare il punteggio complessivo di quella sessione.

Come Google aggrega i punteggi INP nei ranking

Google non usa il punteggio medio: usa il 75° percentile delle sessioni reali degli ultimi 28 giorni. Questo significa che anche se il 74% degli utenti sperimenta un INP eccellente, basta che il 25% peggiore sia sopra 200 ms perché l’intero URL venga classificato come “Da migliorare”. È un target deliberatamente alto — progettato per incentivare l’ottimizzazione su hardware reale, non su MacBook Pro in condizioni di rete ideali.

I Veri Colpevoli Dietro un Punteggio INP Scarso

Comprendere le cause alla radice è fondamentale, perché risolverle è raramente semplice come attivare un plugin di caching o comprimere immagini:

1. Long Task sul Thread Principale

Qualsiasi task JavaScript che superi i 50 ms è classificato come “long task”. Durante un long task, il browser non può elaborare l’input dell’utente — è bloccato. Plugin popolari come mega-menu, widget di live chat, piattaforme di gestione del consenso (CMP) e slider interattivi generano routinariamente long task di 200–800 ms su hardware mobile di fascia media. Su un Motorola G54 — il dispositivo di riferimento nei test CrUX — questi task si moltiplicano rispetto a quanto vedi nel tuo DevTools su un M-series Mac.

2. Script di Terze Parti che Bloccano il Rendering

Google Tag Manager, Meta Pixel, Hotjar, Intercom, Tidio, Klaviyo — ognuno singolarmente può sembrare innocuo. Insieme possono aggiungere 400–900 ms di blocco del thread principale dopo il caricamento della pagina, il che significa che ogni interazione nei primi secondi di una sessione compete direttamente con il loro codice di inizializzazione. Il paradosso: spesso gli strumenti di marketing che usi per acquisire traffico sono quelli che peggiorano la qualità dell’esperienza — e quindi il ranking — di quel traffico.

3. Alberi di Componenti React / Vue Non Ottimizzati

I moderni framework JavaScript sono potenti — finché non diventano un collo di bottiglia. Alberi di componenti profondamente annidati con aggiornamenti di stato sincroni causano cascate di re-render che bloccano il thread principale per centinaia di millisecondi per ogni clic. Questo è particolarmente diffuso nei siti WordPress che usano il Full Site Editing di Gutenberg con blocchi interattivi, nei negozi WooCommerce personalizzati, e in qualsiasi SPA che non adotta React 19 con le nuove primitive di concorrenza o Vue 3.5+ con la Vapor compilation.

4. Conflitti tra Plugin WordPress

Il sito WordPress medio nel 2026 ha 24–27 plugin attivi. Ognuno registra event listener, accoda script e a volte carica intere librerie UI. L’interazione tra plugin — non i singoli plugin isolati — è il killer silenzioso di INP che la maggior parte degli audit superficiali non riesce a identificare. Un classico esempio: un plugin di form che carica la libreria Datepicker globalmente su tutte le pagine, anche dove non c’è nessun form.

5. CSS Containment Mancante e Ricalcoli di Stile

Un problema meno discusso ma sempre più rilevante nel 2026: l’assenza di content-visibility e contain CSS causa ricalcoli di stile sull’intera pagina a ogni interazione. Su pagine lunghe con molti elementi — come le pagine prodotto WooCommerce o i feed di blog — questo aggiunge decine di millisecondi nascosti al punteggio INP che non appaiono immediatamente evidenti nel waterfall.

Perché l’Ottimizzazione INP Non È un Lavoro Fai-da-Te nel 2026

Il web è pieno di articoli che ti dicono di “differire gli script” e “rimuovere JavaScript inutilizzato.” Quei consigli erano a malapena sufficienti per LCP nel 2022. Per INP nel 2026, non spostano l’ago della bilancia — e a volte lo peggiorano, ritardando script critici e causando interazioni rotte nel primo secondo di sessione.

L’ottimizzazione INP reale richiede la profilazione delle sessioni con il pannello Performance di Chrome DevTools contro il throttling reale dell’hardware mobile (CPU 4x slowdown, rete Slow 4G), identificando quale specifica interazione genera quale long task, tracciando quel task fino allo script o componente di origine, e poi correggendolo chirurgicamente — che si tratti di suddividere un bundle, spezzare un event handler sincrono in microtask ceduti con scheduler.postTask(), o ristrutturare un componente React per differire gli aggiornamenti di stato non critici con useTransition.

Questo è lavoro di infrastruttura e ingegneria front-end specializzata. È il tipo di analisi approfondita che il nostro team esegue nell’ambito di un audit tecnico WordPress, dove portiamo alla luce non solo i punteggi INP aggregati ma le cause specifiche a livello di codice dietro ogni interazione lenta — con priorità per impatto e sforzo implementativo.

INP e E-Commerce: Il Legame Diretto con le Conversioni

Ecco il caso di business in numeri chiari. I dati aggregati del Web Almanac 2026 (HTTP Archive) mostrano che i siti che transitano da “Da migliorare” a “Buono” su INP registrano in media una riduzione del bounce rate del 12–18% sulle pagine prodotto mobile — e un aumento misurabile nelle interazioni add-to-cart, perché il pulsante si percepisce istantaneo. La latenza percepita è un freno psicologico all’acquisto: ogni esitazione visiva dopo un clic crea un micro-momento di dubbio che aumenta l’abbandono.

Per WooCommerce o negozi personalizzati, questo si traduce direttamente in fatturato. Un sito che genera €80.000/mese in e-commerce con una riduzione del bounce rate del 15% su mobile è un business strutturalmente diverso da quello del mese precedente. Non è una metafora — è un calcolo diretto che rende l’ingegneria della performance uno degli investimenti con il ROI più alto disponibili a un’azienda in crescita, spesso superiore all’incremento del budget advertising.

Il nostro servizio garantito di ottimizzazione PageSpeed mobile punta esattamente a questo risultato: portare i tuoi punteggi reali — INP incluso — nella fascia “Buono”, con dati CrUX verificati prima e dopo l’intervento, non solo metriche di laboratorio.

Cosa Richiede Davvero un Buon Punteggio INP nel 2026

Per ottenere costantemente un INP inferiore a 200 ms al 75° percentile degli utenti reali su mobile, un sito tipicamente necessita di:

1. Budget JavaScript applicati a livello di build — nessuna crescita incontrollata del bundle dopo aggiornamenti di plugin o temi; strumenti come Bundlewatch o Size Limit integrati nella CI/CD
2. Adozione della Scheduler API e di scheduler.postTask() — suddivisione dei long event handler in task ceduti così il browser può elaborare l’input tra un chunk e l’altro senza bloccare il rendering
3. Caricamento selettivo e ritardato di terze parti — caricare analytics, script di chat e widget di marketing solo dopo che il thread principale è inattivo (via requestIdleCallback), non al DOMContentLoaded
4. CSS containment con contain e content-visibility — prevenire ricalcoli di stile sull’intera pagina causati da una singola interazione su componenti isolati
5. Server-side rendering o idratazione parziale per i componenti interattivi — riducendo il lavoro client-side al primo engagement; pattern come islands architecture (Astro, Fresh) o React Server Components stanno diventando lo standard per i siti ad alte prestazioni
6. Audit periodico post-aggiornamento — le ottimizzazioni INP si degradano ad ogni aggiornamento significativo di plugin o tema; serve un processo di validazione continua, non un intervento una tantum

Nessuna di queste cose può essere implementata in sicurezza da un team non tecnico su un sito live in produzione. Richiedono revisione del codice, ambienti di staging, test di regressione funzionale e ri-validazione con dati CrUX reali. E devono essere mantenute nel tempo.

Se stai valutando se la tua attuale configurazione può realisticamente raggiungere questi risultati — o se stai considerando una ricostruzione su uno stack più orientato alla performance — i nostri case study mostrano esattamente cosa è possibile quando la performance viene trattata come priorità ingegneristica fin dal primo giorno, non come afterthought.

INP vs. LCP vs. CLS: Il Quadro Completo dei Core Web Vitals nel 2026

Per contestualizzare INP nel sistema più ampio, vale la pena ricordare come i tre Core Web Vitals si dividono il territorio della user experience:

• LCP (Largest Contentful Paint) — misura la velocità di caricamento del contenuto principale. Soglia “Buono”: ≤ 2,5 s. Problema principale: immagini non ottimizzate, TTFB lento, render-blocking resources.
• INP (Interaction to Next Paint) — misura la reattività a ogni interazione. Soglia “Buono”: ≤ 200 ms. Problema principale: long task JavaScript, script di terze parti, framework non ottimizzati.
• CLS (Cumulative Layout Shift) — misura la stabilità visiva. Soglia “Buono”: ≤ 0,1. Problema principale: immagini senza dimensioni, font swap, contenuti iniettati dinamicamente.

Nel 2026, INP è il più difficile da ottimizzare dei tre — e quello con il delta più ampio tra siti “gestiti” e siti “ingegnerizzati”. LCP e CLS sono migliorabili con configurazioni CDN e best practice di markup. INP richiede intervento sul codice.

Conclusione: INP È il Nuovo Standard Minimo per Competere

LCP ha definito la conversazione sulla performance dal 2020 al 2024. INP domina il 2025 e il 2026 — ed è misurabilmente più difficile da padroneggiare perché non si risolve con infrastruttura, ma con architettura del codice. I siti che vincono nella ricerca organica adesso non si caricano solo velocemente; rispondono velocemente, ad ogni clic, per ogni utente, su ogni dispositivo — inclusi quelli di fascia media che rappresentano la maggioranza del traffico mobile globale.

Il divario tra un sito architetturalmente ottimizzato per INP e uno che non lo è sta diventando visibile nei ranking tanto quanto il divario tra un sito ottimizzato per mobile e uno solo desktop era nel 2018. La domanda non è se affrontarlo — ma se farlo ora, prima che i concorrenti lo facciano, o dopo, quando il divario di ranking si sarà già accumulato e sarà molto più costoso da recuperare.