23 LUG 2026

INP, la nuova metrica dei Core Web Vitals: cosa misura e come si risolve

Da marzo 2024 c’è una sigla in più da tenere d’occhio: INP. Ha preso il posto di un’altra metrica, FID, tra i Core Web Vitals di Google — i tre parametri con cui il motore misura l’esperienza reale di chi naviga. Il cambio non è cosmetico: molti siti che passavano l’esame con FID si ritrovano ora in difficoltà con INP, perché la nuova metrica è più severa e cattura problemi che prima restavano invisibili. Vediamo cosa misura davvero INP, perché il vostro sito può sembrare veloce e non superarla, e le mosse concrete per rientrare nei valori buoni.

Cos’è INP e perché ha sostituito FID.

INP sta per Interaction to Next Paint, «interazione fino al prossimo disegno». In parole semplici misura la reattività: quando toccate un pulsante, aprite un menu o scrivete in un campo, quanto tempo passa prima che lo schermo risponda mostrando il risultato. È una delle tre metriche dei Core Web Vitals, insieme a LCP (velocità di caricamento) e CLS (stabilità visiva).

Fino al marzo 2024 la reattività si misurava con FID, che però guardava solo il ritardo della primissima interazione — e per giunta solo l’attesa iniziale, non l’intera risposta. INP è più onesta: osserva tutte le interazioni durante la visita e considera la più lenta, dall’inizio del tocco fino a quando la pagina mostra davvero il cambiamento. Per questo molti siti «promossi» con FID si scoprono ora lenti con INP: la nuova metrica misura ciò che l’utente sente davvero.

Cosa misura davvero, e le soglie di Google.

Le soglie sono chiare. Un INP sotto i 200 millisecondi è considerato buono: la pagina risponde in modo che l’utente percepisce come immediato. Tra 200 e 500 millisecondi c’è margine di miglioramento; sopra i 500 millisecondi l’esperienza è scadente e si nota, quel micro-ritardo fastidioso tra il clic e la reazione. Google valuta il 75° percentile: non basta che sia veloce «in media», deve esserlo per la grande maggioranza delle interazioni reali.

E qui sta il punto: reali. Google giudica i Core Web Vitals sui dati «sul campo», raccolti dagli utenti veri di Chrome (il Chrome UX Report), non sulle prove di laboratorio fatte una volta sola dal vostro computer nuovo su una connessione ottima. Ecco perché un test onesto guarda ai numeri del campo: è l’esperienza dei vostri visitatori con i loro telefoni e le loro reti, non quella ideale.

Misura gratis i Core Web Vitals reali del vostro sito →

Perché un sito «sembra» veloce ma fallisce INP.

Un sito può caricarsi in un lampo e poi impuntarsi al primo tocco. Il colpevole quasi sempre è lo stesso: troppo JavaScript che tiene occupato il «thread principale» del browser, quello che deve anche rispondere ai vostri clic. Se un pezzo di codice lavora a lungo senza pause, l’interazione resta in coda ad aspettare — e quel millisecondo di attesa è esattamente ciò che INP misura. Il caricamento è finito da un pezzo, ma la pagina «non risponde».

Le cause tipiche sono note: script di terze parti pesanti (chat, banner, tracker, widget), temi e plugin che caricano librerie enormi anche dove non servono, gestori di eventi che fanno troppo lavoro a ogni clic. Sono cose che nei test di velocità classici, tutti concentrati sul caricamento, non emergevano. INP le porta a galla: misura il momento in cui l’utente prova a usare il sito, non solo quello in cui lo guarda comparire.

Come si risolve INP.

La strategia è una: alleggerire e spezzare il lavoro del browser. Ridurre il JavaScript inutile e caricare in ritardo ciò che non serve subito; spezzare le operazioni lunghe in pezzi brevi, così tra uno e l’altro il browser può rispondere ai tocchi; tenere sotto controllo gli script di terze parti, che spesso pesano più del sito stesso. Sono interventi tecnici, ma l’effetto lo sente chiunque: la pagina reagisce all’istante.

Il metodo giusto è misurare prima e dopo, sempre sui dati reali. Si parte identificando le interazioni più lente su smartphone (dove i processori sono più deboli e i problemi si vedono meglio), si interviene sul codice che le rallenta e si verifica che l’INP al 75° percentile scenda sotto la soglia buona. Non è magia: è togliere peso finché la pagina non risponde come dovrebbe.

La reattività è un investimento, non un dettaglio.

INP non è l’ennesima sigla per far felice Google: è la misura di una frustrazione concreta, quel mezzo secondo in cui il sito «non fa niente» dopo che l’avete toccato. Su mobile, dove ormai avviene la maggior parte delle visite, è la differenza tra un sito che sembra un’app e uno che sembra rotto. E siccome pesa sui Core Web Vitals, tocca anche il posizionamento: reattività e visibilità viaggiano insieme.

Nei nostri progetti la reattività non è una toppa dell’ultimo minuto: nasce dalle scelte tecniche, meno codice inutile e script di terze parti tenuti a bada, fin dal primo giorno. Un sito veloce a caricarsi ma lento a rispondere è una promessa mantenuta a metà — e INP, finalmente, la mette nero su bianco.

La SEO tecnica che parte dalla velocità reale →

Leggi anche: Core Web Vitals nel 2026, cosa misura Google →

Leggi anche: immagini e velocità, WebP e lazy-load →

Fonti.

Le cifre e le affermazioni di questo articolo vengono da qui. Sono prime fonti, non riassunti: apritele e verificate.

• web.dev — Interaction to Next Paint (INP)La definizione ufficiale della metrica e delle sue soglie, con la spiegazione del passaggio da FID a INP nel 2024.
• web.dev — ottimizzare l’INPLa guida pratica per migliorare la reattività: ridurre e spezzare il lavoro del thread principale, gestire i gestori di eventi.
• web.dev — Core Web Vitals (Google)Le tre metriche (LCP, INP, CLS), le soglie e perché contano: l’esperienza reale, non i numeri di laboratorio.
• Chrome UX Report (CrUX) — documentazioneLa fonte dei dati «sul campo»: utenti reali di Chrome, su cui Google valuta i Core Web Vitals al 75° percentile.

Misura gratis i Core Web Vitals del vostro sito →