Comment redBus a amélioré l'interaction to Next Paint (INP) sur son site Web et augmenté ses ventes de 7%

Les optimisations d'INP ont permis à redBus d'accroître ses ventes d'environ 7%

Amit Kumar

Saurabh Rajpal

Le Web et ses fonctionnalités évoluent à toute vitesse. Vous pouvez désormais créer des expériences riches et complètes sur le Web qui permettent d'atteindre la plupart des capacités des applications natives.

JavaScript est l'un des principaux moteurs de l'interactivité sur le Web. Toutefois, s'il n'est pas utilisé avec précaution, les interactions peuvent sembler lentes et inciter les utilisateurs à croire que votre site Web ne répond pas ou ne fonctionne pas du tout. Heureusement, la métrique Interaction to Next Paint (INP) a été créée pour résoudre ce problème spécifique d'expérience utilisateur.

L'INP mesure toutes les interactions avec une page au cours de son cycle de vie et enregistre une valeur unique représentative de la vitesse de réponse d'un site Web aux entrées utilisateur. Pour faire simple, si l'INP d'une page est inférieur ou égal au seuil approprié, vous pouvez considérer que toutes les interactions avec une page sont rapides et fiables.

redBus, un site Web de réservation et de billetterie de bus basé en Inde, a entrepris des efforts importants pour améliorer l'INP de son site Web, même à l'époque où cette métrique était encore considérée comme expérimentale. Grâce à ces efforts, l'entreprise a pu augmenter ses ventes de 7%, ce qui illustre une fois encore la relation entre performances Web et santé de l'entreprise. Voici ce que redBus a fait pour améliorer l'INP de son site Web.

Principaux objectifs

Lorsque redBus a entrepris d'optimiser l'INP de son site Web, l'équipe avait trois objectifs en tête:

Améliorez l'expérience utilisateur en vous concentrant sur la latence des interactions, quelles que soient la vitesse du réseau et les capacités de l'appareil.
Optimiser son site Web pour que les interactions soient les plus rapides possible.
Vérifier que les réponses de son API soient aussi légères que possible pour assurer un transfert rapide des données vers l'interface

Le parcours

redBus a classé la latence d'interaction de deux manières:

Latence d'interaction causée par le blocage de JavaScript sur le client. Lorsque les interactions utilisent un nombre excessif de codes JavaScript qui bloque le thread principal, l'affichage est retardé, ce qui affecte l'INP d'une page.
Latence du réseau causée par des appels d'API. Bien que l'activité réseau ne soit pas mesurée par INP, une interaction dépendante d'un appel à une API distante peut sembler lente sur des réseaux plus lents ou si les requêtes génèrent des réponses volumineuses.

Au départ, redBus était convaincue que l'INP de son site Web serait satisfaisant, mais les données de la surveillance de l'utilisateur réel (RUM) pour cette métrique au 95e centile étaient différentes.

Comment redBus a mesuré l'INP

redBus s'est appuyé sur la bibliothèque JavaScript web-vitals créée par Google pour effectuer le suivi non seulement de l'INP, mais aussi de toutes les métriques importantes concernant l'expérience utilisateur sur l'ensemble des pages de son site Web. En plus de la bibliothèque JavaScript web-vitals, redBus a utilisé ELK pour analyser les données INP collectées sur l'interface.

Cependant, la façon dont vous effectuez le suivi de l'INP de votre site sur le terrain peut être très différente de celle dont redBus a abordé le problème. Nous vous recommandons vivement de lire l'article Identifier les interactions lentes sur le terrain afin de découvrir comment effectuer au mieux le suivi des INP pour vos sites Web, puis comment les reproduire dans l'atelier avant de commencer à optimiser les interactions.

Après avoir mis en place un système de suivi des INP, redBus a pu analyser les données afin de mieux comprendre où se trouvait une interactivité lente.

Capture d'écran du système de journalisation ELK générant des rapports sur les valeurs INP à des fins d'analyse. — Capture d'écran du système de journalisation utilisé par redBus pour analyser les valeurs INP collectées à partir du champ. (Cliquez ici pour afficher une version haute résolution de cette image.)

Cas d'utilisation

Lorsque les utilisateurs recherchent des tarifs sur le site Web de redBus, ils peuvent modifier la date sur la page de recherche afin de filtrer les tarifs sélectionnés pour la destination souhaitée. L'interaction permettant de modifier la date sur cette page était lente et était à l'origine d'un INP faible.

