Interaction to Next Paint, abbreviato INP, è il Core Web Vital che misura quanto rapidamente una pagina riesce a produrre una risposta visiva dopo le interazioni dell’utente.
In pratica, osserva cosa accade quando una persona fa clic, tocca lo schermo o usa la tastiera e misura il tempo che passa dall’inizio dell’interazione fino al momento in cui il browser può mostrare il frame successivo. Un valore INP pari o inferiore a 200 millisecondi è considerato buono; oltre 200 e fino a 500 ms la reattività è da migliorare; sopra 500 ms è considerata scarsa.
Per questo Interaction to Next Paint non va letto soltanto come un valore prestazionale, ma come il punto di partenza per individuare dove una pagina smette di rispondere rapidamente.
Il numero, però, è soltanto il punto di partenza. Se PageSpeed Insights segnala un INP elevato, sapere che la pagina impiega 350 o 600 millisecondi non dice ancora quale interazione sia lenta né dove venga consumato il tempo.
Per migliorare davvero questa metrica serve quindi un processo diagnostico:
dato reale → interazione problematica → fase lenta → causa tecnica → intervento → verifica.
È lo stesso principio che rende più utile lavorare sui Core Web Vitals come segnali dell’esperienza reale, invece di trattarli come semplici numeri da portare in verde.
Cos’è Interaction to Next Paint e cosa misura davvero
La documentazione ufficiale di web.dev sull’INP definisce Interaction to Next Paint come una metrica della reattività complessiva della pagina durante la visita.
Questa caratteristica la distingue dalle metriche che descrivono principalmente il caricamento. INP continua infatti a osservare la pagina anche dopo che il contenuto iniziale è apparso.
Supponiamo che un utente apra una pagina prodotto e, qualche secondo dopo, prema il pulsante per aprire un selettore di varianti. Se il browser rimane occupato prima di poter elaborare il clic, esegue un event handler molto costoso oppure impiega troppo tempo a ricalcolare e disegnare l’interfaccia, la risposta visiva viene ritardata.
È proprio quella latenza percepita che INP cerca di rappresentare.
Non misura invece necessariamente il completamento di tutto ciò che l’azione ha avviato. Se un clic genera una richiesta asincrona al server che termina diversi secondi dopo, INP non aspetta automaticamente l’intero processo: il suo riferimento è il momento in cui il browser può presentare il frame successivo conseguente all’interazione.
Quali interazioni entrano nell’INP e quali no
Per il calcolo di INP vengono osservate principalmente tre famiglie di input: clic del mouse, tap su touchscreen e pressione di tasti su tastiera fisica o virtuale.
Scroll, hover e zoom non vengono invece considerati direttamente ai fini di INP. Possono naturalmente accompagnarsi a gesti che generano eventi validi, ma non costituiscono di per sé le interazioni misurate dalla metrica.
Questo dettaglio è importante perché una pagina può sembrare poco fluida durante lo scorrimento e, allo stesso tempo, non avere necessariamente un problema INP. In quel caso occorre investigare il rendering e la fluidità con strumenti appropriati senza attribuire automaticamente il problema a questo Core Web Vital.
Come viene scelto il valore INP durante una visita
INP non fa la media delle interazioni.
Durante la visita vengono osservate le latenze delle interazioni qualificanti e il valore finale tende a rappresentare quella peggiore. Per le pagine con molte interazioni viene applicato un meccanismo che riduce l’influenza di outlier occasionali: web.dev specifica che viene ignorata un’interazione massima ogni 50 interazioni.
Questo spiega perché una singola interazione molto lenta può incidere parecchio sul risultato.
Spiega anche perché non conviene ottimizzare soltanto ciò che accade nei primi secondi di caricamento. Un menu, un filtro, un accordion, un pulsante “aggiungi al carrello” o un componente usato molto più tardi può diventare l’interazione che determina il valore finale.
Qual è un buon valore INP: 200 ms, 500 ms e 75° percentile
Quando si valuta l’esperienza reale, Google raccomanda di osservare il 75° percentile delle visite, separando mobile e desktop. Le soglie correnti sono queste.
| Valore INP | Valutazione |
|---|---|
| ≤ 200 ms | Buono |
| > 200 ms e ≤ 500 ms | Da migliorare |
| > 500 ms | Scarso |
Il riferimento al 75° percentile evita di giudicare il sito soltanto dal computer dello sviluppatore o da un singolo test eseguito in condizioni ideali.
Le soglie di Interaction to Next Paint vanno quindi interpretate sui dati reali e non sulla singola esecuzione di un test locale.
Se il tuo test locale mostra 90 ms non significa che gli utenti reali stiano necessariamente vivendo la stessa esperienza. Dispositivi meno potenti, pagine visitate in condizioni diverse, script di terze parti e comportamenti differenti possono produrre risultati molto diversi.
Allo stesso modo, un singolo test lento non dimostra da solo che il sito abbia un problema generalizzato.
INP e SEO: cosa Google conferma e cosa non possiamo dedurre
Qui conviene separare ciò che Google dichiara da ciò che spesso viene dedotto in modo troppo aggressivo.
GOOGLE_CONFIRMED: LCP, INP e CLS sono gli attuali Core Web Vitals. Google raccomanda buoni valori di queste metriche e spiega che i Core Web Vitals sono utilizzati dai propri ranking systems insieme ad altri aspetti della page experience.
GOOGLE_CONFIRMED: ottenere buoni Core Web Vitals non garantisce buone posizioni. La rilevanza e la qualità del contenuto restano fondamentali e la page experience non va trasformata in un singolo punteggio SEO.
NON CONFERMATO: non esiste una formula pubblica del tipo “ridurre INP di 100 millisecondi produce X posizioni in più”.
La conseguenza operativa è semplice: vale la pena migliorare INP perché una risposta lenta è un problema reale per chi utilizza il sito e perché la page experience è una componente considerata da Google. Non ha invece senso promettere un aumento di ranking direttamente proporzionale al numero di millisecondi recuperati.
INP vs FID: perché Google ha cambiato metrica
Interaction to Next Paint ha sostituito First Input Delay (FID) come Core Web Vital dedicato alla reattività il 12 marzo 2024. Google ha confermato ufficialmente il passaggio nel proprio annuncio sul cambiamento da FID a INP.
Il cambiamento non è soltanto nominale.
FID osservava il ritardo prima che il browser iniziasse a gestire la prima interazione dell’utente. Era quindi utile per valutare un particolare aspetto della responsiveness iniziale, ma non descriveva tutto ciò che accadeva durante l’utilizzo della pagina.
INP amplia il campo: considera le interazioni durante la visita e comprende non solo il ritardo iniziale, ma anche il tempo necessario a elaborare gli event handler e ad arrivare alla presentazione del frame successivo.
Per questo oggi un articolo o un audit che tratta ancora FID come Core Web Vital corrente va aggiornato.
Le tre parti dell’INP: dove nasce davvero il ritardo
La latenza di un’interazione può essere scomposta in tre parti:
input delay → processing duration → presentation delay.
Questa suddivisione è molto più utile del numero totale perché permette di capire dove intervenire.
Input delay: il browser non riesce ancora a iniziare
L’input delay è il tempo che passa tra l’azione dell’utente e l’inizio dell’esecuzione degli event handler associati.
Immagina di premere un pulsante mentre il main thread sta già eseguendo un task JavaScript molto lungo. Il clic è avvenuto, ma il browser deve terminare il lavoro che lo sta occupando prima di potersi dedicare al nuovo evento.
L’utente percepisce quindi che “non succede nulla”.
In questa fase il problema non è necessariamente il codice del pulsante stesso: l’interazione può essere rimasta in attesa a causa di altro lavoro già presente sul main thread.
Processing duration: il codice dell’interazione impiega troppo
Quando il browser può finalmente iniziare a gestire l’input, esegue gli event handler associati.
Se il callback compie troppo lavoro sincrono — elaborazioni JavaScript, manipolazioni del DOM, calcoli, logiche complesse o catene di funzioni costose — la processing duration cresce.
Un esempio frequente è un filtro che, dopo il clic, rielabora immediatamente centinaia di elementi prima di permettere al browser di aggiornare l’interfaccia.
Qui il problema non è più aspettare che inizi il lavoro: è il lavoro dell’interazione stessa che dura troppo.
Presentation delay: il nuovo frame arriva in ritardo
Terminati gli event handler, il browser deve ancora produrre il frame aggiornato.
Può dover ricalcolare stili, layout, rendering e paint. Un DOM molto grande, modifiche che generano molto lavoro di layout o sequenze inefficienti di letture e scritture possono aumentare questa fase.
Perciò un’interazione può avere JavaScript relativamente rapido e risultare comunque lenta perché il browser impiega troppo tempo a visualizzare il risultato.
La guida ufficiale all’ottimizzazione di INP indica proprio input delay, processing duration e presentation delay come aree da investigare separatamente.
Come misurare INP senza confondere dati reali e test di laboratorio
Una diagnosi affidabile parte da due domande diverse:
gli utenti reali stanno vivendo un problema?
e, soltanto dopo:
quale parte del sito lo sta causando?
La prima domanda richiede soprattutto field data. La seconda richiede strumenti diagnostici e riproduzione controllata.
Per misurare correttamente Interaction to Next Paint bisogna distinguere ciò che accade agli utenti reali da ciò che possiamo riprodurre in laboratorio.
PageSpeed Insights e CrUX: cosa stanno vivendo gli utenti reali
PageSpeed Insights può mostrare i dati del Chrome User Experience Report, cioè esperienze raccolte da utenti reali idonei a contribuire a CrUX.
La documentazione corrente specifica che PageSpeed Insights riporta dati aggregati relativi agli ultimi 28 giorni, a livello di singola pagina quando sono disponibili campioni sufficienti e a livello di origin dove necessario.
Questo punto cambia il modo di interpretare il risultato.
Se oggi correggi un problema JavaScript e il test locale migliora immediatamente, non devi aspettarti che il valore CrUX si trasformi nello stesso istante. La finestra comprende ancora visite avvenute prima dell’intervento.
Soprattutto, CrUX può aiutarti a capire se esiste un problema, ma non identifica automaticamente quale pulsante, menu o componente abbia prodotto l’interazione lenta. web.dev sottolinea esplicitamente questa limitazione.
Search Console: quando serve una vista aggregata del problema
Il report Core Web Vitals di Search Console è utile per capire se gruppi di URL mostrano problemi relativi a LCP, INP o CLS e per osservare la situazione a scala di sito. Google raggruppa gli URL in base allo stato, alla metrica e a gruppi di pagine simili.
È uno strumento di prioritizzazione, non un profiler JavaScript.
Se Search Console mostra un gruppo di pagine con INP problematico, il passo successivo non è modificare tutte le pagine alla cieca. Conviene individuare pattern comuni — template, componenti, script, banner, menu o funzionalità — e poi riprodurre le interazioni interessate.
Chrome DevTools: riprodurre e isolare l’interazione lenta
Quando hai un indizio sul problema reale, il Performance panel di Chrome DevTools diventa molto più utile.
Puoi registrare una sessione, riprodurre un’interazione e osservare il lavoro eseguito dal main thread: task lunghi, event handler, scripting, rendering e layout.
La guida ufficiale alla misurazione dei Web Vitals raccomanda proprio di combinare field data e strumenti di laboratorio, invece di scegliere uno dei due mondi.
Il vantaggio del laboratorio è la ripetibilità. Puoi eseguire la stessa interazione, modificare il codice e verificare se la causa individuata si riduce.
TBT può aiutare nella diagnosi, ma non sostituisce INP
Nei normali audit di caricamento, Google Lighthouse non osserva una vera sessione utente composta da tutte le interazioni della visita.
Per questo Total Blocking Time (TBT) è spesso utilizzato come proxy di laboratorio per individuare un main thread eccessivamente occupato durante il caricamento.
TBT e INP, però, non sono la stessa metrica.
Un TBT elevato può indicare condizioni che rendono probabili interazioni lente, mentre un buon TBT non dimostra che ogni componente interattivo della pagina risponderà rapidamente durante l’intera sessione. web.dev precisa espressamente che TBT può essere un proxy utile, ma non sostituisce INP.
Può anche capitare di non vedere alcun valore INP. Se durante le visite disponibili non avvengono abbastanza clic, tap o input da tastiera — oppure gli utenti compiono soltanto interazioni non misurate come scroll e hover — la metrica può non essere disponibile.
Come trovare la causa di un INP alto
Una volta stabilito che esiste un problema reale, la domanda utile non è “quale plugin migliora INP?”, ma “quale interazione è lenta e cosa sta facendo il browser in quel momento?”
Quando Interaction to Next Paint supera le soglie consigliate, il valore aggregato deve essere trasformato in una diagnosi dell’interazione concreta.
Long task e JavaScript che occupano il main thread
I long task sono una delle prime cose da cercare.
Se il main thread è impegnato quando arriva l’input, l’event handler deve attendere. Questo aumenta l’input delay anche se il codice dell’interazione, preso da solo, è veloce.
Il problema può derivare dal JavaScript proprietario della pagina, da librerie, inizializzazioni, rendering lato client o script di terze parti.
La correzione non consiste necessariamente nell’eliminare tutto JavaScript. L’obiettivo è evitare grandi blocchi di lavoro sincrono che impediscono al browser di tornare disponibile abbastanza spesso.
Event handler troppo pesanti e lavoro non critico prima del paint
Se il collo di bottiglia si trova nella processing duration, devi analizzare ciò che l’event handler esegue.
Una pratica utile è separare il lavoro indispensabile per fornire subito un feedback visivo dal lavoro che può essere rinviato.
Se un clic deve aprire un pannello e contemporaneamente aggiornare analytics, ricalcolare dati, modificare molte parti del DOM e avviare altre attività, non tutto deve necessariamente precedere il primo frame utile.
Mostrare rapidamente lo stato richiesto dall’utente e distribuire il lavoro non critico in task successivi può ridurre sensibilmente la latenza percepita.
Layout thrashing, DOM grande e rendering costoso
Un’altra classe di problemi emerge dopo l’esecuzione del JavaScript.
Modifiche ripetute del DOM, letture e scritture che obbligano il browser a ricalcolare continuamente il layout, oppure l’aggiornamento di grandi quantità di HTML possono rendere costosa la fase di rendering.
La guida web.dev segnala anche la dimensione del DOM e il rendering lato client di grandi quantità di contenuto come fattori da considerare quando la presentation delay è elevata.
Qui ridurre di qualche kilobyte un file JavaScript potrebbe non risolvere il problema principale. Serve capire quanto lavoro viene generato dopo l’interazione.
Script di terze parti e iframe: quando il collo di bottiglia è esterno
Consent manager, sistemi di tracking, widget, chat, player video, advertising e altre integrazioni possono aggiungere lavoro al main thread.
Inoltre, le interazioni che avvengono all’interno di iframe possono contribuire all’esperienza misurata da CrUX, mentre il JavaScript della pagina principale non sempre ha visibilità completa su ciò che avviene all’interno di iframe cross-origin. web.dev segnala esplicitamente questa possibile differenza tra CrUX e misurazioni RUM eseguite dalla pagina.
Quando i dati reali e la strumentazione interna sembrano quindi raccontare storie leggermente diverse, la presenza di contenuti embedded è una delle condizioni da verificare.
Come migliorare Interaction to Next Paint in base alla causa
Non esiste un intervento universale. La correzione più efficace dipende dalla fase nella quale viene consumato il tempo.
Ridurre l’input delay spezzando il lavoro lungo
Se il browser è spesso occupato prima dell’inizio degli event handler, l’obiettivo è liberare più frequentemente il main thread.
Significa ridurre il lavoro sincrono non necessario, suddividere task molto lunghi in unità più piccole e rimandare attività non urgenti quando è possibile.
Questo permette al browser di inserire più facilmente una nuova interazione tra un’attività e l’altra.
Ridurre il processing alleggerendo gli event callback
Se il problema è dentro l’handler, devi diminuire ciò che deve essere completato prima del frame successivo.
Non ogni elaborazione richiesta da un clic deve avvenire nello stesso task. Il feedback visivo immediato spesso ha una priorità maggiore rispetto ad aggiornamenti secondari che l’utente non deve vedere istantaneamente.
La regola pratica è: prima esegui ciò che rende percepibile la risposta, poi distribuisci il lavoro non critico quando l’architettura lo consente.
Ridurre il presentation delay intervenendo su DOM, layout e rendering
Se scripting e callback sono relativamente brevi ma il frame arriva comunque tardi, guarda il costo di rendering.
DOM eccessivamente ampi, aggiornamenti massivi, layout forzati e componenti che ricostruiscono grandi porzioni della pagina possono essere più importanti del peso assoluto dei file.
In alcuni scenari anche tecniche come content-visibility, indicate dalla guida web.dev, possono limitare il lavoro di rendering per contenuti fuori schermo. Non è però una soluzione da applicare automaticamente: va verificato che intervenga effettivamente sulla fase problematica.
Mostrare prima il feedback visivo e rimandare il lavoro non critico
Questa è una delle idee più importanti dell’intera ottimizzazione.
Un’interazione complessa può richiedere operazioni che non possono essere eliminate. In quel caso la priorità diventa evitare che tutto debba concludersi prima di mostrare qualunque risposta.
Se l’utente apre un menu, seleziona una variante o avvia un’azione, una modifica visiva immediata comunica che il comando è stato ricevuto. Le elaborazioni successive possono continuare dopo il primo frame quando la logica dell’applicazione lo permette.
INP premia proprio la capacità di arrivare rapidamente alla risposta visiva successiva.
Come migliorare INP su WordPress senza affidarsi a un plugin “magico”
Su WordPress il metodo non cambia: prima individui l’interazione, poi la causa. Anche su WordPress, migliorare Interaction to Next Paint significa individuare quale componente occupa il main thread o ritarda il frame successivo.
Installare indiscriminatamente un plugin di performance può migliorare alcuni aspetti del caricamento senza modificare l’event handler che sta realmente causando la lentezza.
Tema, builder e plugin: trovare chi genera il task lento
Temi, page builder e plugin possono aggiungere JavaScript, componenti dinamici e listener agli eventi.
Il punto non è stabilire a priori che “il plugin X rallenta INP”, ma registrare l’interazione lenta e verificare quali script vengono eseguiti.
Se un menu mobile risponde tardi, analizza quell’interazione. Se il problema avviene aprendo un filtro WooCommerce, concentra il profiling sul filtro. Se compare dopo l’apertura di un popup, guarda ciò che viene eseguito in quella fase.
La diagnosi per componente evita di rimuovere o sostituire strumenti che non hanno alcuna relazione con il problema.
Tracking, CMP, chat e altri script di terze parti
WordPress viene spesso usato come punto di integrazione di molti servizi esterni.
Il loro costo può sommarsi soprattutto durante il caricamento, quando il main thread è già impegnato. Un input eseguito in quel momento può restare bloccato in attesa.
Per questo vale la pena controllare non solo quanto pesa uno script in rete, ma quanto lavoro genera sul main thread e quando lo esegue.
Cache e delay JavaScript: quando possono aiutare e quando non risolvono INP
Caching, ottimizzazione del caricamento e differimento di script possono essere utili se riducono il lavoro che compete con le prime interazioni.
Ma non correggono automaticamente un callback inefficiente.
Se un pulsante avvia 300 ms di JavaScript ogni volta che viene premuto, una cache HTML non rende quel callback magicamente più leggero.
Anche il ritardo degli script va usato con criterio. Posticipare codice non essenziale può liberare il caricamento iniziale; posticipare invece proprio il codice necessario al primo clic può spostare il costo nel momento peggiore e rendere quella prima interazione più lenta.
L’obiettivo rimane quindi ridurre il lavoro che blocca l’interazione, non applicare un’impostazione di performance senza verificarne l’effetto.
Nel 2026 è emersa una novità importante per le Single Page Application.
Con Chrome 151 sono state introdotte nuove API che permettono di misurare i Core Web Vitals anche attraverso le soft navigation, cioè transizioni di route che aggiornano URL e contenuto senza un caricamento completo della pagina.
Le API indicate da web.dev sono PerformanceSoftNavigation e InteractionContentfulPaint. La prima consente di identificare una soft navigation e di separare la timeline in navigazioni distinte, permettendo tra l’altro di misurare INP e CLS per ciascuna navigazione.
Ad agosto 2026, però, l’adozione è ancora in corso.
La FAQ aggiornata di web.dev sulle SPA e i Core Web Vitals precisa che queste API stanno iniziando a essere integrate in web-vitals, soluzioni RUM e Chrome DevTools, mentre Chrome non ha ancora pubblicato una tempistica per l’integrazione completa in CrUX. Gli altri browser engine, inoltre, non supportano ancora le nuove API.
Per chi gestisce una SPA la conseguenza è importante: le misurazioni per route diventano tecnicamente più accessibili, ma non bisogna ancora assumere che tutti i report aggregati e tutti i browser stiano già trattando le soft navigation nello stesso modo.
Come verificare che l’ottimizzazione abbia davvero funzionato
La verifica deve avvenire su due tempi differenti.
Verifica immediata in DevTools
Dopo una modifica puoi riprodurre subito la stessa interazione nel Performance panel.
L’obiettivo è controllare se:
- il task che bloccava il main thread è diminuito;
- l’event handler è diventato più breve;
- il rendering richiede meno lavoro;
- il frame successivo arriva prima.
Questa verifica è utile perché collega direttamente la modifica tecnica alla causa che avevi individuato.
Conferma successiva con RUM, CrUX e dati real-user
Il laboratorio, però, dimostra soltanto che hai migliorato lo scenario riprodotto.
La conferma definitiva deve arrivare dagli utenti reali.
Un sistema RUM proprietario o di terze parti può offrire informazioni molto più granulari e più rapide sulle interazioni. PageSpeed Insights, Search Console e le altre superfici basate su CrUX permettono invece di controllare l’evoluzione aggregata della metrica nel tempo. Google raccomanda esplicitamente di integrare i dati CrUX con RUM quando serve una diagnosi più dettagliata.
Il workflow completo diventa quindi:
field data rilevano il problema → laboratorio individua la causa → modifica tecnica → laboratorio verifica → field data confermano.
Gli errori che portano a ottimizzare INP nel modo sbagliato
Il primo errore è inseguire PageSpeed 100. Il Performance Score Lighthouse non coincide con INP degli utenti reali e non è un punteggio SEO.
Il secondo è utilizzare un singolo test di laboratorio come prova dell’esperienza reale. Un test serve per diagnosticare e confrontare; la distribuzione degli utenti reali risponde a una domanda differente.
Il terzo è correggere qualunque problema di caricamento sperando che migliori automaticamente la reattività. Alcune ottimizzazioni possono avere effetti indiretti positivi, ma se la causa è un event handler costoso devi intervenire sull’event handler.
Il quarto è trattare TBT come se fosse INP. Le due metriche possono condividere alcune cause legate a un main thread occupato, ma misurano cose differenti.
Il quinto è ignorare l’interazione concreta. Un valore aggregato segnala che esiste un problema; per risolverlo devi arrivare il più possibile al componente, al gesto e alla fase che generano la latenza.
Infine, non bisogna trasformare un buon Core Web Vital in una promessa di ranking. Google raccomanda buoni Core Web Vitals, ma chiarisce che da soli non garantiscono buone posizioni.
Conclusione
Interaction to Next Paint è utile perché sposta l’attenzione dalla semplice velocità di caricamento alla reattività durante l’utilizzo reale della pagina.
Ma un INP alto non è ancora una diagnosi.
Il percorso corretto è:
misura → identifica l’interazione → individua la fase lenta → correggi la causa → verifica in laboratorio → conferma sui dati reali.
Se il problema nasce prima dell’event handler, libera il main thread. Se è il callback a essere troppo costoso, riduci o distribuisci il lavoro. Se il ritardo arriva dal rendering, analizza DOM, layout e aggiornamenti dell’interfaccia.
Su WordPress vale la stessa regola: tema, builder, plugin, script di terze parti, cache e ottimizzazioni JavaScript vanno valutati in relazione alla causa effettivamente osservata, non come soluzioni universali. Migliorare Interaction to Next Paint significa quindi intervenire sulla causa della latenza, non cercare semplicemente di far diminuire un numero.
Quando il problema di INP fa parte di criticità più ampie di performance, struttura o UX, il passo successivo può essere un’analisi più completa dell’ottimizzazione del sito web, mantenendo sempre la stessa logica: prima la causa, poi l’intervento.