INP nel 2026: Il Core Web Vital che Sta Silenziosamente Penalizzando il Tuo Sito

Google ha sostituito il First Input Delay (FID) con Interaction to Next Paint (INP) nel marzo 2024. Sono passati più di due anni. Eppure, ad agosto 2026, i dati field di CrUX mostrano costantemente che oltre il 40% dei siti web ottiene ancora un punteggio “da migliorare” o “scarso” su INP — rendendolo di gran lunga il segnale più trascurato della suite Core Web Vitals.

In sintesi: INP misura la rapidità con cui l’intera pagina risponde a ogni interazione dell’utente — clic, tocchi, input da tastiera — non solo alla prima. Un punteggio INP scarso (oltre 500 ms) penalizza direttamente il tuo posizionamento su Google e allontana gli utenti. La maggior parte dei siti lo sta fallendo senza saperlo, e la correzione è quasi mai semplice.

Cosa Misura Davvero INP (e Perché FID Era Più Facile da “Superare”)

First Input Delay misurava solo il ritardo prima che il browser iniziasse a elaborare la prima interazione. Ignorava tutto ciò che veniva dopo — rendering, layout, paint. Una pagina poteva sembrare visivamente lenta e ottenere comunque un ottimo FID.

INP è molto più severo. Cattura la latenza completa di ogni interazione durante l’intera sessione di pagina — dal momento in cui l’utente clicca un pulsante al momento in cui il browser si aggiorna visivamente in risposta. La peggiore interazione dell’intera visita determina il punteggio INP. Non c’è modo di nascondersi.

• Buono: ≤ 200 ms
• Da migliorare: 201–500 ms
• Scarso: > 500 ms

Pensa a un sito WordPress con un carrello fluttuante, un mega-menu animato, un widget di ricerca live e un gestore di consenso cookie — il tutto sovrapposto a un tema con 400 KB di JavaScript non ottimizzato. Ognuno di questi elementi contribuisce alla latenza INP su ogni interazione. Un utente che tocca “Aggiungi al carrello” o filtra un elenco prodotti sta aspettando centinaia di millisecondi in più del necessario, in silenzio.

Perché INP È Ancora il Vital Più Trascurato nel 2026

LCP ha ricevuto tutta l’attenzione nel 2024 e nel 2025 perché è visivo, drammatico e relativamente facile da diagnosticare. INP è più difficile: è causato dalla congestione del main thread, da long task JavaScript, da DOM eccessivamente grandi e da colli di bottiglia di rendering che si sommano a ogni interazione — non solo al caricamento della pagina.

Il risultato? Le agenzie hanno ottimizzato LCP e CLS, si sono dichiarate soddisfatte e sono andate avanti. Nel frattempo INP ha continuato a fallire silenziosamente, specialmente su:

1. Siti WordPress ricchi di funzionalità — page builder, WooCommerce, stack di plugin
2. SPA React/Next.js con hydration client-side pesante
3. Landing page di marketing cariche di script di tracciamento e strumenti di A/B testing
4. Siti news e media con reti pubblicitarie che iniettano JS di terze parti a runtime

Il Vero Costo di Business di un INP Scarso

La performance non è una metrica di vanità per sviluppatori. Google ha confermato che INP è un fattore di ranking su tutti i dispositivi e verticali di ricerca. Ma l’impatto sulle conversioni è la storia più acuta:

“Ogni aumento di 100 ms nella latenza di interazione riduce i tassi di conversione e-commerce dell’1–3%. Con un INP di 500 ms o più, stai compounding questa penalità su ogni singola azione dell’utente.” — Sintesi della ricerca del Web Performance Working Group, Q1 2026

Su un sito che genera €50.000/mese di fatturato, un punteggio INP costantemente scarso può costare silenziosamente €500–€1.500 in conversioni perse ogni mese — senza nemmeno considerare il calo nei ranking organici.

I brand che capiscono questo trattano INP come una voce di ricavo, non come una casella tecnica da spuntare. Puoi vedere come questo approccio si traduce in risultati concreti nei nostri case study Totaliweb, dove i miglioramenti di performance hanno generato aumenti misurabili di fatturato per i clienti.

Cosa Causa un INP Scarso: La Realtà Tecnica

I fallimenti INP quasi mai hanno un’unica causa. Sono sistemici. I colpevoli più comuni nel 2026 sono:

1. Long Task sul Main Thread

Qualsiasi task JavaScript che blocca il main thread per più di 50 ms ritarda la capacità del browser di rispondere agli input. Le installazioni WordPress cariche di plugin generano regolarmente task di 200–600 ms durante il caricamento della pagina e durante le interazioni dell’utente. Il browser è semplicemente troppo occupato per eseguire il paint.

2. Event Handler Non Ottimizzati

Listener di eventi sincroni e inefficienti — specialmente su scroll, resize e input — causano picchi imprevedibili di latenza di interazione. I framework moderni aiutano quando usati correttamente, ma la maggior parte dei siti in produzione accumula anni di debito tecnico nel proprio JS.

3. DOM Eccessivamente Grande

