In che modo redBus ha migliorato l'interazione con il sito Next Paint (INP) del suo sito web e ha aumentato le vendite del 7%

Le ottimizzazioni INP hanno aiutato redBus ad aumentare le vendite di circa il 7%

Amit Kumar
Amit Kumar
Saurabh Rajpal
Saurabh Rajpal

Il web e le sue funzionalità si evolvono a un ritmo veloce. Ora puoi creare sul web esperienze complete e complete in grado di realizzare molte delle funzionalità offerte dalle applicazioni native.

JavaScript è un fattore determinante per l'interattività su tutto il web, ma se non viene utilizzato con cautela, le interazioni possono risultare lente e portare gli utenti a percepire il tuo sito web come non reattivo o completamente non funzionante. Per fortuna è stata creata la metrica Interaction to Next Paint (INP) per risolvere questo specifico problema relativo all'esperienza utente.

INP misura tutte le interazioni effettuate con una pagina durante il suo ciclo di vita e riporta un singolo valore che rappresenta la velocità di un sito web nel rispondere agli input degli utenti. In parole povere, se l'INP di una pagina è pari o inferiore alla soglia valida, tutte le interazioni effettuate con una pagina sono affidabili e veloci.

redBus, un sito web per la prenotazione e la vendita di biglietti di autobus con sede in India, ha intrapreso uno sforzo considerevole per migliorare l'INP del suo sito web, anche quando era ancora considerato una metrica sperimentale. Grazie ai loro sforzi, l'azienda è riuscita ad aumentare le vendite del 7%, a testimonianza del rapporto tra prestazioni web e integrità dell'attività. Ecco cosa ha fatto redBus per migliorare l'INP del suo sito web.

Obiettivi principali

Quando redBus ha deciso di ottimizzare l'INP del suo sito web, aveva in mente tre obiettivi:

  1. Offri una migliore esperienza utente agli utenti concentrandoti sulla latenza dell'interazione, indipendentemente dalla velocità della rete e dalle funzionalità del dispositivo.
  2. Ottimizzare il sito web per favorire le interazioni il più rapidamente possibile.
  3. Assicurarsi che le risposte dell'API siano il più leggere possibile per garantire un trasferimento rapido dei dati al front-end.

Il viaggio

redBus ha classificato la latenza delle interazioni in due modi:

  1. Latenza interazione causata dal blocco di JavaScript sul client. Quando le interazioni utilizzano un codice JavaScript eccessivo che blocca il thread principale, il rendering subisce un ritardo e questo influisce sull'INP di una pagina.
  2. Latenza di rete causata dalle chiamate API. Sebbene l'attività di rete non sia qualcosa che INP misura, un'interazione dipendente da una chiamata a un'API remota può sembrare lenta sulle reti più lente o se le richieste generano risposte elevate.

Inizialmente, redBus era abbastanza sicuro che l'INP del suo sito web sarebbe stato buono, ma i dati relativi al Real User Monitoring (RUM) per questa metrica al 95° percentile hanno raccontato una storia diversa.

Come redBus ha misurato l'INP

redBus si è affidata alla libreria JavaScript web-vitals creata da Google per monitorare non solo l'INP, ma anche tutte le metriche più importanti relative all'esperienza utente per tutte le pagine del suo sito web. Oltre alla libreria JavaScript web-vitals, redBus ha utilizzato ELK per analizzare i dati INP raccolti sul front-end.

Tuttavia, la modalità di monitoraggio dell'INP del tuo sito web sul campo potrebbe essere molto diversa da quella con cui redBus ha affrontato il problema. Ti consigliamo vivamente di leggere come individuare le interazioni lente sul campo per imparare a monitorare al meglio l'INP per i tuoi siti web e, successivamente, come riprodurle nel lab prima di iniziare a ottimizzare le interazioni.

Una volta realizzato un sistema per il monitoraggio dell'INP, redBus è stato in grado di analizzare i dati per comprendere meglio dove era presente l'interattività lenta.

Uno screenshot del sistema di registrazione ELK che riporta i valori INP per l'analisi.
Uno screenshot del sistema di logging utilizzato da redBus per analizzare i valori INP raccolti dal campo. (Fai clic per una versione a risoluzione più alta di questa immagine.)

casi d'uso

Quando gli utenti cercano le tariffe sul sito web di redBus, possono modificare la data nella pagina di ricerca per filtrare le tariffe selezionate per la destinazione desiderata. L'interazione per cambiare la data in questa pagina è stata lenta ed è stata causata da un INP scarso.

Inoltre, quando un utente scorre le tariffe, le tariffe aggiuntive vengono caricate tramite caricamento lento dall'API. Anche se lo scorrimento in sé non è considerato nel modo in cui viene misurato l'INP, il listener di eventi scroll programma una grande quantità di lavoro che deve essere eseguita sul thread principale. Questo lavoro causava una contesa sul thread principale che aumentava la latenza dell'interazione, generando un INP scadente nella pagina di ricerca.

