Da quando l'INP (Interaction to Next Paint) ha sostituito FID come Core Web Vital nel marzo 2024, abbiamo misurato decine di siti in produzione. Due anni dopo, il quadro è chiaro: l'INP è la metrica che separa siti percepiti veloci da siti percepiti lenti. L'LCP, da molti considerato la "vera" metrica di velocità, è in larga parte un problema risolto sui siti curati. Quello che fa la differenza oggi è la responsività dell'interazione.
Cosa misura l'INP
L'INP misura il peggior tempo di risposta di una pagina alle interazioni dell'utente: click, tap, pressione tastiera. Non il primo, non la media: il p98 sulle interazioni della sessione. Se l'utente clicca dieci volte e una di quelle clicca freezna l'interfaccia per 800ms, l'INP è 800ms.
I threshold:
- Buono: ≤ 200 ms
- Da migliorare: 201-500 ms
- Scarso: > 500 ms
Le cinque cause più comuni di INP alto
1. Bundle JavaScript pesanti caricati al click
Un click che apre un modale che a sua volta carica un componente lazy: se il componente è 200 KB, il browser blocca il main thread per parsing/eval. Il fix è preloadare i componenti critici via <link rel="modulepreload"> e ridurre il bundle.
2. Handler sincroni lunghi
Un onClick che fa loop su 5.000 elementi DOM blocca tutto. La regola: ogni handler deve restituire il controllo al browser entro 50ms. Per operazioni lunghe, scheduler.yield() (Chrome 129+) o requestIdleCallback.
3. Re-render React costosi
Un click che aggiorna lo state e fa re-renderizzare 500 componenti senza memoization spara l'INP. Il React Compiler in v19 aiuta molto, ma non sostituisce un'analisi mirata con React DevTools Profiler.
4. Listener globali che intercettano ogni evento
Tracciamento, analytics, A/B testing: spesso intercettano click globalmente. Quando ce ne sono tre o quattro sovrapposti, l'INP cresce silenziosamente.
5. Animazioni JavaScript invece che CSS
Animare top/left con JS è anni '90. Animare transform e opacity con CSS è decenni avanti. Ogni anno troviamo siti dove l'animation library di turno fa più danni del marketing che voleva animare.
Strumenti nuovi del 2025-26 che aiutano
View Transitions API
Animazioni di navigazione native, gestite dal browser. Niente più libraries pesanti per fade tra route. Supportate ora su Chromium e Safari, in arrivo su Firefox.
Speculation Rules API
Permette di prefetchare o prerendere pagine in anticipo, in modo dichiarativo. Per i siti editoriali e e-commerce, riduce il LCP a quasi zero sulle navigazioni interne.
scheduler.yield()
Una primitiva del browser per cedere il controllo al main thread in modo cooperativo. Sostituisce con eleganza i pattern setTimeout(fn, 0) o requestAnimationFrame usati come yield.
I numeri del CrUX 2026
Dai dati pubblici di Chrome UX Report del Q1 2026:
- Siti italiani con INP "buono": 53% — su 47% di un anno fa.
- Siti italiani con LCP "buono": 76% — stabile.
- Siti italiani con CLS "buono": 81% — stabile.
L'INP è dove c'è ancora margine. È anche dove i frontend mal scritti si vedono: nessuna ottimizzazione di immagine può salvarti se il tuo bundle JS si bevve mezzo secondo a ogni click.
La nostra checklist 2026
- Bundle JS sotto i 150 KB gzipped per la pagina iniziale.
- Code splitting per route e per interazioni rare.
- React Compiler attivo o memoization manuale dove conta.
- scheduler.yield() per qualsiasi handler oltre 50ms.
- View Transitions per le navigazioni.
- Speculation Rules per prerender link probabili.
- Audit dei listener globali ogni 6 mesi.
La performance non è un'ottimizzazione che si fa una volta. È una disciplina continua — e nel 2026, una di quelle che fa la differenza tra un sito che vende e uno che fa scappare gli utenti dopo il primo click.