Un buon punteggio INP è di 200 millisecondi o meno, misurato al 75° percentile delle visite reali. Tra 200 e 500 ms la pagina “necessita di miglioramenti”, e oltre i 500 ms è considerata scadente. Google applica queste soglie separatamente a mobile e desktop, quindi una pagina può superarle su un dispositivo e non sull’altro.
Interaction to Next Paint (INP) misura la rapidità con cui una pagina risponde visivamente dopo che qualcuno clicca, tocca o preme un tasto. È diventato un Core Web Vital il 12 marzo 2024, sostituendo First Input Delay (FID), che misurava solo il ritardo prima della gestione della prima interazione. INP considera le interazioni nell’intera visita e riporta una delle più lente.
In pratica, “buono” significa tre cose: almeno il 75% delle visite reali riceve una risposta entro 200 ms, stai misurando con dati sul campo e non con un singolo test di laboratorio, e hai un certo margine sotto la soglia, così che un nuovo script o una settimana di saldi intensa non ti facciano superare il limite.
Questa guida spiega come viene calcolato il punteggio, dove trovare il tuo, perché alcuni strumenti non mostrano nulla e come diagnosticare e correggere un INP lento senza andare a tentativi.
Quali sono le soglie INP?
Google usa tre fasce, e i valori limite contano. La tabella seguente riflette la documentazione INP di web.dev e il report Core Web Vitals di Search Console.
| Valutazione | Valore INP | Cosa significa per gli utenti |
|---|---|---|
| Buono | 200 ms o meno | Clic e tocchi sembrano immediati nella maggior parte delle visite |
| Da migliorare | Oltre 200 ms, fino a 500 ms | Ritardo percepibile su menu, filtri, moduli o aggiunta al carrello |
| Scadente | Oltre 500 ms | Gli utenti ripetono i clic, pensano che la pagina non funzioni o se ne vanno |
Esattamente 200 ms è buono? Sì. web.dev definisce buono un valore “inferiore o uguale” a 200 ms, quindi 200 supera la soglia e 201 no. La stessa logica vale a 500 ms: esattamente 500 resta “da migliorare”, e tutto ciò che lo supera è scadente.
Per confronto, gli altri due Core Web Vitals in Search Console usano soglie LCP di 2,5 s e 4 s e soglie CLS di 0,1 e 0,25. INP è l’unico misurato in millisecondi di reattività anziché in termini di caricamento o stabilità visiva.
Come viene calcolato davvero il tuo punteggio INP?
INP viene calcolato prima per singola visita, poi riassunto su tutte le visite al 75° percentile. Capire entrambi i passaggi chiarisce gran parte della confusione intorno a questo numero.
Durante una visita, il browser misura ogni clic, tocco e pressione di tasto. Ogni interazione ha tre parti:
- Input delay: l’attesa prima che partano i tuoi gestori di eventi, di solito perché il thread principale è occupato con altro lavoro.
- Processing duration: il tempo di esecuzione dei tuoi gestori di eventi.
- Presentation delay: il tempo che passa dalla fine dei gestori al momento in cui il browser disegna il frame successivo.
L’INP della visita è la più lunga di queste interazioni, con un’eccezione per le pagine molto usate: web.dev specifica che viene ignorata l’interazione più lenta ogni 50 interazioni, così un singolo picco anomalo in una sessione lunga non determina il punteggio. Passaggio del mouse, scorrimento e zoom non contano come interazioni.
Poi i valori di tutte le visite vengono messi insieme e viene riportato il 75° percentile. È la “regola del 75%”: la tua pagina è buona se almeno tre visite su quattro hanno avuto un INP di 200 ms o meno. Il restante quarto può essere più lento senza far fallire la pagina, ed è per questo che correggere la tua interazione lenta tipica conta più che inseguire un raro caso limite.
Una visita in cui l’utente non clicca, non tocca e non digita non produce alcun valore INP. Le pagine che le persone soprattutto leggono, come gli articoli lunghi, hanno spesso meno dati INP di quelle con cui interagiscono, come i filtri di categoria o il checkout.
Un buon punteggio INP è diverso su mobile e desktop?
La soglia è la stessa, 200 ms, ma i risultati sono molto diversi. I telefoni hanno processori più lenti, quindi lo stesso JavaScript impiega più tempo a essere eseguito, e Google riporta mobile e desktop separatamente sia in PageSpeed Insights sia in Search Console.
Il capitolo sulle prestazioni del Web Almanac 2024 di HTTP Archive ha rilevato che il 74% dei siti mobile e il 97% dei siti desktop aveva un INP buono. In altre parole, INP è soprattutto un problema mobile. Se il report desktop è verde e quello mobile è arancione, è lo schema normale, non un errore di misurazione.
Dai priorità al dispositivo che porta traffico e fatturato. Per la maggior parte dei siti consumer è il mobile, il che significa anche testare su un telefono Android di fascia media o con il throttling della CPU in Chrome DevTools, non su un laptop veloce. La nostra guida alla SEO mobile copre il quadro mobile più ampio.
Dove puoi controllare il tuo punteggio INP?
Usa i dati sul campo per sapere se superi la soglia, e gli strumenti di laboratorio per capire perché non la superi. Ogni strumento risponde a una domanda diversa.
| Strumento | Tipo di dati | Ideale per |
|---|---|---|
| Search Console, report Core Web Vitals | Campo (CrUX), URL raggruppati | Vedere quali gruppi di pagine falliscono su mobile o desktop e convalidare le correzioni |
| PageSpeed Insights | Campo (CrUX, ultimi 28 giorni) più test di laboratorio Lighthouse | Controllare rapidamente un URL o l’intera origine |
| CrUX API, BigQuery o CrUX Vis | Campo (CrUX) | Tendenze nel tempo e confronti con i concorrenti |
| Real user monitoring (RUM), per esempio la libreria JavaScript web-vitals | Campo, i tuoi visitatori | Trovare quale elemento e quale interazione hanno causato un INP lento |
| Pannello Performance di Chrome DevTools | Laboratorio | Registrare un’interazione e vedere quale task l’ha bloccata |
| Lighthouse (modalità navigazione) | Laboratorio | Total Blocking Time come indicatore approssimativo; non misura INP durante un test di caricamento della pagina |
La documentazione di Google è chiara sulla gerarchia: i dati sul campo provenienti da utenti reali sono il modo migliore per misurare INP. Il Total Blocking Time può suggerire problemi, ma web.dev lo descrive come un indicatore ragionevole, “non un sostituto di INP”. Un punteggio Lighthouse perfetto non significa che superi la soglia INP.
Perché PageSpeed Insights non mostra un punteggio INP per alcune pagine?
Di solito perché non ci sono abbastanza dati di utenti reali per quell’URL. PageSpeed Insights recupera i dati sul campo dal Chrome UX Report (CrUX), che include solo pagine individuabili pubblicamente e con abbastanza visitatori. Google non pubblica la soglia di traffico esatta.
Quando un singolo URL non ha dati, PageSpeed Insights prova a ripiegare sui dati a livello di origine, cioè dell’intero dominio. Se anche l’origine non ha dati, la sezione dei dati sul campo mostra “Nessun dato” e restano solo i risultati di laboratorio di Lighthouse. Altri motivi comuni:
- La pagina è nuova, quindi non ha ancora raccolto 28 giorni di visite
- La pagina è dietro un login o esclusa dall’indicizzazione, quindi CrUX non la include
- I visitatori interagiscono raramente con la pagina, quindi ci sono pochi campioni INP anche con un buon traffico
La soluzione pratica è aggiungere un tuo RUM. La funzione onINP della libreria web-vitals riporta l’INP di ogni visita, e la sua build di attribuzione ti dice quale elemento era coinvolto e quanto è durata ciascuna delle tre fasi. Così hai dati anche sulle pagine con poco traffico e, soprattutto, il contesto per il debug.
Come trovare cosa rende lento l’INP?
Diagnostica prima la fase, poi la causa. Ogni fase indica un tipo diverso di intervento.
| Fase lenta | Causa tipica | Dove guardare |
|---|---|---|
| Input delay | Thread principale occupato da altri script: tag manager, widget di chat, A/B test, idratazione pesante durante il caricamento | Long task in DevTools intorno al momento del clic |
| Processing duration | Il gestore di eventi fa troppo: filtrare un lungo elenco di prodotti, chiamate di analytics, archiviazione sincrona, nuovo rendering di interi componenti | Il gestore del clic o del keydown nel pannello Performance |
| Presentation delay | DOM grande, ricalcolo costoso di stili e layout, rendering di grandi blocchi di HTML con JavaScript | Voci “Recalculate Style” e “Layout” dopo il gestore |
Un flusso di lavoro semplice:
- In Search Console, trova i gruppi di URL con “problema INP” su mobile.
- Apri un URL di esempio e individua le interazioni che le persone eseguono davvero: il menu, un filtro, il selettore della taglia, l’aggiunta al carrello, un campo di un modulo.
- In Chrome DevTools, imposta il throttling della CPU, avvia una registrazione Performance, esegui l’interazione e ferma la registrazione.
- Cerca i long task, che web.dev definisce come task superiori a 50 ms, e annota da quale script provengono.
- Ripeti l’interazione mentre la pagina è ancora in caricamento. È spesso il momento in cui il thread principale è più occupato, ed è proprio allora che gli utenti reali cliccano.
Come migliorare un punteggio INP scadente?
Fai meno lavoro sul thread principale al momento dell’interazione e dai al browser la possibilità di disegnare prima. Le correzioni seguenti sono ordinate più o meno dalla più semplice alla più tecnica.
Controlla prima gli script di terze parti
Su molti siti di marketing, il costo INP maggiore non è il tuo codice. Widget di chat, heatmap, strumenti per il consenso, widget delle recensioni e diversi tag di analytics competono tutti per il thread principale. Elenca ogni script nel tuo tag manager, elimina ciò che nessuno usa e ritarda i tag non essenziali a dopo il caricamento della pagina o dopo la prima interazione.
Mostra prima un riscontro, poi fai il resto
Aggiorna subito l’interfaccia (apri il menu, mostra lo spinner, segna il pulsante come premuto), poi esegui il lavoro più lento in un task separato. Si chiama cedere il controllo al thread principale (yielding). Un piccolo helper come quello qui sotto usa scheduler.yield() dove il browser lo supporta e ripiega su setTimeout altrove:
function yieldToMain() {
if (globalThis.scheduler?.yield) {
return scheduler.yield();
}
return new Promise(resolve => setTimeout(resolve, 0));
}
button.addEventListener('click', async () => {
showFilterResultsLoading(); // visible update first
await yieldToMain(); // let the browser paint
applyFilters(); // heavier work afterwards
sendAnalyticsEvent();
});Secondo web.dev, scheduler.yield() è supportato in Chrome ed Edge dalla versione 129 e in Firefox dalla versione 142, ma non in Safari, ed è per questo che il fallback è importante.
Spezza i long task
Qualsiasi task più lungo di 50 ms blocca l’input. Dividi i cicli lunghi, come l’elaborazione di centinaia di prodotti, in blocchi con un yield tra l’uno e l’altro. Chiedi al tuo sviluppatore di rivedere l’idratazione nei framework JavaScript, che spesso viene eseguita come un unico grande task durante il caricamento.
Mantieni il DOM snello
Ogni elemento in più rallenta il ricalcolo di stili e layout. Pagina o virtualizza gli elenchi lunghi, elimina i menu duplicati nascosti per mobile e desktop e usa la proprietà CSS content-visibility per saltare il rendering delle sezioni fuori schermo.
Evita il layout thrashing
Leggere un valore di layout, come l’altezza di un elemento, subito dopo aver modificato gli stili costringe il browser a calcolare immediatamente il layout. Nei tuoi gestori di eventi raggruppa le letture prima delle scritture.
Ricontrolla dopo ogni modifica
I dati sul campo impiegano tempo a cambiare. CrUX in PageSpeed Insights copre gli ultimi 28 giorni, e la convalida di Search Console prevede una finestra di monitoraggio di 28 giorni. Usa il tuo RUM per confermare la correzione in pochi giorni, poi lascia che i report di Google si aggiornino.
INP influisce sul posizionamento SEO?
INP fa parte dei Core Web Vitals, che secondo Google sono in linea con ciò che i suoi sistemi di ranking principali cercano di premiare, ma non è una scorciatoia per la cima dei risultati. Google “consiglia vivamente” buoni Core Web Vitals per avere successo nella Ricerca, mentre pertinenza e qualità dei contenuti restano decisive.
La ragione più forte per correggere INP è commerciale. Filtri lenti, pulsanti di aggiunta al carrello che rispondono in ritardo e moduli poco reattivi costano conversioni in modo diretto, soprattutto su mobile. Considera un buon punteggio INP come requisito minimo di un sito usabile, poi concentra la maggior parte del tuo impegno SEO su contenuti e struttura. La nostra guida alla SEO per e-commerce mostra dove si collocano le prestazioni tra le priorità di un negozio.
A cosa dovresti puntare?
Punta a un INP al 75° percentile ben al di sotto dei 200 ms su mobile, non appena sotto. Una pagina a 190 ms oggi supera la soglia, ma può fallire dopo un nuovo tag di marketing o un picco di traffico da dispositivi più lenti. Un margine di diverse decine di millisecondi dà al tuo team spazio per aggiungere funzionalità.
Fissa obiettivi per template anziché per URL: pagine di categoria, schede prodotto, articoli, moduli e checkout. Correggi per primo il template con più traffico e l’INP peggiore, e rendi INP parte della checklist di rilascio, così che i nuovi script vengano verificati prima di andare online.
Qual è il ruolo di Marketer Coffee?
Marketer Coffee è un’agenzia di AI SEO e GEO; trattiamo le prestazioni come parte della SEO tecnica, insieme ad architettura, dati strutturati e contenuti. Risultati in altri settori:
- Aldi.pl (retail). I clic organici sono passati da 367.127 a 852.724 al mese in 12 mesi (+132%) grazie a contenuti di prodotto, schema Product, un’architettura più snella e dati dei punti vendita unificati. Leggi il case study di Aldi.
- IDG-Online (servizi CCTV e affiliazione). Da 500 a oltre 30.000 clic mensili in 16 mesi contro Ceneo, MediaExpert e MediaMarkt, grazie a pagine di classifica, contenuti Q&A e schema. Leggi il case study di IDG-Online.
Per chi siamo adatti: siti in cui velocità, struttura e contenuti richiedono un unico piano, spesso negozi online o siti internazionali. Per chi non siamo adatti: team che hanno bisogno solo di un ingegnere delle prestazioni JavaScript per riscrivere una tantum un framework; per questo serve uno sviluppatore specializzato. Per vedere come si comporta il tuo sito nella ricerca con IA oltre che su Google, inizia con il nostro audit gratuito della visibilità nell’IA.
Domande frequenti sui punteggi INP
Qual è un buon punteggio INP?
200 millisecondi o meno al 75° percentile delle visite reali, misurato separatamente per mobile e desktop. Oltre 200 ms e fino a 500 ms è da migliorare; oltre 500 ms è scadente.
Quando INP ha sostituito FID?
INP è diventato un Core Web Vital il 12 marzo 2024, sostituendo First Input Delay. In quella data Search Console ha rimosso FID.
Perché il mio INP è buono su desktop ma scadente su mobile?
I telefoni hanno processori più lenti, quindi gli stessi script impiegano più tempo a essere eseguiti. Il Web Almanac 2024 ha rilevato un INP buono sul 97% dei siti desktop ma solo sul 74% dei siti mobile.
Lighthouse può misurare INP?
Un normale test di caricamento di Lighthouse non include interazioni dell’utente, quindi non può riportare INP. Mostra il Total Blocking Time, che è un indicatore approssimativo. Per valutare INP usa i dati sul campo di CrUX o del tuo RUM.
Quanto tempo serve perché una correzione INP si veda in Search Console?
I dati sul campo coprono una finestra mobile di 28 giorni, e la convalida di Search Console monitora per 28 giorni, quindi prevedi circa quattro settimane prima che i report riflettano del tutto una correzione. Il tuo RUM può confermarla prima.
In sintesi?
Un INP buono è di 200 ms o meno per almeno il 75% delle visite reali, su ciascun tipo di dispositivo. Trova i template che non superano la soglia in Search Console, registra le interazioni lente in DevTools, individua la fase lenta e correggi la causa: meno script di terze parti, riscontro più rapido, task più brevi e un DOM più piccolo. Poi lasciati un margine.
Se vuoi un secondo parere su dove si collocano le prestazioni tra le tue priorità SEO, prenota una consulenza gratuita.
Fonti: web.dev, “Interaction to Next Paint (INP)” (soglie, 75° percentile, fasi dell’interazione, regola sui valori anomali, TBT come indicatore); post sul blog web.dev di Jeremy Wagner e Rick Viscomi che annuncia INP come Core Web Vital il 12 marzo 2024; web.dev, “Optimize Interaction to Next Paint” e “Optimize long tasks” (long task da 50 ms, supporto di scheduler.yield); Guida di Google Search Console, report Core Web Vitals (soglie, convalida in 28 giorni); Google Search Central, “Understanding Core Web Vitals and Google search results”; Chrome for Developers, metodologia CrUX e CrUX in PageSpeed Insights (idoneità, finestra di 28 giorni, fallback sull’origine); HTTP Archive, Web Almanac 2024, capitolo Performance; Marketer Coffee, case study di Aldi e IDG-Online (altri settori).