Google raccomanda meno di 1.400 nodi DOM. Le pagine costruite con builder visivi superano regolarmente i 3.000–5.000 nodi. Ogni interazione obbliga il browser a ricalcolare il layout su migliaia di elementi.

4. Script di Terze Parti

Analytics, widget di chat, script pubblicitari e gestori di consenso — ognuno compete per il main thread. Uno stack di sei script di terze parti può aggiungere da solo 150–300 ms di latenza di interazione.

INP e WordPress: Un Rapporto Particolarmente Complicato

WordPress alimenta circa il 43% del web nel 2026, e il suo ecosistema di plugin è il motivo principale per cui INP è un problema così diffuso. La sfida è architettonica: la maggior parte dei plugin di performance WordPress è stata costruita in un’era in cui l’unica metrica che contava era il tempo di caricamento. Ottimizzano gli asset in entrata — minificando CSS, caricando le immagini in lazy — ma fanno poco riguardo a ciò che accade quando un utente inizia effettivamente a usare la pagina.

WooCommerce merita una menzione speciale. Le interazioni con il carrello, i selettori di varianti, gli input di quantità e i form di checkout sono tutti ad alta frequenza di interazione. Una pagina prodotto con INP scarso sta attivamente perdendo clienti nel momento di massima intenzione di acquisto.

Risolvere INP in un ambiente WordPress significa tipicamente fare un audit completo dell’albero delle dipendenze JavaScript, identificare quali plugin registrano event handler sincroni, valutare la complessità del DOM per ogni template e spesso sostituire o ridurre chirurgicamente i plugin che non possono essere corretti. Non è un lavoro da impostazioni — è ingegneria di performance esperta. Il nostro servizio garantito di PageSpeed mobile è progettato specificamente per affrontare esattamente questo tipo di debito tecnico profondo.

INP su Stack Custom e Headless: Non Sono Immuni

I team migrati a React, Next.js o architetture headless a volte hanno assunto di essersi liberati da questi problemi. I dati raccontano una storia diversa. Il rendering concorrente di React e il Next.js App Router hanno migliorato significativamente la situazione, ma l’overhead di hydration — il processo di collegamento del JavaScript all’HTML renderizzato lato server — crea una finestra in cui la pagina sembra interattiva ma non lo è, generando esattamente il tipo di ritardo di interazione che INP cattura.

Le architetture a isole e le strategie di hydration parziale (rese popolari da Astro, Qwik e ora sempre più adottate nei progetti Next.js) sono le risposte architetturali più efficaci. Combinate con il code splitting per route e il caricamento differito degli script di terze parti, gli stack custom leggeri possono raggiungere punteggi INP comodamente sotto i 100 ms. Il nostro servizio di sviluppo custom punta a punteggi Lighthouse 99–100 e raggiunge regolarmente INP sub-100 ms trattando la reattività alle interazioni come un vincolo di design fondamentale fin dal primo giorno.

Come Sapere Se INP Ti Sta Penalizzando Adesso

Non devi indovinare. I dati field sono pubblici. Vai allo strumento PageSpeed Insights, inserisci il tuo URL e scorri oltre i punteggi lab alla sezione Dati sul campo. Se il tuo INP mostra giallo o rosso, Google ha già registrato il problema contro il tuo dominio — e lo ha fatto anche nel tuo ranking.

Per un’analisi più approfondita, il dashboard Chrome UX Report (CrUX) in Google Search Console ora mostra INP a livello di singola pagina, non solo per origine. Questo significa che puoi identificare esattamente quali template di pagina — schede prodotto, archivi blog, flussi di checkout — stanno trascinando verso il basso il punteggio aggregato del tuo sito.

Il Modo Giusto per Correggere INP (Senza Rompere Tutto)

L’ottimizzazione INP è fondamentalmente un problema di codice e architettura, non di configurazione. Il flusso di lavoro tipico di remediation prevede:

• Profilazione completa delle interazioni su dati field di dispositivi reali (CrUX + strumenti RUM)
• Attribuzione dei long task — identificare esattamente quali script possiedono il tempo di blocco
• Audit e refactoring asincrono degli event handler dove applicabile
• Riduzione della complessità DOM (spesso richiede interventi su tema o template)
• Deferral, sandboxing o sostituzione degli script di terze parti
• Adozione dello Scheduler API e di `requestIdleCallback` per lavoro non critico differito
• Monitoraggio delle regressioni per evitare che futuri aggiornamenti di plugin o tema reintroducano i problemi

È un lavoro multidisciplinare: si trova all’intersezione tra ingegneria di performance, architettura JavaScript ed esperienza con il CMS. Sbagliare — differendo gli script sbagliati o rimuovendo funzionalità necessarie — può rompere funzionalità core del sito. Farlo bene è ciò che distingue un vero partner di performance da un passaggio di ottimizzazione tramite tool e impostazioni.

Se il tuo sito ha un punteggio INP giallo o rosso e vuoi sapere esattamente cosa lo causa — e cosa ci vorrebbe per raggiungere il verde — un audit tecnico WordPress è il punto di partenza logico. Porta alla luce il quadro completo prima che venga cambiata una singola riga di codice.