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à sono in rapida evoluzione. Ora puoi creare esperienze complete e ricche sul web che possono raggiungere gran parte delle funzionalità delle applicazioni native.

JavaScript è uno dei principali fattori di interattività sul web, ma se non viene utilizzato con attenzione, le interazioni possono risultare lente e indurre gli utenti a percepire il tuo sito web come non responsivo o addirittura non funzionante. Fortunatamente, la metrica Interaction to Next Paint (INP) è stata creata per risolvere questo problema specifico dell'esperienza utente.

INP misura tutte le interazioni effettuate con una pagina durante il suo ciclo di vita e riporta un singolo valore rappresentativo della velocità di risposta di un sito web agli input degli utenti. In parole semplici, se l'INP di una pagina è pari o inferiore alla soglia ottimale, si può affermare che tutte le interazioni effettuate con la pagina sono affidabilmente rapide.

redBus, un sito web di prenotazione e vendita di biglietti per autobus con sede in India, ha intrapreso un notevole impegno per migliorare l'INP del proprio sito web, anche quando era ancora considerata una metrica sperimentale. Grazie ai suoi sforzi, l'azienda è riuscita ad aumentare le vendite del 7%, a dimostrazione ancora una volta del rapporto tra rendimento del sito web e salute dell'attività. Ecco cosa ha fatto redBus per migliorare l'INP del proprio sito web.

Obiettivi principali

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

  1. Offrire un'esperienza utente migliore concentrandosi sulla latenza di interazione, indipendentemente dalla velocità della rete e dalle funzionalità del dispositivo.
  2. Ottimizzare il sito web per mantenere le interazioni il più veloci possibile.
  3. Assicurati 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 di interazione in due modi:

  1. Latenza di interazione causata dal blocco di JavaScript sul client. Quando le interazioni utilizzano JavaScript in modo eccessivo e bloccano il thread principale, il rendering viene ritardato e questo influisce sull'INP di una pagina.
  2. Latenza di rete causata dalle chiamate API. Sebbene l'attività di rete non sia un aspetto misurato dall'INP, un'interazione che si basa su una chiamata a un'API remota può sembrare lenta su reti più lente o se le richieste generano risposte di grandi dimensioni.

Inizialmente redBus era abbastanza sicura che l'INP per il proprio sito web sarebbe stato buono, ma i dati del monitoraggio dei real user (RUM) per questa metrica al 95° percentile raccontavano una storia diversa.

In che modo redBus ha misurato l'INP

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

Tuttavia, il modo in cui monitori l'INP del tuo sito web sul campo potrebbe essere molto diverso da come redBus ha affrontato il problema. Ti consigliamo vivamente di leggere l'articolo su come trovare interazioni lente sul campo per scoprire come monitorare al meglio l'INP per i tuoi siti web e, successivamente, come riprodurli in laboratorio prima di iniziare a ottimizzare le interazioni.

Una volta implementato un sistema per il monitoraggio dell'interattività non interattiva, redBus ha potuto 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 registrazione utilizzato da redBus per analizzare i valori INP raccolti sul campo. Fai clic per visualizzare una versione di questa immagine con una risoluzione più elevata.

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 modificare la data in questa pagina è stata lenta e ha causato un INP scadente.

Inoltre, quando un utente scorre le tariffe, altre tariffe vengono caricate tramite il caricamento differito dall'API. Sebbene lo scorrimento stesso non venga preso in considerazione per la misurazione dell'INP, l'ascoltatore di eventi scroll stesso pianifica molto lavoro che deve essere eseguito nel thread principale. Questo lavoro causava contese sul thread principale che aumentavano la latenza di interazione, con un conseguente calo dell'INP nella pagina di ricerca.