Il comportamento di caricamento lento utilizzato per caricare tariffe aggiuntive dall'API allo scorrimento. (Fai clic per visualizzare una versione a risoluzione più alta di questo video.)

In che modo redBus ha ottimizzato l'INP per la pagina di ricerca

Per migliorare l'INP della pagina di ricerca, redBus ha apportato diverse ottimizzazioni:

  • Il gestore di eventi scroll è stato debounced per ridurre il numero di volte in cui il callback dell'evento è stato attivato in un determinato periodo. Riducendo la frequenza con cui viene eseguito il callback dell'evento scroll, il thread principale ha potuto rispondere più rapidamente alle interazioni degli utenti nella pagina di ricerca.
  • Il lavoro di rendering risultante è stato prioritario utilizzando un callback requestAnimationFrame. requestAnimationFrame comunica al browser che le operazioni nel callback devono essere eseguite prima del frame successivo.
Uno screenshot del riquadro delle prestazioni in Chrome DevTools che mostra i callback dell'evento di scorrimento del sito web redBus che non vengono eliminati. Di conseguenza, il thread principale viene bloccato.
Prima: i gestori di scorrimento attivati senza debouncing applicati al callback dell'evento. Nel thread principale è presente un numero considerevole di attività di blocco che ritardano le interazioni.
Uno screenshot del riquadro delle prestazioni in Chrome DevTools che mostra i callback dell'evento di scorrimento del sito web redBus che sono stati rimossi. Il risultato è che il thread principale è meno bloccato perché i gestori di eventi di scorrimento si attivano molto meno di frequente.
Dopo: gestori di scorrimento attivati con debouncing applicato. I callback degli eventi di scorrimento vengono attivati meno di frequente, offrendo al thread principale più opportunità di rispondere alle interazioni degli utenti.

Inoltre, sono state apportate le seguenti ottimizzazioni alla pagina dei risultati di ricerca:

  • Sono stati recuperati nuovi gruppi di risultati nella penultima scheda della pagina dei risultati di ricerca per migliorare l'esperienza utente e le prestazioni visive attivando il caricamento lento precedente.
  • Durante il caricamento lento, sono stati recuperati meno risultati per ogni chiamata di rete. Riducendo i fetch da 30 a 10 risultati, è stata osservata una riduzione degli intervalli INP da 870 a 900 fino a 350-370.
Il comportamento di caricamento lento utilizzato per caricare tariffe aggiuntive dall'API allo scorrimento. (Fai clic per visualizzare una versione a risoluzione più alta di questo video.)

Anche se queste modifiche miglioravano notevolmente l'INP della pagina di ricerca, si verificava ancora il problema per cui l'evento change nei campi di immissione della pagina di ricerca chiamava una funzione di riduttore costosa per aggiornare l'interfaccia utente. Ciò ha comportato un rendering non necessario dell'interfaccia utente, con ripercussioni sull'INP della pagina.

Valori INP riportati nella console mentre l'utente digita in un campo di immissione. Il risultato INP di 344 osservato a livello di laboratorio rientra nelle soglie di “bisogno di miglioramento”. (Fai clic per visualizzare una versione a risoluzione più alta di questo video.)

Per ottimizzare questa interazione, redBus ha gestito lo stato dei componenti di input localmente e lo ha sincronizzato con lo store Redux solo quando è stato attivato un evento blur di un input. Questa modifica ha ridotto il numero di rendering ed eliminato quelli indesiderati dell'interfaccia utente richiamando il riduttore con minore frequenza.

Miglioramento dell'INP in seguito a chiamate meno frequenti del riduttore in seguito a una modifica del campo di immissione. (Fai clic per visualizzare una versione a risoluzione più alta di questo video.)

Grazie a questa modifica, l'INP della pagina è migliorato del 72%, ottenendo un'esperienza utente più rapida e fluida con cui è più probabile che gli utenti interagiscano.

Impatto sul business

La relazione tra l'integrità dell'attività e le prestazioni della pagina è ben nota. Sebbene INP sia una metrica relativamente nuova rispetto ad altri Segnali web essenziali, redBus ha osservato risultati aziendali migliori concentrandosi sul miglioramento di questa importante metrica delle prestazioni incentrata sull'utente. Il risultato è stato un aumento complessivo delle vendite del 7%.

In breve, INP ha contribuito a delineare un quadro dei problemi di prestazioni di runtime sul sito web di redBus. Sapendo che erano necessari miglioramenti, redBus è stata in grado di osservare il problema, riprodurlo e utilizzare queste informazioni fondamentali per effettuare ottimizzazioni vantaggiose per redBus e la sua attività.