INP, cioè Interaction to Next Paint, è la metrica che misura quanto una pagina risponde davvero agli input dell’utente: click, tap e pressione dei tasti. Per chi lavora su SEO e performance, è uno dei segnali più utili dei Core Web Vitals perché traduce la sensazione di “sito reattivo” in un numero concreto, leggibile e migliorabile. Qui trovi una spiegazione pratica di come leggerlo, cosa lo peggiora e quali interventi fanno la differenza senza inseguire ottimizzazioni decorative.
Le idee chiave da tenere a mente subito
- INP misura la reattività percepita, non solo la velocità di caricamento.
- Un valore buono è 200 ms o meno, misurato sul 75° percentile dei caricamenti reali.
- Per capire un INP alto servono sia dati di campo sia test di laboratorio.
- Le cause più comuni sono JavaScript pesante, long task, layout costoso e callback troppo ricchi.
- Le correzioni utili riducono lavoro sul main thread e semplificano il rendering.
- INP aiuta UX e SEO, ma da solo non basta a salvare una pagina lenta o instabile.
Cos’è l’INP e perché conta nei Core Web Vitals
Io considero l’INP la metrica più onesta quando voglio capire se una pagina “si lascia usare” oppure no. A differenza di metriche che guardano soprattutto al caricamento iniziale, INP osserva la risposta dell’interfaccia durante tutta la visita e prende in considerazione le interazioni più significative. In pratica, conta quello che succede quando una persona apre un menu, filtra un elenco, invia un modulo o prova a chiudere un popup.
Il punto è importante anche per i motori di ricerca: un sito che si carica in fretta ma poi si inceppa al primo tocco offre comunque un’esperienza scadente. Per questo INP è entrato stabilmente nel gruppo dei Core Web Vitals, insieme a LCP e CLS. Se LCP misura la percezione di velocità e CLS la stabilità visiva, INP misura la reattività, cioè quanto la pagina riesce a reagire senza dare la sensazione di essere bloccata.
La differenza rispetto a FID è sostanziale. FID osservava il primo input, mentre INP guarda l’interazione peggiore tra quelle rilevanti nel corso della visita, con una logica più vicina alla realtà d’uso. È proprio qui che molte pagine mostrano il loro limite: non falliscono all’apertura, falliscono quando l’utente inizia davvero a interagire. E da qui si capisce anche perché misurarlo bene richiede un approccio più serio del semplice “sembra veloce”.
Il passaggio successivo è capire come leggere i numeri senza farsi ingannare da un singolo caso estremo o da una media troppo comoda.
Come leggere i valori senza farsi ingannare
Il modo corretto di interpretare INP non è “guardare un numero e sperare che sia basso”, ma leggere quel numero nel contesto giusto. Il riferimento pratico è il 75° percentile dei page load reali, separando mobile e desktop. Questo significa che non basta avere qualche sessione veloce: il sito deve risultare reattivo per la maggior parte degli utenti, non solo per i casi migliori.
| Valore INP | Lettura pratica | Cosa fare |
|---|---|---|
| ≤ 200 ms | Responsività buona | Mantenere il livello e verificare la stabilità su mobile e desktop |
| 201-500 ms | Serve miglioramento | Individuare l’interazione peggiore e alleggerire il main thread |
| > 500 ms | Problema serio di interattività | Ripartire dai dati di campo e ridurre lavoro JS, rendering e layout |
Il dettaglio che spesso viene dimenticato è questo: INP non fotografa la media delle interazioni, ma la peggiore esperienza rilevante. È un vantaggio, perché evita di mascherare i problemi; ma è anche una trappola, perché un solo template pesante può trascinare l’intero sito fuori soglia. Per questo io guardo sempre la metrica insieme alla tipologia di pagina, al device e al punto del funnel in cui compare il rallentamento.
Un’altra semplificazione sbagliata è pensare che tutte le interazioni contino allo stesso modo. INP considera click, tap e input da tastiera, ma non hover o scroll come segnali principali della metrica. Tradotto: se una pagina “scorre bene” ma si inceppa quando l’utente usa un filtro o conferma un’azione, il problema rimane eccome. Ed è proprio in quel passaggio che bisogna andare a misurare con metodo.
Per farlo bene, però, servono dati reali e non solo una prova locale. È qui che il quadro si fa più utile.
Come misurarlo tra dati reali e test locali
Se devo partire da una sola cosa, parto dai dati di campo. Il laboratorio è indispensabile per riprodurre e diagnosticare, ma è il traffico reale che mi dice dove l’esperienza si rompe davvero. Questo è particolarmente vero per INP, perché la metrica dipende da interazioni concrete, dal comportamento degli script e dalla complessità della pagina lungo tutta la visita.
| Strumento | Cosa ti dice | Limite principale |
|---|---|---|
| Search Console | Stato aggregato dei gruppi di URL e segnale di qualità in campo | Poco contesto sulla singola interazione che ha creato il problema |
| PageSpeed Insights e CrUX | Dati reali, p75, confronto tra mobile e desktop | Mostra bene il problema, meno bene la causa precisa |
| RUM | Contesto della sessione, interazione specifica, timing e percorso utente | Richiede implementazione e manutenzione |
| Lighthouse | Diagnosi di laboratorio ripetibile | Non sostituisce il comportamento reale degli utenti |
Io uso questa gerarchia in modo molto semplice: campo per scoprire dove sta il problema, laboratorio per capire perché succede. Se i dati reali segnalano un INP alto, il passo successivo è riprodurre l’interazione in un ambiente controllato, possibilmente con un device meno potente e non con il desktop ideale dell’ufficio. Spesso la differenza la fa proprio questo: il rallentamento non è “astratto”, ma legato a una sequenza di script, rendering o fetch che sul computer del team sembrano quasi innocui.
Quando il dato è chiaro, diventa più facile isolare le cause. E nella pratica le cause ricorrenti sono sorprendentemente sempre le stesse.
Cosa peggiora davvero la reattività
La prima fonte di problemi è quasi sempre il main thread, cioè il filo di esecuzione principale del browser. Se lì sopra si accumulano parsing, compilazione ed esecuzione di JavaScript, l’interfaccia resta in attesa. L’utente vede la pagina, ma non la sente pronta. Questo succede spesso all’avvio, quando il sito sembra caricato ma deve ancora diventare davvero interattivo.
Un altro problema classico è il callback troppo pesante. Se un click avvia una serie di operazioni non essenziali, il browser non riesce a presentare il nuovo frame in tempo utile. Succede con modali, filtri, carrelli, menu complessi e componenti che aggiornano troppi elementi insieme. Più il codice è “tutto in un colpo”, più la probabilità di un INP alto cresce.
- Long task in avvio: script voluminosi che bloccano la prima risposta utile.
- Callback eccessivi: eventi che fanno troppo lavoro prima del paint successivo.
- Layout e style costosi: il browser ricalcola troppo spesso posizione e stile degli elementi.
- DOM grande o poco razionale: più nodi da gestire, più tempo per renderizzare.
- Rendering client-side pesante: tanta HTML costruita in JavaScript proprio quando l’utente interagisce.
Ci sono poi casi meno intuitivi. Un iframe con codice lento può incidere sul punteggio della pagina principale; un flusso pieno di interazioni rapide può far emergere il peggior comportamento solo su alcune azioni; una pagina editoriale apparentemente semplice può rallentare per colpa di embed, analytics e script di terze parti. Per questo non mi accontento mai della prima lettura: guardo sempre quale interazione fa scattare il problema e in quale momento della visita succede.
Una volta capito cosa sta frenando la pagina, il lavoro utile è quasi sempre quello di togliere peso, non di rincorrere micro-ottimizzazioni marginali.
Come migliorarlo in modo concreto
Il modo più efficace per abbassare INP è ridurre il lavoro che compete con la risposta all’input. In pratica, io seguo una sequenza molto pragmatica: prima trovo l’interazione lenta, poi taglio tutto ciò che non deve accadere prima del paint successivo. Questo approccio rende i miglioramenti più visibili di qualsiasi intervento cosmetico sul front-end.
- Rendi più leggero il callback. Se il click attiva troppe operazioni, separa la parte essenziale da quella rinviabile. L’utente deve vedere subito la reazione dell’interfaccia.
- Spezza il lavoro in task più piccoli. Bloccare il main thread con un’unica sequenza lunga è uno dei modi più rapidi per peggiorare l’interattività.
- Rimanda ciò che non è critico. Analisi, logging, aggiornamenti secondari e calcoli non visibili possono spesso aspettare un attimo.
- Riduci il costo del rendering. DOM molto ampi, layout complessi e style recalculation frequenti fanno pagare pegno proprio nel momento dell’interazione.
- Valuta Web Worker per il lavoro pesante. Se una parte del calcolo non deve stare nel thread principale, spostarla fuori aiuta più di quanto sembri.
- Rivedi il rendering client-side. Se la pagina costruisce grandi blocchi HTML via JavaScript nel momento sbagliato, la reattività ne risente subito.
Qui c’è un principio che uso spesso nelle revisioni: se l’azione non serve per mostrare una risposta visibile immediata, non deve stare nello stesso pacchetto del click. È una regola semplice, ma nella pratica taglia una quantità sorprendente di ritardi.
Non tutte le ottimizzazioni, però, hanno lo stesso peso. Alcune danno benefici evidenti, altre migliorano il numero ma non il comportamento percepito. Il vero salto arriva quando si smette di trattare l’interattività come un problema secondario e si inizia a progettare la pagina in funzione della risposta agli input. Da qui nascono anche gli errori più comuni.
Gli errori che vedo più spesso nei progetti
Il primo errore è confondere INP con una metrica di caricamento. Se la pagina appare rapida ma poi si blocca al primo uso, il problema non è risolto: è solo spostato nel tempo. Il secondo è guardare solo il punteggio di laboratorio e ignorare i dati reali. Un sito può “passare” in un test sintetico e fallire nella vita vera, soprattutto quando gli utenti usano device più lenti, reti più instabili e percorsi più ricchi di interazioni.
Il terzo errore è ottimizzare solo la homepage. Nei siti editoriali, negli e-commerce e nelle web app il vero costo spesso si concentra su template secondari: ricerca interna, schede prodotto, filtri, area account, moduli e pagine con molti widget. Se lì l’interazione è lenta, il miglioramento percepito dall’utente è molto più forte che non su una landing già leggera.
Un quarto errore, molto diffuso, è trattare tutti i script come se avessero la stessa priorità. Non è così. Un’animazione, un tracker, un widget social o un modulo di assistenza possono sembrare innocui, ma se arrivano nel momento sbagliato competono con l’input e peggiorano l’esperienza. Io preferisco una regola brutale ma efficace: tutto ciò che non aiuta l’utente a completare l’azione principale deve stare più indietro possibile nella coda di esecuzione.
C’è anche un limite strutturale da tenere presente: non sempre si può scendere sotto soglia con una singola patch. A volte serve una revisione di architettura, soprattutto quando il front-end è cresciuto per stratificazioni successive. In quei casi il risultato migliore arriva lavorando per priorità, non per eroismo. E questo porta all’ultima lettura utile: come tenere insieme INP e il resto dell’esperienza.
Come leggere INP insieme agli altri Core Web Vitals
La lettura corretta non è mai “INP da solo”, ma INP dentro l’esperienza complessiva. Se LCP è buono ma INP è cattivo, la pagina si carica bene ma poi diventa goffa nell’uso. Se CLS è alto, l’utente può perfino cliccare nel punto sbagliato perché il layout cambia sotto gli occhi. Quando tutte e tre le metriche sono solide, il risultato si sente: la pagina non solo arriva, ma resta affidabile.
Per un sito editoriale come Mediaversi, io partirei dai template che combinano contenuti lunghi, embed, banner e componenti dinamici. Lì la reattività tende a degradarsi in modo più silenzioso che altrove. Per un e-commerce, invece, il focus va sui flussi più delicati: filtri, ricerca, scheda prodotto, carrello e checkout. Per una web app, spesso INP diventa la metrica dominante una volta superata la fase di caricamento.
La conclusione pratica è semplice: non inseguire un numero perfetto ovunque. Insegui la stabilità delle interazioni che contano davvero. Se una pagina editoriale si legge bene ma il menu, la ricerca o il modulo di contatto sono lenti, il problema non è marginale. È esattamente il tipo di frizione che fa percepire il sito come meno affidabile, meno fluido e, alla lunga, meno credibile. Io partirei sempre dal template che genera più interazioni, non da quello che riceve più attenzioni nel design: lì di solito si concentra il vero costo della reattività.
