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

Tempo di lettura : 14 minuti

Sono passati esattamente due anni da quando per la prima volta Google introdusse il concetto di Core Web Vitals e, più in generale, di metriche per valutare concretamente l’esperienza vissuta dagli utenti sulle pagine di un sito: allora fu Ilya Grigorik, Web Performance Engineer, a presentare il progetto e a svelare il primo set di metriche scelto 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, ovvero Interaction to Next Paint o INP, che misura la responsiveness delle pagine, ovvero la capacità di rispondere agli input degli utenti.

La nuova metrica per la reattività: INP

A presentare INP è stato qualche settimana fa 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.

Anche se il First Input Delay è “un’ottima metrica per misurare la reattività dell’input durante il caricamento della pagina”, dicono i Googler, il Web sta diventando più capace e gli utenti si aspettano interfacce più ricche e interattive: guardare solo alla reattività durante il caricamento della pagina non racconta l’intera storia e serve un approccio più olistico alla misurazione della reattività e INP va proprio in questa direzione.

Che cosa significa Interaction to Next Paint

Interaction to Next Paint o INP (in italiano interazione fino alla successiva visualizzazione) è la metrica sperimentale 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 approfondisce 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 recenti 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”.

Il video chiarisce questi aspetti, mostrando una rappresentazione visiva di reattività scarsa (a sinistra) e buona (a destra) di un’immagine a grandezza naturale caricata da una galleria di miniature: l’esempio a destra fornisce un feedback visivo (l’indicatore di caricamento) che appare subito dopo la richiesta dell’immagine e scompare al momento opportuno, rappresentando un valido modo di comunicare il risultato di un’interazione. Nel caso di sinistra, invece, la reattività è scarsa perché l’immagine deve essere scaricata prima di essere visualizzata, il che comporta un notevole ritardo.

La definizione di INP e il valore della metrica

L’articolo di Wagner spiega come funziona INP, come misurarlo e offre suggerimenti per migliorarlo, partendo dall’assunto che una buona reattività è indispensabile per garantire una buona esperienza utente.

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.

Come si misura INP

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.

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

L’introduzione di INP ha interessato subito la comunità SEO internazionale, soprattutto perché questa nuova metrica sembra entrare in collisione con il First Input Delay e ne rappresenta 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 la possibilità che INP sostituisca (o quanto meno affianchi) FID all’interno dei segnali web essenziali e nei segnali della Page Experience.

Venendo agli aspetti pratici, 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 diventerà una “migliore bussola per i siti web” al fine di migliorare la reattività e le prestazioni nell’immediato futuro.

Per il momento, la community internazionale ha reagito con curiosità ma senza apparente frenesia, 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 finora), nonostante le premesse altisonanti.

Non resta quindi che attendere i prossimi sviluppi e 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.