Una pagina può comparire in fretta e restare perfettamente stabile, ma se al tocco di un pulsante non succede nulla per mezzo secondo l’esperienza è comunque frustrante. Il menu non si apre, il filtro non si applica, il prodotto non sembra aggiunto al carrello, e l’utente tocca di nuovo, o se ne va. L’Interaction to Next Paint, INP, è la metrica dei Core Web Vitals che misura proprio questo: quanto rapidamente la pagina risponde a ciò che l’utente fa.
Che cosa misura l’INP
L’INP misura il tempo che passa tra un’interazione dell’utente, cioè un clic, un tocco sullo schermo o la pressione di un tasto, e il momento in cui il browser disegna il fotogramma successivo, quello che mostra all’utente che qualcosa è successo. Non basta che il codice inizi a rispondere: conta quando la risposta diventa visibile.
Dal marzo 2024 l’INP ha sostituito il First Input Delay tra i Core Web Vitals. La differenza è sostanziale: il FID misurava solo il ritardo della prima interazione, mentre l’INP considera tutte le interazioni della visita e tutta la loro durata. Le soglie, al 75° percentile delle visite reali, sono queste: entro 200 millisecondi il risultato è buono, tra 200 e 500 è da migliorare, oltre 500 è scarso.
L’anatomia di un’interazione
Ogni interazione attraversa tre fasi, e ciascuna può essere responsabile di un INP alto:
- Ritardo dell’input: il tempo in cui l’interazione aspetta perché il thread principale del browser è occupato da altro, per esempio da uno script di terze parti.
- Elaborazione: il tempo necessario a eseguire il codice che risponde all’evento, cioè i gestori collegati al clic o al tasto.
- Presentazione: il tempo che il browser impiega a ricalcolare stili e layout e a disegnare il nuovo fotogramma.
Distinguere le tre fasi è fondamentale, perché i rimedi sono diversi. Un ritardo dell’input alto indica un thread principale sovraccarico da lavoro estraneo all’interazione; un’elaborazione lunga indica gestori degli eventi troppo pesanti; una presentazione lenta indica una pagina costosa da ridisegnare, spesso per un DOM molto grande o per modifiche che costringono il browser a ricalcolare il layout più volte.
Quale interazione diventa l’INP
Durante una visita l’utente interagisce molte volte, e il browser misura ciascuna interazione. L’INP della visita è la latenza di una delle peggiori: per la maggior parte delle pagine, con meno di cinquanta interazioni, coincide con la più lenta; per le pagine con moltissime interazioni, come applicazioni web o giochi, se ne ignora una ogni cinquanta, così che un singolo episodio isolato non determini il risultato. Lo scorrimento della pagina e il passaggio del mouse non sono interazioni conteggiate.
È una scelta deliberata: l’utente ricorda il pulsante che non ha risposto, non i dieci che hanno funzionato. Per migliorare l’INP bisogna quindi individuare le interazioni più lente, non limitarsi a rendere più veloci quelle già rapide.
Perché l’INP è una questione di business
Le interazioni lente arrivano nei momenti in cui l’utente sta facendo qualcosa di importante: scegliere una taglia, applicare un filtro, aggiungere un prodotto al carrello, compilare un modulo, aprire il menu per cercare una sezione. Una pagina che non risponde genera tocchi ripetuti, azioni duplicate, dubbi su che cosa sia successo, e alla fine abbandoni proprio nel percorso che porta alla conversione. È anche la metrica più legata alla percezione di qualità di un sito: una pagina lenta a rispondere sembra rotta, anche quando non lo è.
Le cause più comuni
- Task lunghi sul thread principale. Script che eseguono decine o centinaia di millisecondi di lavoro senza interruzioni bloccano qualsiasi interazione che arrivi nel frattempo.
- Script di terze parti. Tag di marketing, pixel pubblicitari, chat, strumenti di analisi e di test A/B aggiungono lavoro che spesso si concentra proprio quando l’utente inizia a interagire.
- Gestori degli eventi pesanti. Un clic che aggiorna molte parti della pagina, invia dati di tracciamento, ricalcola filtri e prezzi tutto insieme, prima di mostrare qualunque risposta.
- Pagine costose da ridisegnare. DOM con migliaia di elementi, fogli di stile complessi, letture e scritture del layout alternate che costringono il browser a ricalcolare più volte.
- JavaScript rinviato al primo clic. Tecniche che ritardano tutti gli script fino alla prima interazione concentrano il lavoro proprio in quel momento, come abbiamo spiegato parlando del delay al primo clic.
Come si migliora
Il principio guida è lasciare il thread principale libero di rispondere. Il primo strumento è spezzare i task lunghi in blocchi più piccoli, restituendo periodicamente il controllo al browser: il lavoro complessivo resta lo stesso, ma un’interazione può inserirsi tra un blocco e l’altro invece di attendere la fine di tutto.
Il secondo principio è mostrare subito una risposta e rinviare il resto. Nel gestore di un clic conviene aggiornare prima ciò che l’utente vede, come lo stato del pulsante o un indicatore di caricamento, e solo dopo eseguire il lavoro non urgente, come l’invio dei dati di tracciamento:
// Cede il controllo al browser, con ripiego dove scheduler.yield non esiste.
const cedi = () =>
globalThis.scheduler?.yield?.() ?? new Promise( ( r ) => setTimeout( r, 0 ) );
pulsante.addEventListener( 'click', async () => {
pulsante.classList.add( 'is-loading' ); // risposta visibile subito
await cedi(); // il browser disegna il fotogramma
aggiornaCarrello(); // lavoro necessario
await cedi();
inviaTracciamento(); // lavoro non urgente, per ultimo
} );- Ridurre il JavaScript caricato su ogni pagina, eliminando plugin e librerie inutili e caricando i componenti solo dove servono.
- Governare le terze parti: limitarne il numero, caricarle in modo non bloccante e verificarne il costo reale sulle interazioni.
- Contenere il DOM e la complessità degli stili, e usare
content-visibilityper le sezioni fuori dallo schermo. - Evitare i ricalcoli forzati del layout, raggruppando le letture delle dimensioni prima delle modifiche.
- Spostare il lavoro pesante fuori dal thread principale, in un web worker o sul server, quando non riguarda direttamente l’interfaccia.
Come si misura
L’INP è per sua natura una metrica di campo: richiede interazioni reali, e un test di laboratorio che si limita a caricare la pagina non ne compie. Per questo Lighthouse non riporta l’INP e usa il Total Blocking Time come indicatore indiretto del rischio. I valori reali si leggono in PageSpeed Insights e in Search Console dai dati di CrUX, ricordando che si aggiornano lungo una finestra di 28 giorni.
Per la diagnosi, il pannello Performance dei DevTools di Chrome mostra in tempo reale la latenza delle interazioni che compiamo sulla pagina, e permette di registrare una traccia per vedere che cosa occupa il thread principale in quel momento. Sul campo, la libreria web-vitals nella versione con attribuzione indica l’elemento, il tipo di interazione e la durata di ciascuna fase:
import { onINP } from 'web-vitals/attribution';
onINP( ( { value, attribution } ) => {
console.log( 'INP', Math.round( value ), 'ms', {
elemento: attribution.interactionTarget,
tipo: attribution.interactionType,
ritardoInput: attribution.inputDelay,
elaborazione: attribution.processingDuration,
presentazione: attribution.presentationDelay,
} );
} );Raccogliere questi dati dagli utenti reali, anche solo per un periodo limitato, è spesso il modo più rapido per scoprire quale pulsante o quale script è responsabile: le interazioni lente si concentrano quasi sempre su pochi elementi e poche pagine.
In sintesi
L’INP misura quanto tempo passa tra un’interazione dell’utente e il fotogramma che ne mostra l’effetto, su tutte le interazioni della visita, e riporta una delle peggiori. È buono entro 200 millisecondi al 75° percentile e si scompone in ritardo dell’input, elaborazione e presentazione. Le cause sono quasi sempre un thread principale sovraccarico, gestori degli eventi pesanti e pagine costose da ridisegnare.
Migliorarlo significa soprattutto fare meno lavoro, e farlo al momento giusto: meno JavaScript e meno terze parti, task spezzati, risposta visibile subito e lavoro non urgente rinviato. È l’ottimizzazione che si sente di più nell’uso quotidiano, perché riguarda il momento in cui l’utente chiede qualcosa al sito e si aspetta una risposta.
