Performance

INP: cosa misura e come si migliora

INP misura il tempo tra un tocco e il frame che mostra la risposta: buono sotto 200 ms. Le tre fasi, i comandi e le correzioni che alzano il p75.

In sintesi

  • INP misura la latenza dell'interazione, non il ritardo del primo input.
  • La soglia è 200 ms al 75° percentile delle visite, separate per mobile e desktop.
  • Un p75 aggregato nasconde la route lenta: leggi il dato per route e per device.

INP misura il tempo tra un tocco e il frame che mostra la risposta: sotto 200 ms è buono. Non è il ritardo del primo input, e per questo ha sostituito FID il 12 marzo 2024.

Le tre parti della latenza

La latenza di un'interazione si divide in input delay, processing duration e presentation delay. L'input delay arriva dal main thread occupato quando l'utente tocca, il processing è il tuo handler, la presentation è il frame che il browser deve dipingere dopo.

FaseCausa tipicaRiduzione
Input delayTask lungo già in corsoSpezza i task e cedi il main thread
ProcessingHandler che calcola in modo sincronoSposta il calcolo in un worker
PresentationAlbero grande da ridipingereRiduci i nodi e gli stili ricalcolati

Leggere INP dal campo

curl -s -H "x-admin-token: $ADMIN_TOKEN" "https://ui.eneawork.it/api/rum/summary?days=30" | jq '.metrics.INP, .devices.mobile.INP'

L'endpoint restituisce conteggio, p75 e soglia per metrica, più la stessa lettura separata per device. Richiede ADMIN_TOKEN sul server: senza token risponde 503, con un token sbagliato 401.

Misurare una singola interazione

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (!entry.interactionId) continue;
    console.log(entry.name, Math.round(entry.duration), entry.target);
  }
}).observe({ type: "event", durationThreshold: 40, buffered: true });

La soglia minima di durationThreshold è 16 ms e 40 taglia il rumore. Gli eventi senza interactionId, come lo scroll o il movimento del mouse, non sono interazioni e restano fuori dal conteggio.

Tre correzioni che spostano il p75

  • Cedi il main thread dopo 50 ms di lavoro: await scheduler.yield() dove esiste, setTimeout(…, 0) come ripiego.
  • Riduci il JavaScript che parte al caricamento: ogni kilobyte di entry code è lavoro prima che un tocco possa essere gestito.
  • Non idratare interi alberi interattivi: carica il comportamento quando il componente entra nella viewport.

La limitazione da dichiarare

INP è una metrica per visita, non per pagina: una visita lunga pesa quanto una breve e il p75 aggregato nasconde la route lenta. Le nostre 66 letture includono sessioni automatiche, quindi non sostituiscono il Chrome UX Report: leggile per route e per device prima di dichiarare un passaggio.

Dove continuare

Nel catalogo: componenti interattivi, image accordion e blocchi dashboard. Le guide: un import che aumenta il bundle e cosa sono i Core Web Vitals; l'articolo gemello su LCP e il confronto misurato librerie React 2026.

Domande frequenti

INP ha sostituito FID?

Sì. INP è una metrica Core Web Vitals dal 12 marzo 2024 e ha preso il posto di First Input Delay, che misurava solo il ritardo del primo input.

Qual è la soglia di INP?

200 ms al 75° percentile delle visite, separate per mobile e desktop. Sopra 500 ms la pagina è da correggere; fra 200 e 500 ms il valore è intermedio.

Lighthouse misura INP?

No. Lighthouse misura task, TBT e peso del JavaScript, che sono cause di INP ma non INP. Per la reattività serve il dato di campo o una traccia nel pannello Performance.

Perché il mobile ha un INP peggiore?

Perché la CPU è più lenta e il main thread è già occupato dal parsing all'arrivo del primo tocco. Lo stesso handler costa due o tre volte di più su un telefono di fascia media.

Come si misura una singola interazione?

Con un PerformanceObserver sul tipo event, con durationThreshold a 40 ms e il filtro su interactionId. L'entry porta la durata, il tipo e il nodo che ha ricevuto l'evento.