Interaction to Next Paint o INP, il nuovo Core Web Vitals di Google

Tempo di lettura : 18 minuti

Se ne parla esattamente da un anno, ma oggi ne abbiamo la conferma ufficiale (anche se dobbiamo avere ancora pazienza prima dell’applicazione pratica): a partire dal prossimo mese di marzo 2024 INP o Interaction to Next Paint diventerà la metrica Core Web Vital per la reattività, in sostituzione di FID. Dopo un lungo lavoro di test e raccolta di feedback dalla community, infatti, il Google’s Chrome Team è pronto a “togliere le rotelle alla bici” di INP, che non più solo sperimentale ma diventa pienamente effettiva e quasi operativa in termini di ranking.

La nuova metrica per la reattività: INP

A presentare per la prima volta INP è stato nel 2022 un articolo di Jeremy Wagner su blog.dev, ma l’attenzione è salita dopo che la metrica è stata annunciata ufficialmente anche nel corso di Google I/O 2022, con l’intervento di Annie Sullivan e Michal Mocny incentrato proprio sul tema della responsiveness e sulle azioni intraprese da Google per tendere a un generale miglioramento dell’ecosistema web su tale fronte.

Al termine di dodici mesi di test e utilizzo sperimentale, durante i quali la metrica è stata resa ampiamente disponibile negli strumenti di Google con tanto lavoro di dialogo con la community per verificarne l’efficacia, in queste ore è arrivata la notizia che già si intravedeva, ovvero che Interaction to Next Paint è pronto a sostituire First Input Delay tra i Core Web Vitals di Google, come spiegano Rick Viscomi e Annie Sullivan.

Tutto gira (ancora) intorno al concetto di Core Web Vitals, il set di metriche introdotte nel 2020 da Google per consentire di valutare concretamente e in modo oggettivo e misurabile l’esperienza vissuta dagli utenti sulle pagine di un sito. Allora fu Ilya Grigorik, Web Performance Engineer, a presentare il progetto e a svelare le prime tre metriche scelte per misurare le prestazioni delle pagine, anticipando che l’elenco sarebbe stato sottoposto a controllo periodico. Fast forward fino a oggi, perché effettivamente stiamo per fare la conoscenza di un nuovo segnale web essenziale, per l’appunto Interaction to Next Paint o INP, che misura la reattività delle pagine, ovvero la capacità di rispondere agli input degli utenti.

Che cosa significa Interaction to Next Paint

Interaction to Next Paint o INP (in italiano interazione fino alla successiva visualizzazione) è la metrica che valuta la reattività, registrando la latenza di tutte le interazioni durante l’intero ciclo di vita della pagina; l’INP della pagina è registrato come il valore più alto di queste interazioni o il valore più vicino al più alto per le pagine con molte interazioni, e un valore INP basso garantisce che la pagina sia sempre reattiva in modo affidabile.

Si tratta quindi di una metrica del ciclo di vita a pagina intera, proprio come Cumulative Layout Shift, e quindi misura tutte le interazioni, non solo la prima, cambiando e aggiornandosi continuamente durante l’intero ciclo di vita della pagina; inoltre, come nel caso di CLS, non si registra un valore di INP fino a quando l’utente non lascia la pagina.

INP viene anche definita reattività di runtime (runtime responsiveness) per differenziarla dalla semplice reattività di caricamento, e in termini pratici misura l’intera latenza di input, da quando un utente interagisce fino a quando non vede effettivamente una risposta visiva, non solo il ritardo iniziale sul thread principale.

Che cos’è la reattività e perché è importante per un sito

Wagner approfondiva anche il significato di responsiveness, un valore che stima la velocità con cui una pagina risponde agli input dell’utente ed è fondamentale per l’interazione positiva delle persone con le pagine.

I dati di utilizzo di Chrome mostrano che circa il 90% del tempo trascorso da un utente su una pagina viene appunto trascorso dopo il caricamento della stessa: pertanto, un’attenta misurazione della reattività è importante, soprattutto se si considera che un numero sempre maggiore di siti web si affida a JavaScript per fornire interattività, e INP misura questo aspetto comprendendo come detto l’intero ciclo di vita di una pagina.

