INP è il Core Web Vital di interattività. ≤ 200 ms al 75° percentile sul campo. Non è FID, ritirato il 9 settembre 2024. Non è lo score di Lighthouse.
FID non è più un Core Web Vital. Dal maggio 2024 la metrica di interattività è INP: Interaction to Next Paint. Non misura solo il primo click. Non è Lighthouse. Verifica del 7 ottobre 2026 su web.dev/articles/inp (last updated 2 settembre 2025).
In breve: buono ≤ 200 ms, da migliorare 200–500, scarso > 500, al 75° percentile sul campo. Click, tap, tasto. Non scroll, non zoom, non hover. FID ha perso il supporto il 9 settembre 2024.
Cosa trovi in questo articolo
INP misura il frame dopo l’interazione, non FID
L’articolo Interaction to Next Paint (INP) su web.dev, published 6 maggio 2022, last updated 2 settembre 2025, rilettura 7 ottobre 2026: INP è «a stable Core Web Vital metric that assesses responsiveness using data from the Event Timing API». Osserva la latenza di tutte le interazioni e riporta un valore sotto il quale stanno tutte, o quasi. Il cluster è Performance. Lighthouse e CrUX restano due mestieri diversi: Lighthouse vs CrUX. Server-Timing è un header del backend, non INP: Server-Timing.
Il glossary MDN, stessa rilettura: INP sostituisce First Input Delay (FID) nel maggio 2024. Due differenze, in pagina: FID guarda solo la prima interazione, INP le considera tutte; FID misura solo l’input delay, INP parte da lì, include i gestori e arriva al presentation time, «until the browser has painted the next frame». Scroll e zoom «are not included». Pagine con 50 o più interazioni: 98° percentile, per escludere gli outlier. Fetch di rete e letture file, in pagina, di solito non ritardano INP: il paint può avvenire mentre quelle operazioni vanno avanti.
web.dev, sezione «What's in an interaction?»: si osservano click del mouse, tap su touchscreen, pressione di un tasto fisico o a schermo. Hover, zoom e scroll non contano, salvo i gesti che contengono un click/tap/tasto. L’INP degli iframe conta per la pagina top-level; le Web API JS non vedono il contenuto degli iframe, quindi CrUX e RUM possono divergere.
200 ms, 500 ms, 75° percentile
web.dev, «What is a good INP score?»: la soglia da misurare è il 75° percentile dei page load sul campo, mobile e desktop separati.
| In pagina (web.dev/articles/inp, agg. 2 settembre 2025) | |
|---|---|
| Buono | INP ≤ 200 millisecondi. |
| Da migliorare | Sopra 200 e ≤ 500 millisecondi. |
| Scarso | Sopra 500 millisecondi. |
| Come si aggrega | 75° percentile sul campo. Non è il peggior click in assoluto se la pagina è molto interattiva (MDN: 98° percentile oltre 50 interazioni). |
| FID | web.dev/articles/fid: non è più Core Web Vital, sostituito da INP. Supporto FID terminato il 9 settembre 2024. Soglia FID «good»: 100 ms. Non si usa più per giudicare l’interattività. |
Stessa pagina INP: Chrome usage data, «90% of a user's time on a page is spent after it loads». Per questo INP guarda l’intero ciclo di vita, non solo il primo input. L’intento «is not to measure all the eventual effects of an interaction» (fetch, aggiornamenti UI asincroni), ma il tempo in cui il rendering successivo resta bloccato.
CrUX e RUM, non lo score di Lighthouse
web.dev/articles/fid, warning in testa, 7 ottobre 2026: «You should now focus on INP». FID misurava solo il ritardo prima che partissero i gestori, non la durata dei gestori né il paint. Un lab report che stampa ancora FID non è la metrica di campo. INP si legge da dati di campo (CrUX, RUM con Event Timing API). Lighthouse, in laboratorio, non sostituisce il 75° percentile reale. CrUX aggrega Chrome; un RUM proprio può vedere iframe e utenti che CrUX non vede, e viceversa.
Tre pezzi di un’interazione, schema web.dev: input delay (main thread occupato, long task), callback dei gestori, delay fino al frame successivo. JavaScript è spesso il motore; checkbox, radio e controlli CSS restano interazioni. Ottimizzare INP non è «alzare lo score Lighthouse»: è accorciare long task, spezzare il lavoro, non fare layout thrashing, non gonfiare il DOM. I dettagli operativi stanno sulle guide collegate in calce all’articolo INP (optimize long tasks, input delay, rendering). Qui conta la distinzione: FID è ritirato; INP è il Core Web Vital; Lighthouse è un altro strumento.
Errori da evitare
Trattare FID come se fosse ancora il Core Web Vital di interattività.
Leggere INP su un report Lighthouse di laboratorio e usarlo al posto del 75° percentile di campo.
Includere scroll, zoom o hover nel calcolo: in pagina non sono osservati.
Confondere INP con LCP (primo paint del contenuto) o con CLS (spostamenti di layout).
Confondere INP con Server-Timing: quello è un header, i millisecondi del backend.
Aspettarsi che un fetch di rete «entri» in INP: in pagina il paint può avvenire prima che la rete finisca.
In sintesi
INP è il Core Web Vital di interattività. ≤ 200 ms al 75° percentile sul campo. Non è FID, ritirato il 9 settembre 2024. Non è Lighthouse. Si rilegge web.dev/articles/inp il giorno in cui si misura. Verifica del 7 ottobre 2026.
