Interaction to Next Paint è dentro i Core Web Vitals da marzo 2024, al posto del vecchio FID. A metà 2026 non è più una novità da tenere d'occhio: è la metrica che ci fa perdere o guadagnare posizioni. E soprattutto è quella che smaschera i siti "veloci al primo caricamento e appiccicosi appena tocchi qualcosa".
Perché INP è più onesto di FID
FID misurava solo il ritardo del primo input. Un trucco: se la prima interazione era veloce, il punteggio era buono anche se tutto il resto della pagina rispondeva a rilento. INP guarda la latenza dell'intera sessione e riporta (quasi) il caso peggiore. Non c'è più modo di barare con un onload leggero.
La soglia "good" è 200ms. La "needs improvement" arriva a 500ms. Sotto i 200ms l'interfaccia sembra istantanea; sopra i 500ms l'utente sente il lag anche senza saperlo nominare.
Le cause reali che troviamo negli audit
- Long task da JavaScript di terze parti: tag manager, chat widget, analytics. Un singolo script di marketing che gira 300ms sul main thread rovina l'INP di tutta la pagina.
- Hydration troppo pesante: componenti client giganti che si idratano tutti insieme al primo tap. Il browser è occupato a montare React mentre l'utente sta già cliccando.
- State update non spezzati: un
setStateche ricalcola una lista da 2.000 righe in modo sincrono. L'interazione parte, ma il paint successivo arriva mezzo secondo dopo. - Layout thrashing: handler che leggono e scrivono il DOM in loop, forzando reflow multipli in un solo frame.
Cosa abbiamo cambiato davvero
Rompere i long task
La leva più efficace è la più banale: spezzare il lavoro lungo. Usiamo scheduler.yield() dove supportato per cedere il main thread tra un pezzo e l'altro, e spostiamo su Web Worker qualsiasi calcolo che non tocca il DOM. Da solo, questo ci ha portato pagine da 480ms a 180ms.
Isolare i terzi
Ogni script di terze parti va caricato con defer, dopo l'interazione, o dentro un iframe/worker (Partytown resta utile). La regola nei nostri progetti: nessun tag entra sul main thread durante i primi secondi di vita della pagina, punto.
Idratazione selettiva
Con Next.js e i Server Components la maggior parte della pagina resta server-only. Idratiamo solo le isole interattive. Meno JS spedito significa meno JS da eseguire al primo tap, e l'INP ne beneficia più della LCP.
Misurare sul campo, non in laboratorio
Lighthouse in locale non vede l'INP reale: manca l'interazione umana. Guardiamo i dati field del CrUX e, per il dettaglio, mandiamo l'evento INP a un endpoint nostro con l'API PerformanceObserver. Il pattern che emerge quasi sempre: il 90% degli utenti sta bene, il p75 lo rovinano tre interazioni specifiche, apertura menu, filtro, apri-carrello. Si ottimizzano quelle, non tutto.
Verdetto
INP premia l'ingegneria seria e punisce il "carichiamoci sopra un altro script". Non serve riscrivere il sito: serve profilare le tre interazioni che gli utenti fanno davvero e togliere il lavoro sincrono dal main thread. È il ritorno sull'investimento più alto che vediamo lato frontend nel 2026.