Quando la reattività è buona, le pagine rispondono rapidamente alle interazioni degli utenti: quando un’applicazione risponde alle interazioni, i cambiamenti nell’interfaccia utente che ne derivano sono un feedback visivo che “ci dice, ad esempio, se un articolo che abbiamo chiesto di aggiungere al carrello di un sito viene effettivamente aggiunto, se il contenuto di un modulo di login viene autenticato dal server, se un menu mobile si è aperto e così via”.

Alcune interazioni richiedono naturalmente più tempo di altre, ma per interazioni particolarmente complesse è importante presentare rapidamente un feedback visivo iniziale che segnali all’utente che “sta accadendo qualcosa”. Il tempo fino al paint successivo è la prima opportunità per farlo. Pertanto, l’intento di INP non è quello di misurare tutti gli eventuali effetti dell’interazione (come i recuperi di rete e gli aggiornamenti dell’interfaccia utente da altre operazioni asincrone), ma il tempo in cui il disegno successivo viene bloccato. Ritardando il feedback visivo, potremmo dare agli utenti l’impressione che la pagina non risponda alle loro azioni.

L’obiettivo pratico di INP è garantire che il tempo da quando un utente avvia un’interazione fino a quando viene disegnato il frame successivo sia il più breve possibile, per tutte o la maggior parte delle interazioni effettuate dall’utente.

Il video chiarisce questi aspetti, mostrando una rappresentazione visiva di reattività scarsa e buona: a sinistra, lunghi task bloccano l’apertura dell’accordion, e ciò fa sì che l’utente faccia clic più volte, pensando che l’esperienza sia interrotta. Quando il thread principale si mette alla pari, elabora anche gli input ritardati, provocando l’apertura e la chiusura imprevista del menu a fisarmonica.

Una migliore metrica per misurare la reattività

First Input Delay è “un’ottima metrica per misurare la reattività dell’input durante il caricamento della pagina”, dicono i Googler, e quando è stato aggiunto ai Core Web Vitals nel 2020 rappresentava “un enorme passo avanti” rispetto agli strumenti precedenti, perché offriva agli sviluppatori un nuovo modo per misurare la reattività nel modo in cui la sperimentano gli utenti reali del sito. A differenza di metriche simili che “approssimano solo l’interattività della pagina, come Total Blocking Time (TBT) e Time To Interactive (TTI)”, specificano Viscomi e Sullivan, “FID misura direttamente l’esperienza dell’utente”: fondamentalmente, una pagina potrebbe avere TBT o TTI lenti ed essere comunque percepita come reattiva, a causa del modo in cui gli utenti reali interagiscono con la pagina.

Anche se ha effettivamente migliorato il modo in cui misuriamo la reattività, FID non è stato privo di limitazioni, e c’è un altro aspetto che ne ha decretato quella che possiamo definire obsolescenza: il Web continua a diventare più veloce e capace e gli utenti si aspettano interfacce più ricche e interattive, pertanto guardare solo alla reattività durante il caricamento della pagina non racconta l’intera storia. Serve un approccio più olistico alla misurazione della reattività e INP va proprio in questa direzione.

Il nome stesso FID rivela immediatamente le prime due limitazioni: “primo input” e “ritardo”. FID riporta solo la reattività della prima volta in cui un utente interagisce con la pagina. Anche se le prime impressioni sono importanti, la prima interazione non è necessariamente rappresentativa di tutte le interazioni nel corso della vita di una pagina, spiega la guida. Inoltre, FID misura solo la porzione di ritardo di input della prima interazione, che è la quantità di tempo che il browser ha dovuto attendere (a causa dell’occupazione del thread principale) prima ancora di iniziare a gestire l’interazione.

Tutto ciò è stato analizzato e ha portato all’introduzione di INP che, anziché misurare solo la prima interazione, tiene conto di tutte le interazioni, segnalando una delle più lente nell’intera durata della pagina. E, invece di misurare solo la porzione di ritardo, INP misura l’intera durata dall’inizio dell’interazione, attraverso il gestore di eventi, e fino a quando il browser non è in grado di disegnare il frame successivo – processo che chiarisce il nome interazione fino alla successiva visualizzazione. Questi dettagli di implementazione rendono INP una misura molto più completa della reattività percepita dall’utente rispetto a FID.

