Interaction to Next Paint (INP) per la SEO

TL;DR — L’INP misura quanto rapidamente la pagina risponde quando qualcuno fa clic, tocca lo schermo o digita. Il browser misura l’intervallo tra l’interazione e il successivo aggiornamento visivo per l’intera visita, quindi restituisce un valore prossimo al peggiore. Un valore inferiore a 200 ms è buono; oltre 500 ms è scarso. È uno dei tre Core Web Vitals e nel 2024 ha sostituito una metrica precedente, First Input Delay.

Cosa misura realmente l’INP

Quando fai clic su un pulsante, tocchi un menu o digiti in una casella, ti aspetti che la pagina reagisca: si apre un menu, viene selezionata una casella di controllo o appare del testo. Interaction to Next Paint (INP) misura il tempo necessario, dall’interazione fino al momento in cui il browser disegna il fotogramma successivo mostrando il cambiamento.

Ecco il punto essenziale: l’INP non considera una sola interazione. Osserva ogni clic, tocco e pressione di un tasto durante l’intera visita, quindi riporta un valore prossimo al più lento. Basta quindi un’unica interazione poco fluida — per esempio una casella di ricerca che si blocca per mezzo secondo a ogni digitazione — per compromettere l’intero punteggio.

Scorrimento, passaggio del mouse e zoom non contano. Vengono misurate solo le interazioni di clic, tocco e tastiera.

Le soglie

L’INP è riportato in millisecondi e Google lo suddivide in tre valutazioni:

• Buono — 200 ms o meno
• Da migliorare — più di 200 ms, fino a 500 ms
• Scarso — più di 500 ms

Per avere un riferimento, 200 ms sono pochi e lasciano un margine ridotto. Tutto ciò che il codice esegue in risposta a un clic, compreso il disegno del risultato da parte del browser, deve rientrare in quel limite.

Perché ha sostituito il FID

La precedente metrica di reattività era First Input Delay (FID). FID misurava soltanto il ritardo prima che iniziasse la gestione della prima interazione su una pagina e smetteva di misurare non appena iniziava l’elaborazione. Non considerava né la durata effettiva di quell’elaborazione né il tempo necessario per aggiornare lo schermo.

L’INP ha risolto tutto questo. Misura il tempo completo (dall’inizio all’aggiornamento visivo) per tutte le interazioni, non solo la prima. Google ha reso ufficiale il cambiamento il 12 marzo 2024 e il FID è scomparso del tutto dagli strumenti entro settembre 2024.

Cosa rende l’INP scarso — in termini semplici

Quasi sempre, è JavaScript che monopolizza il thread principale. Il browser può fare solo una cosa alla volta su quel thread, quindi se un blocco di script è occupato a essere eseguito, il tuo clic deve mettersi in coda. Colpevoli comuni:

• Lavoro pesante eseguito all’interno del gestore di clic/tocco stesso.
• Grandi “long tasks” di JavaScript che bloccano tutto.
• Script di terze parti — analytics, banner per il consenso ai cookie, widget di chat, tag manager. Questi sono tra i peggiori colpevoli, anche su siti di contenuti semplici.

La soluzione, in generale, è fare meno lavoro quando qualcuno interagisce e suddividere i grandi compiti in piccoli pezzi in modo che il browser possa inserire la tua interazione tra di essi.

Vuoi i meccanismi reali — la suddivisione della latenza in tre parti, la matematica del 75° percentile, esattamente come risolvere ogni causa e l’angolazione SEO? Passa alla scheda Avanzate.

TL;DR — L’INP è la Core Web Vital per la reattività. Osserva la latenza di tutte le interazioni di clic, tocco e tastiera durante una visita e riporta il valore al 75° percentile (un valore anomalo scartato ogni 50 interazioni) — non solo il primo input come faceva il FID. La latenza di un’interazione = ritardo di input + durata di elaborazione + ritardo di presentazione. Buono ≤ 200 ms, scarso > 500 ms, giudicato sui dati sul campo al p75. Ha sostituito il FID il 12 marzo 2024 (FID completamente rimosso dagli strumenti a settembre 2024). Risolvilo suddividendo le long tasks, cedendo il controllo al thread principale con scheduler.yield(), facendo meno lavoro nei gestori di eventi, riducendo il DOM e rimandando gli script di terze parti. È una metrica sul campo — Total Blocking Time è il proxy di laboratorio e i due non sempre concordano.

Cosa misura l’INP — e come differisce dal FID

La definizione di Google è precisa: INP “valuta la reattività complessiva di una pagina alle interazioni dell’utente osservando la latenza di tutte le interazioni di clic, tocco e tastiera che si verificano durante l’intera durata della visita di un utente a una pagina.”

