L‘Interaction to Next Paint o INP (in italiano interazione fino alla successiva visualizzazione) è la nuova metrica sperimentale dei Core Web Vitals di Google e misura la reattività di una pagina web durante tutte le interazioni sulla pagina stessa.
A partire da marzo del 2024 questo nuovo parametro sostituirà l’attuale metrica per la reattività FID (First Input Delay), cioè quella che fino a oggi ha calcolato il ritardo della risposta a un comando-interazione sul sito.
Ma scopriamo più nel dettaglio come funziona la nuova metrica INP. Buona lettura!
Come funziona l’Interaction to Next Paint (INP)?
Un’interazione avviene quando un utente fa clic o scrolla una pagina, al fine di ottenere un cambiamento nella presentazione visibile sullo schermo.
Per ottenere il valore di INP viene registrata la durata dal momento in cui l’utente ha interagito con la pagina fino alla successiva immagine presentata dopo che tutti gli eventi associati sono stati eseguiti. Si tratta della somma dei seguenti intervalli di tempo:
- ritardo di input, ovvero il tempo tra quando l’utente interagisce con la pagina e quando gli eventi vengono eseguiti;
- tempo di elaborazione, cioè il tempo totale necessario per eseguire il codice negli eventi associati;
- ritardo di presentazione, ovvero il tempo tra quando gli eventi associati hanno finito di essere eseguiti e quando il browser presenta il fotogramma successivo.
Un basso valore di Interaction to Next Paint assicura che la pagina risponda in modo affidabile in ogni momento e questo è un ottimo segnale per Google.
Quali sono i valori ottimali di INP?
Al fine di superare i Core Web Vitals relativi per la metrica Interaction to Next Paint, il 75° percentile dei caricamenti di pagina registrati dovrebbe rimanere al di sotto dei 200 ms. Più precisamente:
- un INP inferiore o uguale a 200 millisecondi indica che la pagina ha una buona reattività;
- un INP compreso tra 200 e 500 millisecondi indica che la reattività della pagina necessita di miglioramenti;
- un INP superiore a 500 millisecondi indica che la reattività della tua pagina è scarsa.
Come misurare l’Interaction to Next Paint?
Per misurare l’Interaction to Next Paint è necessaria un’interazione reale da parte dell’utente. Google misura tutte le interazioni che gli utenti di Chrome effettuano con una pagina web e le memorizza nel dataset CrUX, cioè il dataset ufficiale per le Core Web Vitals.
Come ottenere le metriche ufficiali dell’INP?
Per conoscere le metriche ufficiali dell’Interaction to Next Paint è possibile utilizzare PageSpeed Insight, CrUX dashboard e Google BigQuery.
PageSpeed Insight fornisce il punteggio del 75° percentile degli ultimi 28 giorni, invece Google BigQuery (attraverso Data Studio) permette di ottenere un contesto storico più ampio.
Come misurare l’Interaction to Next Paint della sessione corrente?
I modi più semplici per individuare i problemi relativi all’Interaction to Next Paint sono attraverso Lighthouse in modalità “timespan”.
Inoltre è possibile utilizzare il Core Web Vitals Visualizer, oppure la Libreria JavaScript di Google Web Vitals:
<script type=”module”>
import {onINP}
from ‘https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module’;
onINP(console.log);
</script>
Come migliorare l’Interazione fino al Prossimo Rendering?
L’interazione fino al prossimo rendering è una metrica complicata.
Una pagina potrebbe essere davvero veloce e rispondere istantaneamente per la maggior parte. Sfortunatamente, se solo un’interazione è lenta, purtroppo questa influenzerà l’intera Interazione fino al Prossimo Rendering!
Ecco perché l’INP è suddiviso in:
- ritardo di input
- tempo di elaborazione
- ritardo di presentazione
Scopriamoli più da vicino.
1. Riduci al minimo il ritardo di input
Di solito, qualsiasi pagina risulta meno reattiva durante la fase di avvio.
Per mantenere il thread principale il più libero possibile, occorre:
- Rimuovere il codice inutilizzato. Questo può essere fatto attraverso un processo chiamato tree shaking (rimozione del codice inutilizzato) e code splitting (raggruppamento del codice in molti pacchetti piccoli che possono essere caricati quando necessario).
- Caricare il codice non essenziale durante l’inattività del browser. C’è davvero bisogno di un widget di chat durante i primi 500 ms del caricamento della pagina? Probabilmente no!
- Identificare script lenti che richiedono molte risorse e riscrivere il codice per renderlo più efficiente.
- Assicurarsi che la pagina sia “facile da rendirizzare”. Evita dimensioni DOM troppo grandi, troppe immagini o video enormi, troppe animazioni CSS, ecc.
2. Riduci al minimo il tempo di elaborazione
Quando un utente esegue un’azione come l’invio di un modulo o l’aggiunta di un articolo al carrello, non aspettare la conferma lato server, fornisci piuttosto un feedback immediato (stiamo inviando il tuo modulo, stiamo aggiungendo l’articolo X al carrello etc).
Inoltre, cedi il passo al thread principale il prima possibile. Poiché JavaScript prosegue con la modalità di “esecuzione fino al completamento”, bloccherà il thread principale fino a quando tutto il codice non sarà stato eseguito.
Puoi creare manualmente un punto di interruzione in cui il browser può aggiornare il layout (e quindi, successivamente, lasciarlo continuare a lavorare il resto del codice) cedendo il passo al thread principale. Il modo più semplice per farlo è inserire parti del codice in un setTimeout().
const formfeedbackEl = document.getElementById(“formfeedback”);
const formEl = document.getElementById(“form”);
formEl.addEventListener(“submit”, (evt) => {
evt.preventDefault();
formfeedbackEl.innerText = “Submitting form … please hold on”;
let headers = new Headers({ Accept: “application/json” });
let formData = new FormData(formEl);
fetch(“/form-endpoint”, { method: “POST”, headers, body: formData })
.then(function (response) {
return response.json();
})
.then(function (jsonData) {
formEl.reset();
formfeedbackEl.innerText = jsonData.message;
});
setTimeout(other_code_that_needs_to_run(),0);
});
3. Riduci al minimo il ritardo di presentazione
Quando è necessario aggiornare una pagina, anzitutto questa viene ri-renderizzata. Successivamente, il browser disegna il nuovo contenuto e lo invia alla parte di presentazione del browser (Composite GPU e Raster).
Dopo un’interazione, alcuni ambienti SPA (Single Page Application) potrebbero ri-renderizzare troppo contenuto.
Per rendere più semplice a una pagina (ri-)renderizzare, è possibile seguire queste due regole:
- Mantieni il DOM piccolo e semplice. Fondamentalmente, sarà molto più facile per un browser renderizzare una pagina con meno elementi DOM (nodi HTML) rispetto a renderizzare una pagina con molti nodi DOM nidificati e complicati;
- Utilizza la proprietà content-visibility per ritardare il rendering dei contenuti fuori schermo. La proprietà content-visibility velocizza il rendering delle parti visibili della pagina ritardando il rendering dei contenuti fuori schermo e rendendo quei contenuti fuori schermo appena necessari.
Ottimizzare i Core Web Vitals non è semplice
E così, arriviamo alla conclusione di questo articolo.
Come avrai notato dai nostri suggerimenti, l’ottimizzazione dei Core Web Vitals può essere un compito complesso, richiedendo competenze tecniche significative. Spesso, la difficoltà di tali operazioni è influenzata dalla struttura specifica del tuo sito web, tra cui il CMS utilizzato e le sue dinamiche uniche.
Per ulteriori dettagli e consigli specifici, ti invitiamo a consultare altre nostre guide sui Core Web Vitals. Inoltre, per semplificare questa complessa ottimizzazione, abbiamo sviluppato Phantom Layer, uno strumento che consente ai nostri clienti di affrontare automaticamente tutti questi aspetti, migliorando i Core Web Vitals in soli 48 ore, evitando la necessità di sessioni di sviluppo prolungate o costose consulenze tecniche.