Cosa significa l’introduzione di INP tra i CWV per proprietari di siti e strumenti di analisi

Prima di entrare nei dettagli tecnici su INP può essere utile rileggere anche quello che ha scritto Martin Splitt, Developer Relations Engineer del team di Google Search Relations, che si è soffermato sull’impatto che la rivoluzione dei Core Web Vitals può avere sui report della Search Console e su chi opera alle ottimizzazioni di un sito.

Come detto, la notizia clou è che a marzo 2024 INP sostituirà FID come parte dei Core Web Vitals. Per aiutare i proprietari di siti e gli sviluppatori a prendere le misure necessarie e valutare le loro pagine per la nuova metrica, Search Console includerà INP nel rapporto Core Web Vitals già entro la fine di quest’anno, per poi smetterà di mostrare le metriche FID al momento della “sostituzione” definitiva e utilizzare unicamente INP come metrica per la reattività, in aggiunta a si unirà a Largest Contentful Paint (LCP) e Cumulative Layout Shift (CLS) che invece restano confermate.

Dal punto di vista applicativo, chi sta già lavorando per migliorare il sito nel rispetto dei Core Web Vitals ha già considerato la reattività delle pagine e, secondo Splitt, i miglioramenti apportati per FID sono una buona base per migliorare l’INP e la responsiveness. Raggiungere buoni Core Web Vitals può contribuire ad avere successo con la ricerca e a garantire un’ottima esperienza utente in generale, aggiunge il Googler, ma “un’ottima esperienza di pagina implica più dei Core Web Vitals e buone statistiche all’interno del rapporto Core Web Vitals in Search Console o rapporti Core Web Vitals di terze parti non garantiscono un buon posizionamento”.

La definizione di INP e il valore della metrica

L’originario articolo di Wagner spiegava nei dettagli come funziona INP e come misurarlo, offrendo anche una serie di primi suggerimenti per migliorare il valore, partendo dall’assunto che una buona reattività è indispensabile per garantire una buona esperienza utente – l’aspetto della ottimizzazione tecnica di INP è stato poi ulteriormente sviscerato in un successivo approfondimento.

Riprendendo la definizione, Interaction to Next Paint è una metrica che mira a rappresentare la latenza complessiva delle interazioni di una pagina selezionando una delle singole interazioni più lunghe che si verificano quando un utente visita una pagina.

Per le pagine con meno di 50 interazioni in totale, INP è l’interazione con la latenza peggiore; per le pagine con molte interazioni, INP è spesso il 98° percentile della latenza di interazione.

Ad oggi (2023), ci ha poi detto Google, il 93% dei siti ha buone prestazioni FID sui dispositivi mobili, ma solo il 65% dei siti ha un buon INP sui dispositivi mobili: visto che, come detto, INP dipinge un quadro molto più accurato della reattività, questi numeri ci aiutano a vedere più chiaramente il margine di miglioramento che abbiamo davanti.

Come si misura INP

Tornando alle definizioni di base, un’interazione è un insieme di eventi di input correlati che si attivano durante lo stesso gesto logico dell’utente: ad esempio, le interazioni “tap” su un dispositivo touchscreen includono più eventi, come alzare il puntatore, abbassare il puntatore e il clic, che possono contribuire alla latenza complessiva dell’interazione.

La latenza di una singola interazione consiste nella durata più lunga di ogni evento che fa parte dell’interazione, dove la durata è misurata dal momento in cui l’utente ha interagito con la pagina fino alla presentazione del fotogramma successivo dopo l’esecuzione di tutti i gestori di eventi associati.

La durata è la somma dei seguenti tempi:

• Il ritardo di input (input delay), ovvero il tempo che intercorre tra il momento in cui l’utente interagisce con la pagina e l’esecuzione dei gestori di eventi.
• Il tempo di elaborazione (processing time), ovvero il tempo totale necessario per eseguire il codice nei gestori di eventi associati.
• Il ritardo di presentazione (presentation delay), ovvero il tempo che intercorre tra il termine dell’esecuzione dei gestori di eventi e la presentazione del fotogramma successivo da parte del browser.