Questa frase “tutte le interazioni… durante l’intera durata” è il punto chiave. INP è una metrica a livello di visita, non di tempo di caricamento — e il ragionamento di Google è che la stragrande maggioranza del tempo di un utente su una pagina avviene dopo il caricamento, quindi la reattività durante l’uso conta più della sola prima impressione.

Il contrasto con First Input Delay è il modo più chiaro per capirlo: “FID misurava solo il ritardo di input della prima interazione su una pagina. INP migliora FID osservando tutte le interazioni su una pagina, dal ritardo di input, al tempo necessario per eseguire i gestori di eventi.” FID cronometrava una cosa su una interazione — l’attesa prima che il suo gestore iniziasse — e ignorava sia quanto a lungo il gestore è rimasto in esecuzione sia quanto tempo ha impiegato lo schermo ad aggiornarsi. INP misura la latenza completa di ogni interazione.

Una sfumatura che vale la pena chiarire, perché è un mito comune: INP non è letteralmente la peggiore interazione. Per evitare di penalizzare una pagina per un singolo picco casuale, il browser scarta un valore anomalo ogni 50 interazioni, poi riporta il valore al 75° percentile delle visualizzazioni di pagina. In una visita con poche interazioni, questo cade sulla interazione più lenta; in una con molte interazioni, un paio di valori anomali vengono esclusi prima.

Ciò che conta come interazione è anche più ristretto di quanto si pensi. Solo clic, tocchi e pressioni da tastiera vengono misurati. Scorrimento, passaggio del mouse e zoom sono esplicitamente esclusi. E un singolo gesto può attivare più eventi — un tocco produce pointerdown, pointerup e click — che INP raggruppa come una interazione, non tre. All’interno di quel gruppo, INP prende la durata dell’evento individuale più lunga, non la somma di tutti — quindi un pointerdown veloce accanto a un click lento viene comunque riportato come una interazione dimensionata dall’evento lento. Se una pagina non ha interazioni qualificanti durante una visita, INP semplicemente non viene riportato per essa.

Le tre parti della latenza di un’interazione

Ogni latenza di interazione si suddivide in tre parti sequenziali. Questo è il modello da tenere a mente, perché ogni parte indica una soluzione diversa:

Interaction latency = Input delay + Processing duration + Presentation delay

1. Ritardo input — il tempo prima che i tuoi gestori di eventi possano anche solo iniziare a eseguire, di solito perché il thread principale è occupato a completare un’attività lunga.
2. Durata elaborazione — il tempo necessario per eseguire tutti i callback dei tuoi gestori di eventi.
3. Ritardo presentazione — il tempo da quando i tuoi gestori finiscono fino a quando il browser dipinge il frame successivo sullo schermo.

La build di attribuzione di web-vitals espone tutti e tre (inputDelay, processingDuration, presentationDelay) così puoi vedere quale parte domina in una interazione reale. Secondo i dati del Web Almanac 2024, il ritardo di presentazione è spesso la parte singola più grande alla mediana — ma la durata di elaborazione è dove di solito vive la leva di ottimizzazione, perché è la parte che si gonfia su pagine mal costruite.

Le soglie — e l’avvertenza sul campo p75

Google Search Central indica chiaramente l’obiettivo: “an INP of less than 200 milliseconds” (traduzione) «un INP inferiore a 200 millisecondi» e inquadra il programma così: “We highly recommend site owners achieve good Core Web Vitals for success with Search.” (traduzione) «Raccomandiamo vivamente ai proprietari dei siti di raggiungere buoni Core Web Vitals per avere successo nella Ricerca.» Il budget di 200 ms è davvero ristretto: a 60 fps il browser punta a un nuovo fotogramma ogni circa 16,7 ms e tutto il lavoro del gestore, insieme al rendering, deve rientrare nel tempo disponibile.

Perché INP è una metrica di campo (e i dati di laboratorio non bastano)

Questa è la trappola che cattura molti SEO: un punteggio Lighthouse verde non significa un buon INP. Ma “Lighthouse non può misurare l’INP” richiede tre casi separati, non uno solo, altrimenti leggerai male i tuoi stessi strumenti:

1. Un’esecuzione Lighthouse standard e non interattiva non riporta alcun INP. Osserva solo il caricamento della pagina — non fa mai clic, tocchi o digitazioni — quindi non c’è alcuna interazione da cronometrare. Lighthouse ripiega su Total Blocking Time (TBT) come proxy del tempo di caricamento. La stessa formulazione di Google: “Because TBT correlates well with INP, a page with a high TBT is a reasonable indicator that there may be high INP values during load.” (traduzione) «Poiché il TBT correla bene con l’INP, una pagina con un TBT elevato è un indicatore ragionevole che potrebbero esserci valori INP elevati durante il caricamento.» Le parole chiave sono “during load.” (traduzione) «durante il caricamento.» Il TBT non dice nulla su un’interazione che va male dieci secondi dopo quando un widget caricato in lazy-load viene eseguito — è un proxy, mai un sostituto o una formula di conversione.
2. Un’interazione esercitata manualmente o sinteticamente — fare clic su un pulsante reale in DevTools, o scriptare un clic in uno strumento di laboratorio — produce un numero di latenza reale in stile INP per quella singola interazione. Questo è utile per riprodurre un bug specifico. Ma è comunque un solo percorso scriptato su un solo dispositivo: non può rappresentare la combinazione sul campo di dispositivi reali, utenti reali, obiettivi di interazione reali e l’intera durata della pagina di una visita completa. Come dice Google, il valore risultante “will be dependent on what interactions are performed during the measurement period,” (traduzione) «dipenderà dalle interazioni eseguite durante il periodo di misurazione», e il comportamento reale degli utenti è troppo variabile perché una singola esecuzione di laboratorio possa rappresentarlo.
3. La distribuzione sul campo è l’unica cosa che l’INP realmente è. Ecco perché la fonte autorevole sono i dati sul campo: il Chrome User Experience Report (CrUX), presentato tramite PageSpeed Insights e il report Core Web Vitals di Search Console. “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (traduzione) «I dati sul campo sono la migliore fonte di informazioni a cui puoi attingere per capire quali interazioni sono problematiche per gli utenti reali.»

Usa il laboratorio (casi 1 e 2) per trovare e riprodurre un’interazione lenta; usa il campo (caso 3) per confermare se sta effettivamente trascinando verso il basso i punteggi dei visitatori reali.

Perché il tuo punteggio INP è scarso

Quasi ogni problema di INP riconduce al thread principale bloccato quando un utente interagisce. I soliti sospetti:

• Attività lunghe. Qualsiasi attività sul thread principale oltre 50 ms è un’attività lunga; l’importo oltre 50 ms è il suo “periodo di blocco”. Mentre una è in esecuzione, la tua interazione non può essere gestita. Questa è la causa principale più grande.
• Gestori di eventi pesanti. Fare troppo in modo sincrono all’interno di un gestore di clic/input aumenta direttamente la durata di elaborazione.
• Grandi dimensioni del DOM. DOM più grandi costano di più da renderizzare, il che aumenta sia il ritardo di input che quello di presentazione.
• Script di terze parti. Secondo il Web Almanac, i fornitori di consenso, i tag manager, l’analisi e i widget di chat sono i principali colpevoli — e colpiscono anche i siti di contenuti semplici. Sono il primo posto in cui guardo su una pagina che non ho costruito io.
• JavaScript post-caricamento. Solo perché una pagina è stata renderizzata non significa che abbia finito di caricarsi — gli script che vengono valutati dopo la prima pittura possono bloccare le interazioni iniziali.

Come risolverlo

Le strategie, approssimativamente in ordine di impatto:

1. Spezza le attività lunghe. Il consiglio principale di Google sui gestori è di “do as little work as possible in them.” (traduzione) «fare il minor lavoro possibile in essi.» Dividi un grande lavoro in attività più piccole così il browser può intercalare un’interazione utente. Quando le attività sono spezzate, “the browser can respond to higher-priority work much sooner — including user interactions.” (traduzione) «il browser può rispondere molto prima al lavoro a priorità più alta — incluse le interazioni utente.»

2. Cedi il controllo al thread principale. Il metodo moderno consigliato è scheduler.yield() (Chrome 129+, Firefox 142+): await scheduler.yield() sospende il codice, permette al browser di gestire il lavoro in attesa e riprende con priorità, evitando che altre attività in coda superino la continuazione. Il fallback classico è setTimeout(..., 0), che funziona ancora ma sposta la continuazione in fondo alla coda delle attività; dopo varie chiamate annidate i browser impongono inoltre un minimo di 5 ms. Non usare più isInputPending(): Google afferma “we no longer recommend using this API.” (traduzione) «non consigliamo più di usare questa API». Consulta la scheda Script per il modello.

3. Fai meno nei gestori di eventi — rimanda il lavoro non critico. Esegui solo l’aggiornamento visivo che il prossimo frame richiede in modo sincrono; spingi tutto il resto (salvataggio, controllo ortografico, analytics, conteggi di parole) dietro requestAnimationFrame + setTimeout o uno yield. L’utente vede la risposta immediatamente; la contabilità avviene dopo.

4. Evita il layout thrashing. Leggere le proprietà di layout subito dopo aver scritto gli stili nello stesso task costringe il browser a un layout sincrono che avrebbe potuto altrimenti raggruppare. Raggruppa le letture, poi le scritture.

5. Riduci la dimensione del DOM. Alberi più piccoli vengono renderizzati più velocemente. content-visibility può renderizzare pigramente gli elementi fuori schermo così non ti costano durante il caricamento o l’interazione.