De plus, lorsqu'un utilisateur fait défiler les tarifs, des tarifs supplémentaires sont chargés de manière différée à partir de l'API. Bien que le défilement ne soit pas pris en compte dans la mesure de l'INP, l'écouteur d'événements scroll programme lui-même une grande partie du travail à exécuter sur le thread principal. Ce travail provoquait des conflits sur le fil de discussion principal, ce qui augmentait la latence des interactions, ce qui entraînait un mauvais INP sur la page de recherche.

Comportement de chargement différé utilisé pour charger des tarifs supplémentaires à partir de l'API lors du défilement. (Cliquez ici pour afficher cette vidéo dans une résolution plus élevée.)

Comment redBus a optimisé INP pour la page de recherche

Pour améliorer l'INP de la page de recherche, redBus a effectué plusieurs optimisations:

Le gestionnaire d'événements scroll a été rejeté afin de réduire le nombre de fois où le rappel d'événement se déclencherait au cours d'une période donnée. En diminuant la fréquence d'exécution des rappels d'événement scroll, le thread principal a pu répondre plus rapidement aux interactions des utilisateurs sur la page de recherche.
Le rendu du rendu a été priorisé à l'aide d'un rappel requestAnimationFrame. requestAnimationFrame indique au navigateur que le travail du rappel doit être effectué avant le frame suivant.

Capture d'écran du panneau des performances dans les outils pour les développeurs Chrome montrant le site Web redBus qui déclenche des rappels d'événements de défilement qui ne sont pas renvoyés. Le thread principal est alors bloqué. — Avant: les gestionnaires de défilement se déclenchent sans délai appliqué au rappel de l'événement. Un nombre considérable de tâches bloquantes sont présentes sur le thread principal, ce qui retarde les interactions.

Capture d'écran du panneau "Performances" dans les outils pour les développeurs Chrome montrant le site Web redBus qui déclenche des rappels d'événements de défilement qui sont annulés. Résultat : le thread principal est moins bloqué, car les gestionnaires d'événements de défilement se déclenchent beaucoup moins fréquemment. — Après: les gestionnaires de défilement se déclenchent avec la fonction anti-rebond appliquée. Les rappels d'événement de défilement se déclenchent moins fréquemment, ce qui donne au thread principal plus de possibilités de répondre aux interactions de l'utilisateur.

La page de résultats de recherche a également fait l'objet des optimisations suivantes:

De nouveaux lots de résultats ont été récupérés entre l'avant-dernière fiche de la page de résultats de recherche afin d'améliorer l'expérience utilisateur et les performances visuelles en déclenchant le chargement différé plus tôt.
Moins de résultats ont été récupérés à chaque appel réseau pendant le chargement différé. En réduisant les récupérations de 30 à 10 résultats, nous avons observé une réduction des plages INP de 870 à 900, puis de 350 à 370.

Bien que ces modifications aient considérablement amélioré l'INP de la page de recherche, le problème persiste : l'événement change dans les champs de saisie de la page de recherche appelle une fonction de réducteur coûteuse pour mettre à jour l'interface utilisateur. Cela a entraîné un rerendu inutile de l'interface utilisateur, ce qui affectait l'INP de la page.

Valeurs INP indiquées dans la console lorsque l'utilisateur saisit du texte dans un champ de saisie. La valeur INP de 344 observée en laboratoire se situe dans les seuils de « besoin d’amélioration ». (Cliquez ici pour afficher cette vidéo dans une résolution plus élevée.)

Pour optimiser cette interaction, redBus a géré l'état des composants d'entrée localement et ne l'a synchronisé avec le store Redux que lorsque l'événement blur d'une entrée était déclenché. Cette modification a réduit le nombre de rendus et éliminé un affichage indésirable de l'interface utilisateur en appelant le réducteur moins fréquemment.

Amélioration de l'INP grâce à l'appel moins fréquent du réducteur lors d'un changement de champ de saisie. (Cliquez ici pour afficher cette vidéo dans une résolution plus élevée.)

Grâce à ce changement, l'INP de la page a augmenté de 72%, ce qui lui a permis d'offrir une expérience utilisateur plus rapide et plus fluide, plus susceptible d'interagir avec elle.

Impact sur l'entreprise

La relation entre l'état de l'entreprise et les performances des pages est bien connue. Bien que l'INP soit une métrique relativement nouvelle par rapport aux autres métriques Core Web Vitals, redBus a observé de meilleurs résultats commerciaux en s'efforçant d'améliorer cette métrique de performances importante axée sur l'utilisateur. Résultat : les ventes ont augmenté de 7% au total.

En bref, INP a aidé à dresser un tableau des problèmes de performances d'exécution sur le site Web de redBus. Sachant qu'il y avait des améliorations à apporter, redBus a pu observer le problème, le reproduire et utiliser ces informations cruciales pour réaliser des optimisations bénéfiques pour redBus et son activité.