In linea di massima, un INP basso significa che la pagina è stata costantemente in grado di rispondere rapidamente a tutte, o alla stragrande maggioranza, delle interazioni dell’utente.

Calcolare INP: quali sono i valori ottimali

Secondo Wagner, attribuire etichette come “buono” o “scarso” a una metrica di reattività è difficile: da un lato, Google vuole incoraggiare lo sviluppo di esperienze utente che offrano una buona reattività, ma d’altro canto è necessario tenere conto del fatto che esiste una notevole variabilità nelle capacità dei dispositivi utilizzati dalle persone, e stabilire di conseguenza aspettative realmente realizzabili selezionando un obiettivo che non sia impossibile da raggiungere sui dispositivi di fascia bassa.

Alla luce di questo, è importante che la metrica della reattività sia appropriata per i casi d’uso più disparati e per essere certi di raggiungere questo obiettivo, una buona soglia da misurare è il 75° percentile dei caricamenti di pagina registrati sul campo, segmentati tra dispositivi mobili e desktop:

• Un valore INP inferiore o pari a 200 millisecondi significa che la pagina ha una buona reattività.
• Un INP superiore a 200 millisecondi e inferiore o pari a 500 millisecondi significa che la reattività della pagina deve essere migliorata.
• Un INP superiore a 500 millisecondi significa che la reattività della pagina è scarsa.

Tuttavia, essendo INP una metrica sperimentale, le indicazioni relative alle soglie possono cambiare nel tempo man mano che la metrica viene messa a punto, avvisa l’articolo.

Cosa c’è in un’interazione?

Diventa a questo punto utile comprendere anche cosa si intenda per interazione, e Wagner si sofferma particolarmente su questo aspetto.

Quando si interagisce con una pagina, il motore dell’interattività è spesso JavaScript, anche se i browser forniscono anche interattività attraverso controlli non gestiti da JavaScript, come le caselle da spuntare, i pulsanti di opzione, l’elemento HTML <details> e così via.

Per quanto riguarda l’Interaction to Next Paint, un’interazione consiste in una delle seguenti azioni:

• Fare clic con il mouse su un elemento interattivo.
• Toccare un elemento interattivo su un dispositivo dotato di touchscreen.
• Premere un tasto su una tastiera fisica o su schermo.

Un’interazione può essere composta da più eventi – ad esempio, la pressione di un tasto è composta dagli eventi keydown e keyup (maiuscola/minuscola o altri caratteri raggiungibili dallo stesso tasto) e le interazioni di tocco contengono gli eventi pointerup e pointerdown (alzare e abbassare il puntatore) – e tutti gli eventi di un’interazione fanno parte di una cosiddetta interazione logica dell’utente (logical user interaction).

Ogni interazione è composta da tre fasi: il ritardo di immissione, il tempo di elaborazione e il ritardo di presentazione, e l’immagine sopra mostra le fasi di una singola interazione. Il ritardo di input si verifica dal momento in cui viene ricevuto un input e può essere causato da fattori quali il blocco delle attività sul thread principale. Il tempo di elaborazione è il tempo necessario per l’esecuzione dei gestori di eventi dell’interazione. Al termine dell’esecuzione c’è il ritardo di presentazione, che è il tempo necessario per eseguire il rendering e dipingere il fotogramma successivo.

La durata dei callback degli eventi associati a un’interazione è la somma dei tempi delle tre fasi; viene registrato l’evento con la durata maggiore nell’interazione logica dell’utente.

Analogamente al CLS, l’INP viene calcolato quando l’utente lascia la pagina, ottenendo un unico valore rappresentativo della reattività complessiva della pagina durante l’intero ciclo di vita della stessa. Se la pagina risponde rapidamente alle interazioni ad alto percentile, significa che anche le interazioni a tutti i percentili inferiori sono veloci.

Cosa succede se non ci sono interazioni

In alcuni casi, la pagina viene caricata, ma non avvengono interazioni da parte dell’utente. Questo può accadere per diversi motivi:

• È possibile che un utente abbia caricato la pagina, ma si sia distratto e non l’abbia mai utilizzata.
• L’utente ha caricato la pagina, l’ha fatta scorrere (questa non è un’interazione di cui l’INP tiene conto), ma non ha mai fatto clic, toccato o premuto un tasto sulla tastiera. Forse la parte utile della pagina che l’utente stava cercando non richiedeva alcuna interazione per essere raggiunta.
• La pagina è stata visitata da un bot (ad esempio, un crawler di ricerca o un browser headless) che non è stato programmato per interagire con la pagina.

In tutti questi casi, non verrà riportato alcun valore INP.

Perché INP non valuta la peggiore latenza di interazione

Ci potremmo chiedere, a questo punto, perché Google ha scelto di misurare Interaction to Next Paint prendendo come riferimento “una delle singole interazioni più lunghe” e non la peggior latenza di interazione.

Wagner risponde che l’interazione peggiore potrebbe essere adeguata “per le pagine con un numero relativamente basso di interazioni”, ma non tutte le pagine web sono uguali e “alcune richiedono più interattività di altre, ad esempio un editor di testo o un’applicazione per videogiochi rispetto a un blog o a un sito di notizie”. Per le pagine con un numero molto elevato di interazioni, in particolare, il campionamento della peggiore potrebbe essere fuorviante, e anche nei siti web che danno la priorità alla reattività si verificano occasionalmente degli intoppi, e queste interazioni dovrebbero essere trascurate.

Al contrario, concentrandosi su un percentile elevato, ma non sempre il più alto, è possibile valutare in modo corretto se la maggior parte delle interazioni di una pagina riceve una risposta tempestiva.

Il rapporto tra INP e FID: INP è più affidabile

Sin dalla sua introduzione nel 2022, INP ha subito suscitato l’interesse della comunità SEO internazionale, soprattutto perché questa nuova metrica è sembrata da subito entrare in collisione con il First Input Delay, rappresentandone quasi un’evoluzione. Ciò è stato confermato anche dalla presentazione di Mocny a Google I/O 2022, in cui il Developer per Chrome Speed Metrics e Core Web Vitals (!) ha ammesso che “FID ha alcuni punti ciechi abbastanza grandi”, aggiungendo che “per questo stiamo introducendo una nuova metrica di reattività sperimentale, Interaction to Next Paint”, lasciando aperta già allora la possibilità che INP sostituisse (o quanto meno affiancasse) FID all’interno dei segnali web essenziali e nei segnali della Page Experience.

Approfondendo quanto detto in precedenza anche dal punto di vista pratico, la differenza tra INP e FID è evidente: il First Input Delay tiene conto solo della prima interazione e misura solo il ritardo di ingresso, non il tempo di elaborazione dei gestori di eventi o il ritardo nella presentazione del fotogramma successivo, mentre al contrario Interaction to Next Paint considera tutte le interazioni della pagina.

Essendo una metrica di reattività al caricamento (load responsiveness metric), FID applica una logica di base per cui “se la prima interazione con una pagina nella fase di caricamento ha un ritardo di input minimo o nullo, la pagina ha fatto una buona prima impressione”.

INP però va oltre questa “prima impressione”, perché copre l’intero spettro di interazioni che possono verificarsi dal momento in cui la pagina inizia a caricarsi a quello in cui l’utente lascia la pagina.  Campionando tutte le interazioni, riesce a valutare la reattività in modo completo e ciò “rende INP un indicatore più affidabile della reattività rispetto a FID”, sintetizza Wagner.

Le differenze tra INP e FID e i vantaggi di INP

Scendono in maggiori dettagli Leena Sohoni, Addy Osmani e Keen Yee Liau, che sempre sulle pagine di web.dev firmano un interessante approfondimento incentrato sul rapporto tra la metrica INP e l’esperienza dei siti realizzati con framework e librerie JavaScript.

Parlando delle differenze tra FID e INP, i tre tecnici segnalano che First Input Delay “misura il tempo di attesa dalla prima interazione dell’utente al momento in cui il browser è in grado di elaborare i gestori di eventi collegati all’interazione”, ma non include il tempo necessario per elaborare i gestori di eventi, per elaborare le interazioni successive sulla stessa pagina o per visualizzare il fotogramma successivo dopo l’esecuzione dei callback degli eventi.

