Stai ancora cercando il First Input Delay nei report di Google? Dal 12 marzo 2024 il FID non fa più parte dei Core Web Vitals: al suo posto c’è l’Interaction to Next Paint, la metrica INP Core Web Vitals che misura quanto rapidamente una pagina mostra una risposta visibile a clic, tocchi e tasti per tutta la durata della visita. Un buon INP resta entro 200 millisecondi.
L’INP in breve
- Cos’è: il Core Web Vital che misura la reattività di una pagina a clic, tocchi e pressioni di tasti, dall’azione dell’utente alla risposta visibile.
- Cosa ha sostituito: il First Input Delay (FID), dal 12 marzo 2024.
- Valori: buono entro 200 millisecondi, da migliorare fino a 500, scadente oltre 500.
- Come si calcola: su tutte le interazioni della visita conta la più lenta, scartando i valori anomali; poi si prende il 75° percentile delle visite.
- Le tre fasi: ritardo di input, elaborazione degli eventi, ritardo di presentazione.
- Causa principale di un INP alto: JavaScript che occupa il thread principale del browser con attività lunghe.
- Dove si misura: report Core Web Vitals di Search Console e PageSpeed Insights per gli utenti reali, pannello Prestazioni di Chrome DevTools per i test.
Cos’è l’Interaction to Next Paint (INP)?
L’Interaction to Next Paint (INP) è il Core Web Vital che misura la reattività di una pagina: osserva la latenza di tutti i clic, i tocchi e le pressioni di tasti durante la visita e riporta la più lunga, escludendo i valori anomali. Fa parte dei Core Web Vitals insieme a LCP e CLS.
Il nome spiega che cosa conta: il tempo che passa dall’interazione al "next paint", cioè al primo fotogramma che mostra all’utente un riscontro, come il carrello che si aggiorna o il menu che si apre. Gli effetti che arrivano dopo, per esempio una richiesta al server che si conclude più tardi, restano fuori dal calcolo. Se una fisarmonica non si apre al primo clic, l’utente pensa che la pagina non funzioni e clicca di nuovo: è proprio l’esperienza che l’INP vuole intercettare. Secondo i dati di utilizzo di Chrome riportati nella guida di web.dev a questa metrica, poi, il 90% del tempo che un utente passa su una pagina arriva dopo il caricamento.
Ottimizzazione siti web
Core Web Vitals misurati sui dati reali e interventi per rendere il sito più veloce.
INP Core Web Vitals: Qual è un Buon Valore?
Un INP entro 200 millisecondi è buono; tra 200 e 500 millisecondi richiede miglioramenti; oltre 500 millisecondi è scadente. Conta il valore del 75° percentile, calcolato a parte per smartphone e per desktop sulle visite reali: almeno tre visite su quattro devono restare sotto la soglia.
- Buono: fino a 200 millisecondi.
- Richiede miglioramenti: da 200 a 500 millisecondi.
- Scadente: oltre 500 millisecondi.
Come si Calcola l’INP?
L’INP si calcola osservando tutte le interazioni di una visita: per la maggior parte delle pagine il valore è quello dell’interazione più lenta, mentre sulle pagine con molte interazioni se ne scarta una delle più lente ogni 50, per non farsi ingannare da un singolo intoppo. Il valore della pagina è poi il 75° percentile di tutte le visite.
Ogni interazione è un gruppo di eventi generati dallo stesso gesto: un tocco, per esempio, produce gli eventi pointerdown, pointerup e click: conta quello che impiega più tempo. Il valore della visita si chiude quando l’utente lascia la pagina.
Quali Interazioni Conta l’INP?
L’INP considera tre tipi di interazione: il clic del mouse, il tocco su uno schermo touch e la pressione di un tasto su una tastiera fisica o virtuale. Il passaggio del mouse, lo scroll e lo zoom non vengono considerati. Rientrano invece le interazioni dentro gli iframe, per esempio con un video incorporato.
Perché una Pagina Può Non Avere un Valore INP?
Una pagina resta senza valore INP quando nessuna visita ha registrato clic, tocchi o tasti, per esempio perché gli utenti si sono limitati a scorrere, oppure quando le visite sono di bot. Nel report di Search Console, i gruppi di URL senza dati INP sufficienti vengono valutati solo su LCP e CLS.
Le Tre Fasi di un’Interazione
Ogni interazione si divide in tre fasi: il ritardo di input, prima che partano i gestori degli eventi; la durata di elaborazione, mentre il loro codice viene eseguito; il ritardo di presentazione, fino al disegno del fotogramma successivo.
- Ritardo di input: il browser è ancora occupato con altro, per esempio con script che si caricano, timer o un’interazione precedente, quindi non può iniziare a gestire il gesto.
- Elaborazione: viene eseguito il codice dei gestori degli eventi; si allunga con logiche pesanti e con i ricalcoli del layout forzati dal codice.
- Presentazione: il browser ricalcola stili e layout e disegna il nuovo fotogramma; pesa di più con un DOM molto grande o con molto HTML generato da JavaScript.
Che Differenza c’è tra INP e FID?
Il FID misurava solo il ritardo della prima interazione; l’INP misura tutte le interazioni della visita e la loro durata completa, fino alla risposta visibile. È quindi una metrica più severa e più vicina a ciò che l’utente percepisce.
Cos’era il First Input Delay?
Il First Input Delay (FID) misurava il tempo tra la prima interazione dell’utente con la pagina, come il clic su un link o il tocco su un pulsante, fino al momento in cui il browser poteva iniziare a elaborare la risposta. Era considerato buono entro 100 millisecondi ed era entrato nei Core Web Vitals nel 2020. Non misurava né l’esecuzione del codice né l’aggiornamento della pagina: solo l’attesa iniziale.
Perché Google Ha Sostituito il FID?
I limiti del FID erano nel suo stesso nome: "first input", cioè solo la prima interazione; "delay", cioè solo l’attesa prima dell’elaborazione. Per questo faceva sembrare reattivi siti che non lo erano: secondo i dati pubblicati da web.dev a maggio 2023, su mobile il 93% dei siti aveva un FID buono, ma solo il 65% un INP buono.
Quando è Avvenuto il Passaggio dal FID all’INP?
- 2022: Google presenta l’INP come metrica sperimentale.
- 10 maggio 2023: arriva l’annuncio che l’INP prenderà il posto del FID a marzo 2024.
- 12 marzo 2024: il FID esce dai Core Web Vitals e dal report di Search Console, sostituito dall’INP.
- 9 settembre 2024: finisce il periodo di transizione; da allora PageSpeed Insights e il Chrome UX Report non mostrano più il FID.
Date e dettagli del passaggio sono nel post di Google Search Central Introduzione della metrica INP in Core Web Vitals, aggiornato il giorno della sostituzione.
Come si Misura l’INP?
L’INP si misura soprattutto sul campo, sulle visite reali che Chrome raccoglie nel Chrome UX Report e che Search Console e PageSpeed Insights riportano; in laboratorio si riproducono le interazioni lente con il pannello Prestazioni di Chrome DevTools.
- Search Console: il report Core Web Vitals raggruppa gli URL simili e segnala quelli con INP da migliorare o scadente, sui dati degli ultimi 28 giorni.
- PageSpeed Insights: mostra l’INP al 75° percentile della singola pagina o, se i dati sono pochi, dell’intera origine.
- Chrome DevTools: il pannello Prestazioni mostra l’INP dal vivo mentre usi la pagina, senza registrare, con l’elenco delle interazioni e la latenza di ciascuna; registrando una traccia vedi quale codice rallenta la risposta.
- Monitoraggio degli utenti reali: il Chrome UX Report dice se c’è un problema, ma non quale interazione lo causa; per saperlo servono strumenti RUM o la libreria web-vitals con i dati di attribuzione.
Lighthouse, nel test standard, carica la pagina senza interagire e quindi non misura l’INP: al suo posto mostra il Total Blocking Time (TBT), il tempo in cui il thread principale resta bloccato da attività più lunghe di 50 millisecondi. È un indicatore utile, ma non sostituisce i dati reali. L’articolo sul test dei Core Web Vitals spiega come usare questi strumenti uno per uno.
Come Migliorare l’INP?
Per migliorare l’INP bisogna lasciare libero il thread principale del browser: spezzare le attività JavaScript lunghe, eliminare il codice superfluo e ridurre il lavoro di rendering dopo ogni interazione. Conviene partire dalle interazioni lente reali, sapendo quale elemento e quale fase le rallentano, invece che da una lista generica di ottimizzazioni. La guida di web.dev per ottimizzare l’INP descrive le tecniche nel dettaglio.
Spezzare le Attività Lunghe
Ogni attività che occupa il thread principale per più di 50 millisecondi è un’attività lunga: finché non termina, il browser non può rispondere all’utente. Il lavoro va diviso in parti più piccole, restituendo il controllo al browser tra una parte e l’altra, per esempio con setTimeout o con scheduler.yield(). Dopo un’interazione conviene eseguire subito solo ciò che aggiorna l’interfaccia e rinviare il resto a dopo il fotogramma successivo.
Ridurre il JavaScript e gli Script di Terze Parti
Meno codice da scaricare, analizzare ed eseguire significa un thread principale più libero, soprattutto durante il caricamento, quando gli utenti iniziano a interagire. Controlla i tag di marketing, le chat, i widget e gli strumenti di A/B test: possono occupare il browser proprio quando l’utente interagisce. Gli stessi script ritardano anche il Largest Contentful Paint, cioè il rendering dell’elemento principale.
Alleggerire il Rendering
Un DOM molto grande rende costoso ogni aggiornamento della pagina: riduci il numero di elementi, evita di leggere e modificare gli stili nella stessa attività, che costringe il browser a ricalcolare il layout più volte; limita poi l’HTML generato da JavaScript nel browser.
L’INP Conta per la SEO?
Sì, l’INP fa parte dei segnali sull’esperienza della pagina che Google usa nel ranking, insieme a LCP e CLS; un valore buono però non basta a salire nei risultati se il contenuto non è il più pertinente per la ricerca.
Le Interazioni da Cercare per Prime
Con il passaggio dal FID all’INP l’attenzione si è spostata dalla prima attesa all’intera visita: a pesare sono l’interazione più lenta e il tempo fino alla risposta visibile. Le interazioni da cercare per prime stanno nelle pagine in cui l’utente deve fare qualcosa, come filtri, carrelli, moduli e configuratori, dove JavaScript e script di terze parti tengono occupato il thread principale.
Individuare le interazioni lente sui dati reali e in laboratorio, ordinare le correzioni per impatto e verificarne l’effetto nei report fa parte della nostra ottimizzazione dei siti web: se le pagine del tuo sito rispondono lente a clic e tocchi, mettiti in contatto con noi per una verifica sui dati reali.
Domande Frequenti sull’Interaction to Next Paint
Cos’è l’INP nei Core Web Vitals?
È l’Interaction to Next Paint, la metrica che misura quanto rapidamente una pagina mostra una risposta visibile a clic, tocchi e pressioni di tasti durante tutta la visita. Dal 12 marzo 2024 è uno dei tre Core Web Vitals, al posto del First Input Delay.
Come si calcola l’INP?
Si osservano tutte le interazioni della visita e si prende la più lenta; sulle pagine con molte interazioni se ne scarta una delle più lente ogni 50. Il valore della pagina è il 75° percentile di tutte le visite, separatamente per smartphone e desktop.
Qual è un buon valore di INP?
Fino a 200 millisecondi è buono, tra 200 e 500 millisecondi richiede miglioramenti, oltre 500 millisecondi è scadente. Conta il valore al 75° percentile delle visite reali, calcolato a parte per smartphone e per desktop.
Che differenza c’è tra INP e FID?
Il FID misurava solo il ritardo prima che il browser iniziasse a gestire la prima interazione; l’INP misura tutte le interazioni, dal gesto dell’utente fino al fotogramma che mostra il risultato.
Il First Input Delay si usa ancora?
No. Dal 12 marzo 2024 il FID è uscito dai Core Web Vitals e da settembre 2024 non compare più negli strumenti di Google, come PageSpeed Insights e il Chrome UX Report; resta misurabile con le API del browser, ma non fa più parte della valutazione dei Core Web Vitals.
Si può misurare l’INP con Lighthouse?
Nel test standard no, perché Lighthouse carica la pagina senza interagire: mostra il Total Blocking Time come indicatore. L’INP si misura sui dati reali o interagendo con la pagina nel pannello Prestazioni di Chrome DevTools.
Perché una pagina non ha dati INP?
Perché nessuna visita ha registrato clic, tocchi o tasti, per esempio solo scroll, perché la pagina ha troppo poco traffico per il Chrome UX Report o perché le visite sono di bot.
Cosa peggiora l’INP?
Soprattutto il JavaScript che occupa a lungo il thread principale: script pesanti durante il caricamento, codice di terze parti, gestori di eventi lenti e DOM molto grandi, che rendono costoso ogni aggiornamento della pagina.
Iscriviti alla newsletter
Ricevi la newsletter via email. Puoi disiscriverti quando vuoi.