6. Controlla e rimanda gli script di terze parti. Questa è la correzione SEO a più alto impatto sui siti reali. Carica gli script di consenso/tag/analytics in modo pigro, limitali all’interazione, o spostali fuori dal percorso critico. Una pagina di contenuti “leggera” può fallire l’INP solo a causa di un widget incorporato pesante.

L’INP influisce sul posizionamento?

Sì — l’INP è uno dei tre Core Web Vitals, e i Core Web Vitals fanno parte dei segnali di page experience di Google. Ma è un segnale leggero: un criterio di spareggio tra risultati comparabilmente rilevanti, non un fattore di ranking primario. Non inseguire un punteggio INP perfetto a scapito di contenuti e rilevanza.

Due punti SEO pratici. Primo, il mobile è il numero difficile. Nel Web Almanac 2024, ~74% dei siti mobile ha superato l’INP rispetto a ~97% su desktop — e poiché Google indicizza mobile-first, la cifra mobile è quella che conta. Secondo, i siti complessi vanno peggio: solo ~53% dei primi 1 000 siti ha superato, perché le pagine ricche di funzionalità caricano più JavaScript che blocca il thread principale. Lo sviluppo intenso di funzionalità è un rischio INP, e le pagine ad alta interazione — pagine prodotto, checkout, risultati di ricerca, moduli — sono molto più esposte rispetto ai contenuti statici.

INP vs FID — il quadro completo

FID è sparito — rimosso da Search Console il giorno in cui è stato lanciato l’INP e da CrUX’s BigQuery/API entro settembre 2024. Se uno strumento o un audit fa ancora riferimento a FID, è obsoleto.

Casi limite che fanno discordare i dati INP

Una manciata di stranezze del ciclo di vita spiega la maggior parte delle domande “perché il mio RUM non corrisponde a CrUX”:

• Nessuna interazione, nessun INP. Se una visita non riceve mai un clic, un tocco o una pressione di un tasto — o riceve solo gesti esclusi come lo scorrimento e il passaggio del mouse — non c’è alcun valore INP per quella visualizzazione di pagina. Questo è normale nelle pagine di contenuto di sola lettura e non è un bug nel tuo monitoraggio.
• Gli iframe contano ai fini della metrica, ma il tuo JavaScript non può vedere al loro interno. Un’interazione all’interno di un iframe incorporato (un annuncio, un widget, un modulo incorporato) contribuisce all’INP della pagina. Ma uno script RUM di prima parte non può leggere gli eventi da un iframe cross-origin come può fare la metrica del browser stesso — quindi CrUX e una configurazione RUM same-origin possono legittimamente discordare su pagine con incorporamenti di terze parti. Documenta questa lacuna piuttosto che trattare una discrepanza RUM/campo come un bug.
• Il ripristino della cache back/forward azzera l’INP. Una pagina recuperata dalla bfcache (il pulsante indietro, per esempio) inizia un nuovo conteggio INP — le interazioni precedenti alla navigazione di allontanamento non vengono trasferite.
• Le schede di lunga durata e in background devono comunque fare rapporto. Poiché una scheda può rimanere aperta per ore senza mai essere scaricata formalmente — soprattutto su mobile, dove il sistema operativo potrebbe semplicemente terminarla — l’INP dovrebbe essere catturato quando la pagina diventa nascosta, non solo su unload. Le configurazioni RUM che scaricano solo su unload perderanno silenziosamente dati da queste visite.

Dove si colloca

L’INP è un elemento del quadro dei Core Web Vitals, insieme a Largest Contentful Paint (caricamento) e Cumulative Layout Shift (stabilità visiva). Controllalo in PageSpeed Insights e nel report di Search Console (campo), e correggilo in Lighthouse / Chrome DevTools (laboratorio, tramite il proxy TBT). I dati alla base di tutto provengono da CrUX.

Riepilogo AI

Una sintesi della versione Advanced:

• INP = il Core Web Vital della reattività. Misura la latenza di tutte le interazioni con clic, tocco e tastiera durante l’intera visita e riporta il valore al 75° percentile (scartando un valore anomalo ogni 50 interazioni), non soltanto il primo input come faceva FID.
• Latenza = ritardo di input + durata di elaborazione + ritardo di presentazione. Ogni componente suggerisce una correzione diversa; spesso il margine maggiore è nella durata di elaborazione.
• Soglie (dati sul campo, p75): buono ≤ 200 ms, da migliorare ≤ 500 ms, scarso

  500 ms.