Tuttavia, annotano, la reattività è fondamentale per l’esperienza dell’utente durante l’intero ciclo di vita della pagina, poiché gli utenti trascorrono circa il 90% del tempo su una pagina dopo il suo caricamento. Inoltre, poiché il FID misura appunto solo il ritardo di input della prima interazione, è probabile che gli sviluppatori web non abbiano ottimizzato in modo proattivo le interazioni successive come parte del loro processo di miglioramento.

È qui che entra in gioco INP, che misura il tempo necessario a una pagina web per rispondere alle interazioni dell’utente, da quando l’utente inizia l’interazione fino al momento in cui il fotogramma successivo appare sullo schermo. Con questa nuova metrica Google spera “di ottenere una misura aggregata della latenza percepita di tutte le interazioni nel ciclo di vita della pagina”, una “stima più accurata della reattività di caricamento e di esecuzione delle pagine web”.

FID vs. INP: caratteristiche, calcolo e ottimizzazioni

L’articolo presenta anche una valida tabella riassuntiva e comparativa tra le caratteristiche di First Input Delay e Interaction to Next Paint.

In generale, INP tende ad avere tassi di superamento più bassi e la differenza nel processo di misurazione richiede un’ulteriore ottimizzazione del codice. Nello specifico, i punti su cui soffermarsi sono:

1. Misurazioni

• FID misura la durata tra il primo input dell’utente e il momento in cui viene eseguito il gestore di eventi corrispondente.
• INP misura la latenza complessiva dell’interazione utilizzando il ritardo
  • della singola interazione più grande per meno di 50 transazioni.
  • di una delle interazioni più grandi per più di 50 transazioni.

2. Da cosa dipende

• FID dipende dalla disponibilità del thread principale a eseguire l’event handler (gestore di eventi) necessario per la prima interazione. Il thread principale potrebbe essere bloccato perché sta elaborando altre risorse nell’ambito del caricamento iniziale della pagina.
• INP dipende dalla disponibilità del thread principale e dalla dimensione dello script eseguito dai gestori di eventi per diverse interazioni, compresa la prima interazione.

3. Causa primaria di scarsi punteggi

• Un FID scarso dipende principalmente dall’esecuzione pesante di JavaScript sul thread principale
• Un’intensa attività di gestione degli eventi JavaScript e altre attività di rendering dopo l’esecuzione dei gestori possono causare un INP insufficiente.

4. Ottimizzazione

• Il FID può essere ottimizzato migliorando il caricamento delle risorse al momento del caricamento della pagina e ottimizzando il codice JavaScript.
• Il processo di ottimizzazione è simile a quello del FID per ogni interazione, ma necessita anche dell’uso di modelli di rendering che danno priorità agli aggiornamenti UX chiave rispetto ad altre attività di rendering.

Come si misura INP: strumenti e tecniche per calcolare la responsiveness

È invece ancora l’articolo di Wagner a scendere nei dettagli tecnici per misurare Interaction to Next Paint sulle pagine di un sito, offrendo anche utili suggerimenti pratici per correggere le situazioni in cui i valori non siano ottimali.

Innanzitutto, INP può essere misurato sia sul campo che in laboratorio (con un certo sforzo) attraverso una serie di strumenti.

Tra i field tools ci sono:

• PageSpeed Insights.
• Chrome User Experience Report (CrUX).
  • tramite BigQuery nella tabella experimental.interaction_to_next_paint del dataset CrUX.
  • API CrUX tramite experimental_interaction_to_next_paint.
  • Dashboard di CrUX.
• Libreria JavaScript web-vitals.

Wagner avverte però che al momento la raccolta di metriche INP sul campo funziona solo sui browser che supportano pienamente l’API Event Timing, compresa la proprietà interactionId.

Tra i lab tools invece possiamo usare:

• Pannello Lighthouse in DevTools, disponibile in “Modalità Timespan”.
• Modulo npm Lighthouse.
• Flussi utente Lighthouse (user flow).
• Estensione Web Vitals per Chrome.

