INP: La Nuova Metrica Critica Che Rimpiazza FID
Il 12 marzo 2024, Google ha completato la transizione dei Core Web Vitals: FID (First Input Delay) e uscito, INP (Interaction to Next Paint) e entrato. Un cambiamento silenzioso nei pannelli di Google Search Console che pero ha impatti reali sul ranking SEO di milioni di siti. Secondo i dati del Chrome User Experience Report (CrUX), il 43% dei siti web fallisce ancora la soglia "Good" di INP (sotto i 200ms), un numero significativamente piu alto rispetto al 30% di siti che falliva FID.
FID misurava solo il ritardo al primo input: quanto tempo passava dal momento in cui l'utente cliccava per la prima volta al momento in cui il browser iniziava a processare quell'evento. Era una metrica facile da superare perche misurava solo la prima interazione e non teneva conto del paint successivo. INP e radicalmente diverso: misura la responsivita complessiva per tutta la durata della sessione, scegliendo come punteggio finale il peggior percentile delle interazioni.
Cosa Imparerai
- Come INP differisce da FID e perche misura la responsivita reale
- Le soglie Good/Needs Improvement/Poor di INP (200ms / 500ms)
- Come misurare INP con Chrome DevTools, web-vitals.js e PageSpeed Insights
- I cinque pattern JavaScript piu comuni che fanno esplodere l'INP
- Come interpretare i dati di campo CrUX vs i dati sintetici Lighthouse
- Il workflow di debugging per trovare e correggere interazioni lente
Cosa Misura INP: La Definizione Tecnica
INP osserva tutte le interazioni dell'utente con la pagina durante la visita: click, tap e pressioni di tasto. Per ciascuna interazione, misura il tempo che intercorre dall'input dell'utente al momento in cui il browser dipinge il prossimo frame che riflette la risposta visiva a quell'input. Questo intervallo si chiama interaction latency ed e composto da tre parti:
- Input delay: il tempo che passa prima che il browser inizi a processare l'evento (il main thread era occupato)
- Processing time: il tempo di esecuzione degli event handler JavaScript
- Presentation delay: il tempo necessario al browser per eseguire layout, paint e composite del nuovo frame
INP prende il 98° percentile di tutte le interazioni della sessione (o il peggior valore se ci sono meno di 50 interazioni). Non la media, non il valore tipico: quasi il peggiore. Questo rende INP molto piu sensibile ai picchi di latenza rispetto a FID.
Le Soglie di INP
| Rating | Valore INP | Impatto SEO |
|---|---|---|
| Good | < 200ms | Contribuisce positivamente al ranking |
| Needs Improvement | 200ms - 500ms | Neutro, area di miglioramento |
| Poor | > 500ms | Penalizzazione ranking Google |
FID vs INP: La Differenza Sostanziale
Per capire perche il passaggio da FID a INP e un cambiamento importante, considera questo scenario: hai una pagina di e-commerce. Al primo caricamento, l'utente clicca su "Aggiungi al carrello" e l'evento viene processato in 50ms (FID eccellente). Poi naviga nella pagina, filtra prodotti, apre un dropdown di categorie. Questa seconda interazione prende 800ms perche un heavy computation sta girando sul main thread.
Con FID: il punteggio era 50ms - Good.
Con INP: il punteggio e 800ms - Poor.
INP riflette l'esperienza reale dell'utente durante tutta la sessione, non solo il primo click. Questo e il motivo per cui molti siti che avevano un FID eccellente ora hanno un INP problematico.
Come Misurare INP
1. Chrome DevTools - Performance Panel
Il modo piu preciso per diagnosticare INP e il pannello Performance di Chrome DevTools. Procedi cosi:
- Apri DevTools (F12) e vai al tab Performance
- Clicca il cerchio rosso per avviare la registrazione
- Esegui le interazioni che vuoi misurare (click, typing, ecc.)
- Ferma la registrazione
- Nel pannello risultante, cerca le barre rosse nella sezione Interactions
- Clicca su un'interazione per vedere la breakdown: input delay, processing time, presentation delay
2. Web Vitals JS Library (Field Data)
La libreria web-vitals di Google permette di misurare INP reale degli utenti in produzione.
Aggiungila al tuo progetto e invia i dati a un endpoint di analytics:
import { onINP } from 'web-vitals';
onINP((metric) => {
// metric.value: il valore INP in millisecondi
// metric.rating: 'good' | 'needs-improvement' | 'poor'
// metric.entries: le PerformanceEventTiming entries
console.log('INP:', metric.value, metric.rating);
// Invia a analytics
fetch('/api/vitals', {
method: 'POST',
body: JSON.stringify({
metric: 'INP',
value: metric.value,
rating: metric.rating,
url: window.location.href,
}),
});
});3. PageSpeed Insights e CrUX
PageSpeed Insights mostra i dati CrUX reali per il tuo dominio nella sezione "Field Data". Ricorda che i dati CrUX sono basati su utenti Chrome che hanno abilitato la sincronizzazione, quindi riflettono l'esperienza reale su dispositivi reali, non i risultati sintetici di Lighthouse che girano su hardware controlled.
Dati Lab vs Field Data
Lighthouse e PageSpeed Insights in modalita "Lab" simulano un dispositivo mobile di fascia media su una connessione 4G rallentata. I dati CrUX (Field Data) riflettono gli utenti reali del tuo sito. E normale avere discrepanze del 30-50% tra le due misure. Usa i dati di campo come indicatore primario per le decisioni SEO, e i dati lab per il debugging tecnico.
I Pattern Piu Comuni che Causano INP Elevato
1. Long Tasks sul Main Thread
Il principale colpevole di INP elevato e la presenza di Long Tasks: task JavaScript
che durano piu di 50ms. Ogni Long Task blocca il main thread del browser, impedendogli di rispondere
agli input dell'utente. Il modo piu facile per identificarli e il pannello Performance di DevTools
o l'API PerformanceObserver:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.duration > 50) {
console.warn('Long Task rilevato:', {
duration: entry.duration,
startTime: entry.startTime,
});
}
}
});
observer.observe({ type: 'longtask', buffered: true });2. Event Handler Pesanti
Click handler che eseguono heavy computation sincronamente sono una causa frequente di INP elevato. Il pattern tipico e un handler che:
- Filtra o trasforma grandi array in memoria
- Esegue rendering massivo del DOM (aggiungere centinaia di elementi)
- Calcola layout complessi o forza reflow del browser
- Esegue parsing di JSON di grandi dimensioni
3. React/Angular Change Detection Non Ottimizzata
In framework come React o Angular, un singolo evento puo triggerare un ciclo di change detection che ricalcola l'intero component tree. In componenti complessi o in assenza di memoization appropriata, questo puo richiedere 100-400ms.
In Angular, la soluzione e ChangeDetectionStrategy.OnPush e l'uso di signals per
granular reactivity. In React, React.memo, useMemo e useCallback
sono gli strumenti chiave.
4. Third-Party Scripts
Analytics, chat widget, ad scripts e altri third-party scripts spesso eseguono sul main thread e possono bloccare la risposta agli input. Per identificarli, nel Performance panel di DevTools cerca Long Tasks originati da domini terzi.
5. Hydration nei Framework SSR
In applicazioni con SSR (Next.js, Angular Universal, Nuxt), la fase di hydration puo essere costosa. Durante la hydration, il framework ricollega gli event handler al DOM renderizzato server-side. Se questa fase si sovrappone a un'interazione utente, l'INP ne risente.
Il Workflow di Debugging INP
Ecco il workflow consigliato per diagnosticare e correggere un INP elevato:
- Identifica le interazioni problematiche usando il pannello Performance di DevTools. Cerca le interazioni con latency > 200ms nella sezione Interactions.
- Analizza la breakdown: quale delle tre componenti (input delay, processing, presentation) e la piu grande?
- Se e l'input delay: qualcos'altro stava girando sul main thread al momento del click. Cerca Long Tasks che precedono l'interazione nel timeline.
-
Se e il processing time: i tuoi event handler sono troppo lenti.
Usa
scheduler.yield()per spezzarli (vedi articolo successivo). - Se e il presentation delay: il rendering del frame e lento. Cerca layout thrashing, CSS animations costose, o compositing layers eccessivi.
INP e SEO: L'Impatto Reale
Google ha confermato che i Core Web Vitals, incluso INP, sono fattori di ranking. Il peso esatto non e pubblico, ma l'evidenza empirica mostra che passare da "Poor" a "Good" su INP puo portare miglioramenti di ranking del 2-5% per pagine competitive. Per siti con traffico organico significativo, questo si traduce in aumento di traffico misurabile.
La priorita assoluta deve essere portare tutte le pagine principali (homepage, category pages, product pages) al rating "Good" (< 200ms). Le pagine di contenuto statico raramente hanno problemi INP; i problemi si concentrano su pagine con interfacce interattive complesse.
Next Steps
Ora che sai misurare e identificare i problemi INP, il passo successivo e imparare a
correggerli: il prossimo articolo di questa serie spiega come usare scheduler.yield()
per spezzare i Long Tasks e liberare il main thread tra un'interazione e l'altra.
Per il lato rendering, l'articolo su LCP Optimization copre le tecniche per ridurre il presentation delay e accelerare il paint del primo frame significativo.
Conclusioni
INP rappresenta un cambio di paradigma nella misurazione della performance web: non basta che la pagina si carichi velocemente, deve anche rispondere velocemente per tutta la durata della sessione. Il 43% dei siti che fallisce la soglia Good di INP ha un'opportunita concreta di migliorare sia l'esperienza utente che il ranking SEO.
Il punto di partenza e sempre la misurazione: installa web-vitals.js nel tuo
sito, raccogli i dati reali degli utenti, e usa Chrome DevTools per diagnosticare le interazioni
problematiche. Solo con dati concreti potrai prendere decisioni di ottimizzazione informate.