• Contano solo clic, tocchi e tastiera — scorrimento, passaggio del mouse e zoom sono esclusi; i diversi eventi di un singolo gesto vengono raggruppati in un’unica interazione.
• Ha sostituito FID il 12 marzo 2024 (FID è stato rimosso completamente dagli strumenti nel settembre 2024). FID misurava soltanto il ritardo di input della prima interazione.
• È una metrica sul campo. L’affermazione «Lighthouse non può misurare l’INP» va distinta in tre casi: un’esecuzione Lighthouse standard e non interattiva non produce un valore INP e usa Total Blocking Time soltanto come proxy del caricamento; un’interazione eseguita manualmente in laboratorio produce una latenza reale, ma non rappresentativa; soltanto i dati sul campo di CrUX / PageSpeed Insights / Search Console sono autorevoli.
• Cause: attività lunghe (>50 ms), gestori di eventi pesanti, DOM di grandi dimensioni e soprattutto script di terze parti (consenso, tag manager, analytics, chat).
• Correzioni: suddividi le attività lunghe, cedi il controllo con scheduler.yield() (fallback setTimeout; isInputPending() non è più consigliato), riduci il lavoro nei gestori, evita il layout thrashing, riduci il DOM e rinvia gli script di terze parti.
• Casi limite: se non si verifica alcuna interazione qualificante, non esiste alcun valore INP; le interazioni negli iframe contribuiscono alla metrica, ma uno script RUM same-origin non può osservarle dall’interno; i ripristini dalla bfcache azzerano l’INP; le schede aperte a lungo o in background dovrebbero inviare il dato quando diventano hidden, non soltanto all’evento unload.
• SEO: è un segnale di ranking debole. Il dato mobile (~74% di superamento rispetto a ~97% su desktop) è quello rilevante con l’indicizzazione mobile-first; le pagine con molte interazioni sono le più esposte.

Documentazione ufficiale

Documentazione di fonte primaria di Google / del team Chrome.

web.dev — riferimenti su INP

• Interaction to Next Paint (INP) — la definizione ufficiale, le tre componenti della latenza, i tipi di interazione e le soglie.
• Ottimizzare Interaction to Next Paint — come ridurre il lavoro nei gestori, rinviare quello non critico, evitare il layout thrashing, ridurre il DOM e usare content-visibility.
• Interaction to Next Paint diventa ufficialmente un Core Web Vital — l’annuncio del 12 marzo 2024 di Jeremy Wagner e Rick Viscomi e la dismissione di FID.
• First Input Delay (FID) — la metrica deprecata, ciò che misurava e perché è stata sostituita.
• Una nuova metrica di reattività: richiesta di feedback — i limiti progettuali di FID e i miglioramenti introdotti da INP.
• Ottimizzare le attività lunghe — la soglia di 50 ms, scheduler.yield(), il fallback setTimeout e perché isInputPending() non è più consigliato.
• Valutazione degli script e attività lunghe — TBT come proxy di INP e indicazioni sulla dimensione degli script.
• Individuare le interazioni lente sul campo — la build di attribuzione di web-vitals e l’API Long Animation Frames (LoAF).

Chrome / Google Search

• Riferimento sulle funzionalità di Performance (Chrome DevTools) — la traccia Interactions, Live Metrics e l’avviso di 200 ms.
• Note di rilascio di CrUX — confermano la rimozione di FID da BigQuery/API nel settembre 2024.
• Core Web Vitals e risultati della Ricerca Google — INP come parte del segnale relativo all’esperienza sulla pagina; l’obiettivo ≤ 200 ms.

Citazioni dalla fonte

Dichiarazioni pubbliche di Google / del team Chrome. Ogni link è un deep link che salta al passaggio citato nella pagina di origine.

Cosa misura INP e come si differenzia da FID

• “INP is a Core Web Vitals metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (traduzione) «INP è una metrica Core Web Vitals che valuta la reattività complessiva di una pagina alle interazioni dell’utente osservando la latenza di tutte le interazioni di clic, tocco e tastiera che si verificano durante la visita dell’utente a una pagina.» — web.dev, Interaction to Next Paint (INP). Vai alla citazione
• “FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers.” (traduzione) «FID misurava solo il ritardo di input della prima interazione su una pagina. INP migliora FID osservando tutte le interazioni su una pagina, dal ritardo di input al tempo necessario per eseguire i gestori di eventi.» Vai alla citazione
• “First Input Delay (FID) is no longer a Core Web Vital, and has been replaced by the Interaction to Next Paint (INP) metric.” (traduzione) «First Input Delay (FID) non è più una Core Web Vital ed è stata sostituita dalla metrica Interaction to Next Paint (INP).» — web.dev, First Input Delay (FID). Vai alla citazione

Il passaggio da FID a INP

• “FID will be deprecated.” (traduzione) «FID sarà deprecata.» — Jeremy Wagner & Rick Viscomi, blog web.dev, Interaction to Next Paint officially becomes a Core Web Vital. Vai alla citazione
• “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12.” (traduzione) «FID sarà rimossa da Google Search Console non appena INP diventerà una Core Web Vital il 12 marzo.» Vai alla citazione

Long task — la causa principale