Il comportamento di caricamento differito utilizzato per caricare tariffe aggiuntive dall'API durante lo scorrimento. Fai clic per una versione di questo video in una risoluzione più elevata.

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 eventi scroll è stato debounced per ridurre il numero di volte in cui viene attivato il callback dell'evento in un determinato periodo. Riducendo la frequenza di esecuzione del callback dell'evento scroll, il thread principale è stato in grado di rispondere più rapidamente alle interazioni degli utenti nella pagina di ricerca.
  • Il lavoro di rendering risultante è stato dato la priorità utilizzando un callback requestAnimationFrame. requestAnimationFrame indica al browser che il lavoro nel callback deve essere completato prima del frame successivo.
Uno screenshot del riquadro delle prestazioni in Chrome DevTools che mostra il sito web redBus che attiva i callback dell'evento di scorrimento che non sono sottoposti a debounce. Il risultato è che il thread principale viene bloccato.
Prima: i gestori dello scorrimento vengono attivati senza debouncing applicato al callback dell'evento. È presente un numero considerevole di attività di blocco nel thread principale, che ritardano le interazioni.
Uno screenshot del riquadro sul rendimento in Chrome DevTools che mostra il sito web redBus che attiva i callback dell'evento di scorrimento sottoposti a debounce. Il risultato è che il thread principale è meno bloccato perché i gestori di eventi di scorrimento vengono attivati molto meno di frequente.
Dopo: gli handler di scorrimento vengono attivati con l'applicazione del debouncing. I richiami di 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 ulteriori ottimizzazioni alla pagina dei risultati di ricerca:

  • Nuovi batch di risultati sono stati recuperati nell'ultima scheda della pagina dei risultati di ricerca per migliorare l'esperienza utente e il rendimento visivo attivando il caricamento differito in precedenza.
  • Durante il caricamento lento sono stati recuperati meno risultati per ogni chiamata di rete. Riducendo i risultati di recupero da 30 a 10, è stata osservata una riduzione degli intervalli INP da 870 a 900 a 350-370.
Il comportamento di caricamento differito utilizzato per caricare tariffe aggiuntive dall'API durante lo scorrimento. Fai clic per una versione di questo video in una risoluzione più elevata.

Sebbene queste modifiche abbiano migliorato notevolmente l'INP della pagina di ricerca, il problema persisteva: l'evento change nei campi di immissione della pagina di ricerca chiamava una funzione di riduzione costosa per aggiornare l'interfaccia utente. Ciò ha comportato un nuovo rendering non necessario dell'interfaccia utente, che ha influito sull'INP della pagina.

I valori INP registrati nella console mentre l'utente digita in un campo di immissione. Il valore INP risultante di 344 osservato in un ambiente di laboratorio rientra nelle soglie "Richiede miglioramenti". Fai clic per una versione di questo video in una risoluzione più elevata.

Per ottimizzare questa interazione, redBus gestiva lo stato dei componenti di input localmente e lo sincronizzava con lo store Redux solo quando veniva attivato l'evento blur di un input. Questa modifica ha ridotto il numero di rerendering ed eliminato il rerendering indesiderato dell'interfaccia utente chiamando il riduttore meno di frequente.

Miglioramento dell'INP grazie alla chiamata del riduttore meno frequentemente in caso di modifica di un campo di immissione. Fai clic per una versione di questo video in una risoluzione più elevata.

Con questa modifica, l'INP della pagina è migliorato del 72%, il che ha comportato un'esperienza utente più rapida e fluida con una maggiore probabilità di coinvolgimento degli utenti.

Impatto sul business

La relazione tra l'integrità dell'attività e il rendimento delle pagine è ben nota. Sebbene l'INP sia una metrica relativamente nuova rispetto ad altri Core Web Vital, redBus ha registrato risultati aziendali migliori concentrandosi sul miglioramento di questa importante metrica di prestazioni incentrata sull'utente. Il risultato è stato un aumento complessivo delle vendite del 7%.

In breve, l'INP ha contribuito a descrivere i problemi di prestazioni di runtime sul sito web di redBus. Con la consapevolezza che erano necessari miglioramenti, redBus è riuscita a osservare il problema, a riprodurlo e a utilizzare queste informazioni cruciali per apportare ottimizzazioni vantaggiose per l'azienda.