Scopri come ottimizzare l'Interaction to Next Paint del tuo sito web.
Pubblicazione: 19 maggio 2023, ultimo aggiornamento: 2 settembre 2025
Interaction to Next Paint (INP) è una metrica stabile di Core Web Vitals che valuta l'adattabilità complessiva di una pagina alle interazioni degli utenti osservando la latenza di tutte le interazioni idonee che si verificano durante la visita di un utente a una pagina. Il valore INP finale corrisponde all'interazione più lunga osservata (a volte ignorando i valori anomali).
Per offrire una buona esperienza utente, i siti web dovrebbero avere un valore di Interaction to Next Paint pari o inferiore a 200 millisecondi. Per raggiungere questo obiettivo per la maggior parte degli utenti, una buona soglia da misurare è il 75° percentile dei caricamenti pagina, segmentato tra dispositivi mobili e computer.
A seconda del sito web, le interazioni potrebbero essere poche o nulle, ad esempio pagine con testo e immagini per lo più con pochi o nessun elemento interattivo. In alternativa, nel caso di siti web come editor di testo o giochi, potrebbero esserci centinaia o addirittura migliaia di interazioni. In entrambi i casi, se l'INP è elevato, l'esperienza utente è a rischio.
Migliorare l'INP richiede tempo e impegno, ma il risultato è un'esperienza utente migliore. In questa guida verrà illustrato un percorso per migliorare INP.
Scopri cosa causa un INP scadente
Prima di poter correggere le interazioni lente, avrai bisogno di dati che ti indichino se l'INP del tuo sito web è scadente o deve essere migliorato. Una volta ottenute queste informazioni, puoi passare al lab per iniziare a diagnosticare le interazioni lente e trovare una soluzione.
Trova le interazioni lente sul campo
Idealmente, il tuo percorso di ottimizzazione di INP inizierà con i dati dei campi. Nel migliore dei casi, i dati dei campi di un provider di monitoraggio degli utenti reali (RUM) ti forniranno non solo il valore INP di una pagina, ma anche dati contestuali che evidenziano l'interazione specifica responsabile del valore INP stesso, se l'interazione è avvenuta durante o dopo il caricamento della pagina, il tipo di interazione (clic, pressione di un tasto o tocco) e altre informazioni preziose.
Se non ti affidi a un provider RUM per ottenere i dati sul campo, la guida ai dati sul campo INP consiglia di utilizzare PageSpeed Insights per visualizzare i dati del Chrome User Experience Report (CrUX) per colmare le lacune. CrUX è il set di dati di Google del programma Core Web Vitals e fornisce un riepilogo di alto livello delle metriche per milioni di siti web, tra cui INP. Tuttavia, CrUX spesso non fornisce i dati contestuali che otterresti da un provider RUM per aiutarti ad analizzare i problemi. Per questo motivo, consigliamo comunque ai siti di utilizzare un provider RUM, se possibile, o di implementare la propria soluzione RUM per integrare ciò che è disponibile in CrUX.
Diagnostica le interazioni lente in laboratorio
Idealmente, dovresti iniziare i test in laboratorio una volta che i dati sul campo suggeriscono che le interazioni sono lente. In assenza di dati sul campo, esistono alcune strategie per identificare le interazioni lente in laboratorio. Queste strategie includono seguire i flussi utente comuni e testare le interazioni lungo il percorso, nonché interagire con la pagina durante il caricamento, quando il thread principale è spesso più occupato, per identificare le interazioni lente durante questa parte cruciale dell'esperienza utente.
Ottimizza le interazioni
Una volta identificata un'interazione lenta e riprodotta manualmente nel lab, il passaggio successivo è ottimizzarla.
Le interazioni possono essere suddivise in tre parti:
- Il ritardo di input, che inizia quando l'utente avvia un'interazione con la pagina e termina quando iniziano a essere eseguiti i callback degli eventi per l'interazione.
- La durata dell'elaborazione, ovvero il tempo necessario per l'esecuzione completa dei callback degli eventi.
- Il ritardo di presentazione, ovvero il tempo necessario al browser per presentare il frame successivo che contiene il risultato visivo dell'interazione.
La somma di queste tre parti secondarie è la latenza di interazione totale. Ogni singola parte secondaria di un'interazione contribuisce in qualche modo alla latenza totale dell'interazione, quindi è importante sapere come ottimizzare ogni parte dell'interazione in modo che venga eseguita nel minor tempo possibile.
Identifica e riduci il ritardo input
Quando un utente interagisce con una pagina, la prima parte di questa interazione è il ritardo di input. A seconda delle altre attività sulla pagina, i ritardi di input possono essere di durata considerevole. Ciò potrebbe essere dovuto all'attività che si verifica nel thread principale (ad esempio a causa del caricamento, dell'analisi e della compilazione degli script), alla gestione del recupero, alle funzioni del timer o anche ad altre interazioni che si verificano in rapida successione e si sovrappongono l'una all'altra.
Indipendentemente dall'origine del ritardo di input di un'interazione, è consigliabile ridurlo al minimo in modo che le interazioni possano iniziare a eseguire i callback degli eventi il prima possibile.
La relazione tra la valutazione degli script e le attività lunghe durante l'avvio
Un aspetto fondamentale dell'interattività nel ciclo di vita della pagina è la fase di avvio. Durante il caricamento di una pagina, questa viene inizialmente visualizzata, ma è importante ricordare che il fatto che una pagina sia stata visualizzata non significa che il caricamento pagina sia terminato. A seconda del numero di risorse necessarie per rendere una pagina completamente funzionale, è possibile che gli utenti tentino di interagire con la pagina mentre è ancora in fase di caricamento.
Un fattore che può estendere il ritardo di input di un'interazione durante il caricamento di una pagina è la valutazione degli script. Dopo aver recuperato un file JavaScript dalla rete, il browser deve ancora svolgere alcune operazioni prima che il codice JavaScript possa essere eseguito. Queste operazioni includono l'analisi di uno script per verificare che la sintassi sia valida, la compilazione in bytecode e, infine, l'esecuzione.
A seconda delle dimensioni di uno script, questo lavoro può introdurre attività lunghe nel thread principale, ritardando la risposta del browser ad altre interazioni dell'utente. Per mantenere la pagina reattiva all'input dell'utente durante il caricamento, è importante capire cosa puoi fare per ridurre la probabilità di attività lunghe durante il caricamento della pagina, in modo che la pagina rimanga rapida.
Ottimizza i callback eventi
Il ritardo di input è solo la prima parte di ciò che misura INP. Dovrai anche assicurarti che i callback degli eventi eseguiti in risposta a un'interazione utente possano essere completati il più rapidamente possibile.
Cedi spesso il controllo al thread principale
Il miglior consiglio generale per ottimizzare i callback degli eventi è ridurre al minimo il lavoro al loro interno. Tuttavia, la logica di interazione potrebbe essere complessa e potresti essere in grado di ridurre solo marginalmente il lavoro che svolgono.
Se questo è il caso del tuo sito web, la prossima cosa che puoi provare è suddividere il lavoro nei callback degli eventi in attività separate. In questo modo, il lavoro collettivo non diventa un'attività lunga che blocca il thread principale, consentendo l'esecuzione più rapida di altre interazioni che altrimenti attenderebbero il thread principale.
setTimeout è un modo per suddividere le attività, perché il callback passato viene eseguito in una nuova attività. Puoi utilizzare setTimeout da solo o astrarre il suo utilizzo in una funzione separata per un'interruzione più ergonomica.
La cessione indiscriminata è meglio di nessuna cessione, ma esiste un modo più sfumato di cedere al thread principale, che prevede la cessione solo immediatamente dopo un callback di evento che aggiorna l'interfaccia utente, in modo che la logica di rendering possa essere eseguita prima.
Cedere il controllo per consentire l'esecuzione più rapida del lavoro di rendering
Una tecnica di yielding più avanzata prevede la strutturazione del codice nei callback degli eventi per limitare l'esecuzione alla sola logica necessaria per applicare gli aggiornamenti visivi per il frame successivo. Tutto il resto può essere rimandato a un'attività successiva. In questo modo, non solo i callback rimangono leggeri e agili, ma migliora anche il tempo di rendering delle interazioni, poiché gli aggiornamenti visivi non vengono bloccati dal codice di callback degli eventi.
Ad esempio, immagina un editor di testo RTF che formatta il testo mentre digiti, ma aggiorna anche altri aspetti della UI in risposta a ciò che hai scritto (come il conteggio delle parole, l'evidenziazione degli errori ortografici e altri feedback visivi importanti). Inoltre, l'applicazione potrebbe dover salvare ciò che hai scritto in modo che, se esci e torni, non perdi il lavoro.
In questo esempio, devono verificarsi le seguenti quattro azioni in risposta ai caratteri digitati dall'utente. Tuttavia, solo il primo elemento deve essere completato prima che venga presentato il frame successivo.
- Aggiorna la casella di testo con ciò che l'utente ha digitato e applica la formattazione richiesta.
- Aggiorna la parte della UI che mostra il conteggio delle parole corrente.
- Esegui la logica per verificare la presenza di errori di ortografia.
- Salvare le modifiche più recenti (localmente o in un database remoto).
Il codice per eseguire questa operazione potrebbe essere simile al seguente:
textBox.addEventListener('input', (inputEvent) => {
// Update the UI immediately, so the changes the user made
// are visible as soon as the next frame is presented.
updateTextBox(inputEvent);
// Use `setTimeout` to defer all other work until at least the next
// frame by queuing a task in a `requestAnimationFrame()` callback.
requestAnimationFrame(() => {
setTimeout(() => {
const text = textBox.textContent;
updateWordCount(text);
checkSpelling(text);
saveChanges(text);
}, 0);
});
});
La seguente visualizzazione mostra come il rinvio di eventuali aggiornamenti non critici fino al frame successivo può ridurre la durata dell'elaborazione e, di conseguenza, la latenza complessiva dell'interazione.
Sebbene l'uso di setTimeout() all'interno di una chiamata requestAnimationFrame() nell'esempio di codice precedente sia un po' esoterico, è un metodo efficace che funziona in tutti i browser per impedire al codice non critico di bloccare il frame successivo.
Evita il layout thrashing
Il layout thrashing, a volte chiamato layout sincrono forzato, è un problema di prestazioni di rendering in cui il layout si verifica in modo sincrono. Si verifica quando aggiorni gli stili in JavaScript e poi li leggi nella stessa attività. Esistono molte proprietà in JavaScript che possono causare il layout thrashing.
Il layout thrashing è un collo di bottiglia delle prestazioni perché, aggiornando gli stili e richiedendo immediatamente i valori di questi stili in JavaScript, il browser è costretto a eseguire un lavoro di layout sincrono che altrimenti avrebbe potuto attendere per essere eseguito in modo asincrono in un secondo momento, dopo che i callback degli eventi hanno terminato l'esecuzione.
Riduci al minimo il ritardo di presentazione
Il ritardo di presentazione di un'interazione va dal momento in cui i callback degli eventi di un'interazione hanno terminato l'esecuzione fino al momento in cui il browser è in grado di visualizzare il frame successivo che mostra le modifiche visive risultanti.
Riduci al minimo le dimensioni del DOM
Quando il DOM di una pagina è piccolo, il lavoro di rendering di solito termina rapidamente. Tuttavia, quando i DOM diventano molto grandi, il lavoro di rendering tende a scalare con l'aumentare delle dimensioni del DOM. La relazione tra il lavoro di rendering e le dimensioni del DOM non è lineare, ma i DOM di grandi dimensioni richiedono più lavoro di rendering rispetto ai DOM di piccole dimensioni. Un DOM di grandi dimensioni è problematico in due casi:
- Durante il rendering iniziale della pagina, quando un DOM di grandi dimensioni richiede molto lavoro per eseguire il rendering dello stato iniziale della pagina.
- In risposta a un'interazione dell'utente, un DOM di grandi dimensioni può rendere molto costosi gli aggiornamenti del rendering e, di conseguenza, aumentare il tempo necessario al browser per presentare il frame successivo.
Tieni presente che esistono casi in cui i DOM di grandi dimensioni non possono essere ridotti in modo significativo. Sebbene esistano approcci che puoi adottare per ridurre le dimensioni del DOM, come l'appiattimento del DOM o l'aggiunta al DOM durante le interazioni degli utenti per mantenere ridotte le dimensioni iniziali del DOM, queste tecniche potrebbero non essere sufficienti.
Utilizza content-visibility per eseguire il rendering lazy degli elementi fuori schermo
Un modo per limitare la quantità di lavoro di rendering durante il caricamento della pagina e in risposta alle interazioni degli utenti è utilizzare la proprietà CSS content-visibility, che in pratica equivale a eseguire il rendering lazy degli elementi man mano che si avvicinano alla viewport. Sebbene l'utilizzo efficace di content-visibility possa richiedere un po' di pratica, vale la pena verificare se il risultato è un tempo di rendering inferiore che può migliorare l'INP della pagina.
Tieni presente i costi in termini di prestazioni durante il rendering di HTML utilizzando JavaScript
Dove c'è HTML, c'è l'analisi HTML e, dopo che il browser ha terminato l'analisi dell'HTML in un DOM, deve applicare gli stili, eseguire i calcoli del layout e, successivamente, eseguire il rendering del layout. Si tratta di un costo inevitabile, ma il modo in cui esegui il rendering dell'HTML è importante.
Quando il server invia l'HTML, questo arriva al browser sotto forma di stream. Streaming significa che la risposta HTML del server arriva in blocchi. Il browser ottimizza la gestione di uno stream analizzando in modo incrementale i chunk dello stream man mano che arrivano e visualizzandoli un po' alla volta. Si tratta di un'ottimizzazione delle prestazioni, in quanto il browser cede il controllo periodicamente e automaticamente durante il caricamento della pagina, senza alcun costo.
Sebbene la prima visita a un sito web comporti sempre una certa quantità di HTML, un approccio comune inizia con una quantità minima di HTML iniziale, per poi utilizzare JavaScript per compilare l'area dei contenuti. Anche i successivi aggiornamenti di quell'area di contenuti si verificano in seguito alle interazioni dell'utente. Questo è solitamente chiamato modello di applicazione a pagina singola (SPA). Uno svantaggio di questo pattern è che, eseguendo il rendering dell'HTML con JavaScript sul client, non solo si ha il costo dell'elaborazione JavaScript per creare l'HTML, ma il browser non cede il controllo finché non ha terminato l'analisi e il rendering dell'HTML.
Tuttavia, è fondamentale ricordare che anche i siti web che non sono SPA probabilmente comporteranno una certa quantità di rendering HTML tramite JavaScript come risultato delle interazioni. In genere, questo non è un problema, a meno che tu non stia eseguendo il rendering di grandi quantità di HTML sul client, il che può ritardare la presentazione del frame successivo. Tuttavia, è importante comprendere le implicazioni sul rendimento di questo approccio al rendering dell'HTML nel browser e come può influire sulla reattività del tuo sito web all'input dell'utente se esegui il rendering di molti HTML utilizzando JavaScript.
Conclusione
Migliorare l'INP del tuo sito è un processo iterativo. Quando correggi un'interazione lenta sul campo, è molto probabile che, soprattutto se il tuo sito web offre molta interattività, inizierai a trovare altre interazioni lente e dovrai ottimizzare anche queste.
La chiave per migliorare l'INP è la persistenza. Con il tempo, puoi migliorare la reattività della tua pagina in modo che gli utenti siano soddisfatti dell'esperienza che offri loro. È anche molto probabile che, man mano che sviluppi nuove funzionalità per i tuoi utenti, dovrai seguire lo stesso processo per ottimizzare le interazioni specifiche per loro. Ci vorranno tempo e impegno, ma ne varrà la pena.