• “Any task that takes longer than 50 milliseconds is a long task.” (traduzione) «Qualsiasi attività che dura più di 50 millisecondi è un’attività lunga.» — web.dev, Ottimizzare le attività lunghe. Vai alla citazione

I dati sul campo sono primari

• “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (traduzione) «I dati sul campo sono la fonte migliore per capire quali interazioni creano problemi agli utenti reali.» — web.dev, Individuare le interazioni lente sul campo. Vai alla citazione

Google Ricerca

• “We highly recommend site owners achieve good Core Web Vitals for success with Search.” (traduzione) «Raccomandiamo vivamente ai proprietari dei siti di raggiungere buoni Core Web Vitals per avere successo nella Ricerca.» — Google Search Central, Core Web Vitals e risultati della Ricerca Google. Fonte

Elenco di controllo per la correzione di INP

Procedi dall’alto verso il basso — gli elementi in cima tendono a spostare maggiormente il numero:

• Recupera l’INP sul campo (PageSpeed Insights / report CWV di Search Console), non solo un punteggio di laboratorio — e controlla il mobile separatamente.
• Identifica le interazioni lente con la build di attribuzione di web-vitals o la traccia Interazioni di Chrome DevTools (segnala qualsiasi cosa oltre 200 ms).
• Trova e spezza le attività lunghe (qualsiasi cosa oltre 50 ms sul thread principale).
• Cedi il controllo al thread principale all’interno di loop di lunga durata — scheduler.yield(), con un fallback setTimeout(..., 0). (Smetti di usare isInputPending().)
• All’interno di ogni gestore, esegui in modo sincrono solo l’aggiornamento critico per il rendering; rimanda salvataggio, validazione, controllo ortografico, analisi dietro rAF + setTimeout.
• Controlla il layout thrashing — leggere il layout subito dopo aver scritto gli stili nella stessa attività. Raggruppa le letture, poi le scritture.
• Controlla gli script di terze parti (consenso, tag manager, analisi, chat). Rimanda, carica in lazy o vincolali all’interazione — di solito il singolo guadagno più grande.
• Riduci la dimensione del DOM; applica content-visibility alle sezioni fuori schermo.
• Rimanda / dividi il codice JS non critico così che gli script post-caricamento non blocchino le interazioni iniziali.
• Rimisura sul campo dopo il deploy — CrUX ha una finestra mobile di 28 giorni, quindi il punteggio si muove lentamente.

INP vs FID — promemoria

Fatti rapidi

• Soglie (campo, p75): Buono ≤ 200 ms · Da migliorare ≤ 500 ms · Scarso > 500 ms.
• Conteggi: clic, tocchi, tastiera. Esclude: scorrimento, passaggio del mouse, zoom.
• Latenza = ritardo di input + durata dell’elaborazione + ritardo di presentazione.
• Attività lunga = qualsiasi attività sul thread principale > 50 ms.
• Proxy di laboratorio: Tempo di blocco totale — correlato, ma riflette solo il blocco al momento del caricamento. La fonte autorevole sono i dati sul campo (CrUX).
• Tasso di passaggio mobile (~74%) è molto inferiore al desktop (~97%) — e il mobile è ciò che conta.

Cedi il controllo al thread principale

Quando hai un ciclo di lunga durata (rendering di una grande lista, elaborazione di dati al clic), restituisci periodicamente il controllo al browser così che possa gestire un’interazione utente in attesa. L’API moderna è scheduler.yield(); ripiega su setTimeout dove non è supportata.

// Yield to the main thread every ~50 ms of work so the browser
// can handle a user interaction in between.
async function runJobs(jobQueue, deadline = 50) {
  let lastYield = performance.now();

  for (const job of jobQueue) {
    job();

    if (performance.now() - lastYield > deadline) {
      await yieldToMain();
      lastYield = performance.now();
    }
  }
}