C’è poi un’altra possibilità, ovvero misurare Interaction to Newt Paint in JavaScript, scrivendo personalmente il proprio PerformanceObserver (ma può essere difficile, avverte Google) o usando la libreria JavaScript web-vitals, che esporta una funzione onINP per svolgere questo lavoro.

Come migliorare il valore INP

Se il nostro sito web riporta valori di INP che non rientrano nella soglia “buona” possiamo ovviamente apportare alcuni interventi per tentare di migliorare le prestazioni e quindi la reattività.

Di solito, valori elevati di INP indicano un’elevata dipendenza da JavaScript o da altri thread principali non JavaScript che possono essere eseguiti in concomitanza con le interazioni degli utenti.

Le correzioni iniziano dall’individuazione del momento critico per la responsiveness, ovvero se durante lo startup della pagina o successivamente.

Come migliorare INP durante l’avvio della pagina

INP può essere un fattore durante il caricamento della pagina, perché gli utenti possono tentare di interagire con una pagina mentre questa sta recuperando JavaScript per impostare i gestori di eventi che forniscono l’interattività necessaria per il funzionamento.

Secondo HTTP Archive, il Tempo di blocco totale (Total Blocking Time – TBT) è correlato due volte meglio con l’INP che con il FID. Il TBT è una metrica di laboratorio, ma se si osservano valori elevati di TBT negli strumenti di laboratorio “potrebbe essere un segnale di valori più elevati di INP” anche sul campo.

Per migliorare la reattività durante il caricamento della pagina, possiamo esaminare le seguenti soluzioni:

• Rimuovere il codice inutilizzato utilizzando lo strumento coverage in DevTools di Chrome.
• Trovare opportunità di suddividere il codice, in modo da poter caricare con lazy load il JavaScript non necessario durante il caricamento della pagina (usando ancora il coverage tool per avere informazioni).
• Identificare JavaScript lento di terze parti che potrebbe caricarsi durante l’avvio.
• Usare il profilatore di prestazioni per trovare attività lunghe che possono essere ottimizzate.
• Verificare di non richiedere eccessivo rendering del browser dopo che il codice JavaScript è stato completato: ad esempio, il re-rendering di un albero di componenti di grandi dimensioni, la decodifica di immagini di grandi dimensioni, troppi effetti css pesanti e così via.

Migliorare l’INP dopo l’avvio della pagina

Ma Interaction to Next Paint di una pagina può essere influenzato anche da ciò che accade dopo l’avvio della stessa, perché la metrica si calcola come detto sulla base degli input campionati durante l’intero ciclo di vita della pagina.

Quando ciò accade, possiamo esaminare alcune aree alla ricerca di soluzioni:

• Utilizzare l’API postTask per assegnare le priorità in modo appropriato.
• Programmare il lavoro non essenziale quando il browser è inattivo con requestIdleCallback.
• Usare il profilatore di prestazioni per valutare interazioni discrete (ad esempio, l’attivazione di un menu di navigazione mobile) e trovare attività lunghe da ottimizzare.
• Verificare l’esecuzione di JavaScript di terze parti nel sito web per vedere se influisce sulla reattività della pagina.

INP e JavaScript: i punti critici e le possibili ottimizzazioni

Già da quanto scritto si comprende quindi che JavaScript ha un peso evidente sulla reattività di una pagina, e in effetti si può ipotizzare (senza troppi timori di smentita) che qualsiasi script che blocca il thread principale per una lunga durata sia negativo per l’INP, anche alla luce della citata correlazione tra i valori di INP sul campo e il tempo di blocco totale (TBT) osservato in laboratorio.

Pertanto, una pesante esecuzione di JavaScript dopo un’interazione potrebbe bloccare il thread principale per un periodo prolungato e ritardare la risposta all’interazione, e l’articolo degli sviluppatori rivela alcune delle cause comuni che portano al blocco degli script, con alcune rapide azioni correttive che possiamo applicare.