// scheduler.yield() resumes with priority; setTimeout is the fallback.
function yieldToMain() {
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();          // Chrome 129+, Firefox 142+
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

Alcune note:

• scheduler.yield() restituisce una promise che si risolve in un’attività futura e la continuazione ha priorità, quindi le altre attività in coda non superano il codice ripreso.
• setTimeout(..., 0) funziona ovunque ma sposta la continuazione in fondo alla coda; dopo varie chiamate annidate i browser impongono un minimo di circa 5 ms.
• Non usare isInputPending(): Google “no longer recommend[s] using this API.” (traduzione) «non consiglia più di usare questa API».

Rimanda il lavoro non critico in un handler

Esegui solo ciò che serve al prossimo frame; sposta il resto dopo un paint.

textBox.addEventListener('input', (event) => {
  updateTextBox(event);                  // render-critical: do it now

  requestAnimationFrame(() => {
    setTimeout(() => {
      updateWordCount(text);             // everything else: after paint
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

Strumenti per misurare e correggere l’INP

Campo (autorevole — è ciò che Google valuta)

• PageSpeed Insights — INP di campo CrUX per URL/origine, suddiviso per mobile e desktop, più un passaggio diagnostico di laboratorio.
• Search Console — Report Core Web Vitals — stato INP su tutti i tuoi URL, raggruppati per problema, basato su dati di campo.
• CrUX — il dataset sottostante del Chrome User Experience Report (anche interrogabile tramite l’API CrUX / BigQuery).

Laboratorio / debug

• Chrome DevTools — Pannello Performance — la traccia Interactions misura il ritardo di input, l’elaborazione e la presentazione di ogni interazione, e segnala qualsiasi cosa oltre 200 ms; Live Metrics si aggiorna mentre clicchi.
• Lighthouse — non può misurare l’INP direttamente; riporta il Total Blocking Time come proxy di laboratorio.

Monitoraggio utenti reali (RUM)

• Libreria JS web-vitals — onINP() per il valore; la build di attribuzione (web-vitals/attribution) espone inputDelay / processingDuration / presentationDelay, il selettore interactionTarget e le voci LoAF così puoi vedere esattamente quale script ed elemento hanno causato l’interazione lenta. Qualunque setup RUM tu usi, documenta il suo tasso di campionamento e la copertura di attribuzione — un dato RUM citato senza quel contesto non è confrontabile con il p75 di campo di CrUX, e non può vedere all’interno di iframe cross-origin come può fare la metrica aggregata (vedi Casi limite, nella scheda Avanzate).

Come gli strumenti stessi vengono valutati

Un esempio dal vivo della metrica descritta in questa pagina — noti servizi di velocità e monitoraggio classificati in base al loro INP mobile reale degli utenti (dati di campo Chrome UX Report):

Correzioni INP che di solito mancano il bersaglio

Ottimizzare solo la prima interazione

L’INP valuta le interazioni durante tutta la visita, non solo il primo input. Prova menu, ricerca, filtri, moduli e altri controlli ripetuti prima di decidere che la pagina è reattiva.

Trattare il Total Blocking Time come il risultato

Il TBT è un utile proxy di laboratorio perché espone attività lunghe sul thread principale, ma non è l’INP di campo. Usalo per trovare candidati, poi verifica le interazioni reali con dati di campo o una traccia di interazione.

Spostare tutto il lavoro in un unico callback ritardato

Rimandare un grande blocco può semplicemente spostare il blocco. Dividi il lavoro in attività più piccole e cedi il controllo così il browser può fare paint tra di esse.

Rimuovere il feedback visivo per accorciare l’handler

Un controllo che esegue lavoro senza mostrare una risposta sembra comunque rotto. Rendi prima il cambio di stato immediato, poi rimanda il lavoro di follow-up non critico.

Diagnostica l’INP con il modello di latenza in tre parti

Ogni interazione lenta ha tre punti da esaminare:

1. Ritardo di input: l’evento ha aspettato perché il lavoro precedente sul thread principale era ancora in esecuzione. Controlla le attività lunghe e il JavaScript di terze parti prima che l’handler iniziasse.
2. Durata di elaborazione: l’event handler stesso ha fatto troppo. Riduci il lavoro sincrono, dividi i loop e rimanda qualsiasi cosa di cui il prossimo frame non ha bisogno.
3. Ritardo di presentazione: stile, layout o paint hanno richiesto troppo tempo dopo l’handler. Riduci la complessità del DOM ed evita di forzare calcoli di layout ripetuti.

Inizia con la fase più grande nella traccia. Registra nuovamente la stessa interazione dopo ogni modifica, così un handler più veloce non nasconde un nuovo collo di bottiglia di presentazione.

Dimostrare che una modifica a INP ha migliorato l’interazione

Test di rilascio dell’handler

Test da eseguire: registra l’interazione target nel pannello Performance prima e dopo aver suddiviso o ceduto il lavoro lungo. Risultato atteso: lo span di elaborazione dell’interazione si riduce o viene suddiviso da un paint. Interpretazione del fallimento: il lavoro costoso è altrove o viene ancora eseguito in modo sincrono. Finestra di monitoraggio: immediata in tracce ripetute. Trigger di rollback: il controllo si aggiorna fuori ordine, perde stato o produce nuovi errori di input.

Test di presentazione

Test da eseguire: ispeziona il lavoro di stile, layout e paint della stessa traccia dopo l’event handler. Risultato atteso: il prossimo paint arriva prima senza un task di layout più grande. Interpretazione del fallimento: la dimensione del DOM o il layout forzato rimane il collo di bottiglia. Finestra di monitoraggio: immediata nelle tracce di laboratorio. Trigger di rollback: la risposta visiva diventa incompleta o instabile.

Conferma sul campo

Test da eseguire: confronta l’attribuzione onINP() post-rilascio per l’interazione e il template modificati con la loro baseline. Risultato atteso: il p75 INP migliora e l’elemento target non domina più gli eventi lenti. Interpretazione del fallimento: il caso di laboratorio non rappresentava dispositivi o percorsi reali. Finestra di monitoraggio: RUM man mano che arrivano le visite; CrUX sulla sua finestra mobile di 28 giorni. Trigger di rollback: la reattività o il completamento dell’interazione peggiorano costantemente dopo il deployment.

Metriche INP da monitorare

INP reale dell’utente al p75

Metrica: il 75° percentile di INP per template e classe di dispositivo. Cosa ti dice: se le visite reali tipiche sono reattive lungo l’intero percorso. Come ottenerla: CrUX, PageSpeed Insights o RUM con web-vitals. Benchmark / intervallo realistico: 200 ms o meno è buono; oltre 500 ms è scarso. Cadenza: monitora dopo i rilasci JavaScript e rivedi la tendenza sul campo su base mensile.

Tasso di interazioni lente

Metrica: la quota di interazioni misurate sopra i 200 ms, raggruppate per target. Cosa ti dice: quali controlli creano il maggior ritardo visibile all’utente anche quando il p75 a livello di pagina passa. Come ottenerla: la build di attribuzione di web-vitals o i dati Event Timing in RUM. Benchmark / intervallo realistico: stabilisci una baseline per percorso e riduci i colpevoli a volume più alto. Cadenza: settimanale per template simili ad applicazioni.

Quota delle fasi di latenza

Metrica: ritardo di input, durata di elaborazione e ritardo di presentazione per le interazioni lente. Cosa ti dice: se la pianificazione, il codice dell’handler o il rendering sono il vincolo principale. Come ottenerla: tracce DevTools e attribuzione INP. Benchmark / intervallo realistico: nessuna suddivisione universale è sana; confronta ogni fase con la propria baseline e con la soglia totale buona di 200 ms. Cadenza: durante ogni indagine di performance mirata.

Risorse che meritano il tuo tempo

Google / Chrome (il canone)

• Interaction to Next Paint (INP) — inizia qui.
• Optimize Interaction to Next Paint — le soluzioni.
• Optimize long tasks — cedimento, scheduler.yield().
• Find slow interactions in the field — debug con LoAF + attribuzione.
• INP becomes a Core Web Vital — il lancio del 12 marzo 2024.

Dati

• Web Almanac 2024 — Performance — i numeri reali del tasso di superamento INP e le mediane dei sotto-componenti.

Dal settore

• INP — MDN Web Docs — voce di riferimento di MDN; utile per verificare il supporto dei browser e la definizione della metrica al di fuori della documentazione Google.
• Scheduler API: scheduler.yield() — MDN — tabella di supporto browser e dettagli sulle specifiche per la principale primitiva di yield.
• PerformanceEventTiming — MDN — l’API browser sottostante che INP legge; utile quando si analizzano i dati grezzi di temporizzazione degli eventi.
• Long Animation Frames API — Chrome Platform Status — monitoraggio del supporto browser di LoAF, l’API che alimenta l’attribuzione INP nella libreria web-vitals.
• Argomento INP — Search Engine Land — copertura delle notizie di settore sugli aggiornamenti INP, risultati dei test e transizione da FID a INP da parte dei professionisti.

Statistiche da citare

• Circa il 74% dei siti mobile supera l’INP, contro circa il 97% dei siti desktop (2024). Ottenere un buon risultato sui dispositivi mobili è molto più difficile; poiché Google usa l’indicizzazione mobile-first, è questo il dato rilevante per la SEO. Web Almanac 2024
• Solo circa il 53% dei primi 1 000 siti supera l’INP — i siti ricchi di funzionalità caricano più JavaScript che blocca il thread principale, quindi i siti più grandi spesso ottengono risultati peggiori. Web Almanac 2024
• Attività lunga = > 50 ms. Qualunque attività superi i 50 ms sul thread principale impedisce al browser di rispondere alle interazioni: è il meccanismo diretto alla base di un INP scarso. web.dev — Ottimizzare le attività lunghe
• Mediane delle componenti (2024): il ritardo di presentazione, circa 36 ms, è spesso il contributo singolo maggiore alla mediana; al p75 seguono da vicino il ritardo di input e il tempo di elaborazione. Questo dato aiuta a capire quale delle tre componenti affrontare per prima. Web Almanac 2024

Video

• Google Chrome Developers (YouTube) — le spiegazioni del team Chrome sui Core Web Vitals e sull’INP, comprese le procedure guidate per diagnosticare in DevTools le interazioni lente. Canale

Mettiti alla prova: Interaction to Next Paint

Cinque domande rapide sulla reattività e sulla diagnosi dell’INP. Scegli una risposta per ciascuna, quindi verifica.

Cronologia modifiche