• JavaScript non ottimizzato. Il codice ridondante o le scarse strategie di suddivisione e caricamento del codice possono causare l’ingrossamento del codice JavaScript e bloccare il thread principale per lunghi periodi. La suddivisione del codice, il caricamento progressivo e la suddivisione di compiti lunghi possono migliorare notevolmente i tempi di risposta.
• Script di terze parti. Gli script di terze parti, che a volte non sono necessari per elaborare un’interazione (ad esempio, gli script pubblicitari), possono bloccare il thread principale e causare inutili ritardi. Dare priorità agli script essenziali può aiutare a ridurre l’impatto negativo degli script di terze parti.
• Molteplici gestori di eventi. Più gestori di eventi associati a ogni interazione, ognuno dei quali esegue uno script diverso, possono interferire tra loro e causare lunghi ritardi. Alcune di queste attività potrebbero essere non essenziali e potrebbero essere programmate su un web worker o quando il browser è inattivo.
• Overhead del framework sulla gestione degli eventi. I framework possono avere caratteristiche/sintassi aggiuntive per la gestione degli eventi. Ad esempio, Vue utilizza v-on per collegare gli ascoltatori di eventi agli elementi, mentre Angular si occupa dei gestori di eventi utente. L’implementazione di queste caratteristiche richiede codice aggiuntivo del framework rispetto allo JavaScript standard.
• Hydration. Quando si usa un framework JavaScript, non è raro che un server generi l’HTML iniziale di una pagina, che poi deve essere completata con i gestori di eventi e lo stato dell’applicazione, in modo che possa essere interattiva in un browser web. Questo processo viene chiamato Hydration. Può essere un processo pesante durante il caricamento, a seconda di quanto tempo impiega JavaScript a caricarsi e a terminare l’hydration. Può anche far sembrare interattive pagine che non lo sono. Spesso l’hydration avviene automaticamente durante il caricamento della pagina o in lazy load (ad esempio, in base all’interazione dell’utente) e può avere un impatto sull’INP o sul tempo di elaborazione a causa della programmazione delle attività. In librerie come React, è possibile sfruttare useTransition in modo che parte del rendering di un componente avvenga nel fotogramma successivo e gli effetti collaterali più “costosi” a livello di risorse siano lasciati ai fotogrammi successivi. Per questo motivo, gli aggiornamenti in una transizione che si riferiscono ad aggiornamenti più urgenti, come i clic, possono essere uno schema utile per l’INP.
• Prefetching. il prefetching aggressivo delle risorse necessarie per le navigazioni successive può essere un vantaggio in termini di prestazioni, se fatto bene. Tuttavia, se si esegue il prefetching e il rendering dei percorsi SPA in modo sincrono, si può finire per avere un impatto negativo sull’INP, poiché tutto questo rendering costoso cerca di essere completato in un singolo frame. Questo è il caso in cui non si effettua il prefetching del percorso e si avvia il lavoro necessario (ad esempio, fetch() ) e si sblocca la visualizzazione. È quindi opportuno riesaminare se l’approccio del framework al prefetching fornisce una UX ottimale e come (se mai) questo può influire su INP.

In definitiva, quindi, per ottenere un buon punteggio INP gli sviluppatori dovranno concentrarsi sulla revisione del codice che viene eseguito dopo ogni interazione sulla pagina e ottimizzare le strategie di chunking, re-hydration, caricamento e la dimensione di ogni aggiornamento render() sia per gli script di prima parte che per quelli di terze parti.

Diamo il benvenuto a Interaction to Next Paint

Secondo i Googler, il punteggio INP è destinato a essere una “migliore bussola per i siti web” al fine di migliorare la reattività e le prestazioni, stabilendo un nuovo livello nella misurazione della responsiveness delle pagine come percepita realmente dagli utenti.

Inizialmente, la community internazionale ha reagito con curiosità ma senza apparente frenesia alla notizia, anche alla luce dell’esperienza maturata con la Page Experience e i Core Web Vitals, che in fin dei conti si sono rivelati un fattore di ranking di scarso impatto (almeno percepito) nonostante le premesse altisonanti.

Ora però le cose si fanno più serie e abbiamo meno di un anno per capire come ottimizzare le nostre pagine per intercettare questa nuova metrica, con l’obiettivo di rendere i nostri siti sempre più performanti e (in questo caso) effettivamente reattivi.