Optimisation de l'interactivité des pages d'informations détaillées sur les produits pour réduire de 90% le FID maximal potentiel dans Lighthouse et améliorer de 9% le FID dans le rapport d'expérience utilisateur Chrome.
Mercado Libre est le plus grand écosystème de paiement et d'e-commerce d'Amérique latine. Présent dans 18 pays, il est l'un des leaders du marché en Argentine, au Brésil et au Mexique (en termes de visiteurs uniques et de pages vues).
Les performances Web sont au cœur des préoccupations de l'entreprise depuis longtemps. Toutefois, l'entreprise a récemment constitué une équipe chargée de surveiller les performances et de procéder à des optimisations dans différentes parties du site.
Cet article résume le travail effectué par Guille Paz, Pablo Carminatti et Oleh Burkhay, de l'équipe chargée de l'architecture de l'interface de Mercado Libre, pour optimiser l'un des Core Web Vitals: First Input Delay (FID) et son proxy d'atelier, Total Blocking Time (TBT).
90%
Réduction du FID potentiel maximal dans Lighthouse
9 %
Plus d'utilisateurs perçoivent le FID comme "rapide" dans CrUX
Tâches longues, First Input Delay et Total Blocking Time
L'exécution de code JavaScript coûteux peut entraîner des tâches longues, c'est-à-dire celles qui s'exécutent pendant plus de 50 ms dans le thread principal du navigateur.
Le FID (First Input Delay) mesure le délai entre le moment où un utilisateur interagit pour la première fois avec une page (par exemple, lorsqu'il clique sur un lien) et le moment où le navigateur est en mesure de commencer à traiter les gestionnaires d'événements en réponse à cette interaction. Un site qui exécute du code JavaScript coûteux devra probablement effectuer plusieurs longues tâches, ce qui aura un impact négatif sur le FID.
Pour offrir une expérience utilisateur de qualité, les sites doivent s'efforcer de définir un First Input Delay inférieur à 100 millisecondes :
Même si le site de Mercado Libre fonctionnait bien dans la plupart des sections, le rapport sur l'expérience utilisateur Chrome a constaté que les pages d'informations détaillées sur les produits présentaient un mauvais FID. Sur la base de ces informations, elle a décidé de concentrer ses efforts sur l'amélioration de l'interactivité des pages produit du site.
Ces pages permettent à l'utilisateur d'effectuer des interactions complexes. L'objectif était donc d'optimiser l'interactivité, sans interférer avec des fonctionnalités utiles.
Mesurer l'interactivité des pages d'informations détaillées sur les produits
Le FID nécessite un utilisateur réel et ne peut donc pas être mesuré en laboratoire. Cependant, la métrique Total Blocking Time (TBT) est mesurable en laboratoire, correspond bien au FID sur le terrain et capture également les problèmes qui affectent l'interactivité.
Dans la trace suivante, par exemple, alors que le temps total passé à exécuter des tâches sur le thread principal est de 560 ms, seulement 345 ms de ce temps sont considérés comme le temps de blocage total (la somme des parties de chaque tâche dépassant 50 ms):
L'équipe Mercado Libre a utilisé la requête "TBT" comme métrique de proxy lors de l'atelier, afin de mesurer et d'améliorer l'interactivité des pages d'informations détaillées sur les produits dans le monde réel.
Voici l'approche générale qu'ils ont adoptée:
- Utilisez WebPageTest pour déterminer exactement quels scripts occupaient le thread principal sur un appareil réel.
- Utilisez Lighthouse pour déterminer l'impact des modifications apportées à Max Potential First Input Delay (FID potentiel max.).
Utiliser WebPageTest pour visualiser les longues tâches
WebPageTest (WPT) est un outil de performances Web qui vous permet d'exécuter des tests sur des appareils réels dans différents endroits du monde.
Mercado Libre a utilisé WPT pour reproduire l'expérience de ses utilisateurs en choisissant un type d'appareil et un emplacement semblables à ceux des utilisateurs réels. Plus précisément, elle a choisi un appareil Moto 4G et Dulles, en Virginie, car elle souhaitait évaluer l'expérience des utilisateurs de Mercado Libre au Mexique. En observant la vue du thread principal de WPT, Mercado Libre a constaté que plusieurs tâches longues consécutives bloquaient le thread principal pendant deux secondes:
En analysant la cascade correspondante, ils ont constaté qu'une grande partie de ces deux secondes provenait du module d'analyse. Le bundle principal de l'application était volumineux (950 Ko) et l'analyse, la compilation et l'exécution prenaient beaucoup de temps.
Utiliser Lighthouse pour déterminer le FID maximal potentiel
Lighthouse ne vous permet pas de choisir entre différents appareils et emplacements, mais il s'agit d'un outil très utile pour diagnostiquer les sites et obtenir des recommandations en matière de performances.
Lors de l'exécution de Lighthouse sur les pages d'informations détaillées sur les produits, Mercado Libre a constaté que le FID potentiel maximal était la seule métrique indiquée en rouge, avec une valeur de 1 710 ms.
Sur cette base, Mercado Libre s'est fixé l'objectif d'améliorer son score FID potentiel maximal dans un outil de laboratoire tel que Lighthouse et WebPageTest, en partant du principe que ces améliorations affecteraient leurs utilisateurs réels et s'afficheront donc dans des outils de surveillance réels tels que le rapport sur l'expérience utilisateur Chrome.
Optimiser les longues tâches
Première itération
En se basant sur la trace de thread principale, Mercado Libre a défini l'objectif d'optimiser les deux modules qui exécutaient du code coûteux.
Elle a commencé à optimiser les performances du module de suivi interne. Ce module contenait une tâche gourmande en processeur qui n'était pas essentielle au fonctionnement du module et pouvait donc être supprimée en toute sécurité. Cela s'est traduit par une réduction de 2% du code JavaScript sur l'ensemble du site.
Elle a ensuite commencé à améliorer la taille générale du groupe:
Mercado Libre a utilisé l'outil webpack-bundle-analyzer pour détecter les possibilités d'optimisation:
- Au départ, le module Lodash complet était nécessaire. Elle a été remplacée par un exige par méthode pour charger uniquement un sous-ensemble de Lodash au lieu de l'ensemble de la bibliothèque. Elle a été utilisée avec lodash-webpack-plugin pour réduire encore davantage Lodash.
Il a également appliqué les optimisations Babel suivantes:
- Utilisation de @babel/plugin-transform-runtime pour réutiliser les assistants Babel dans l'ensemble du code et réduire considérablement la taille du bundle.
- Utilisation de babel-plugin-search-and-replace pour remplacer les jetons au moment de la compilation, afin de supprimer un fichier de configuration volumineux dans le bundle principal.
- Ajout de babel-plugin-transform-react-remove-prop-types pour économiser des octets supplémentaires en supprimant les types de props.
Grâce à ces optimisations, la taille du groupe a été réduite d'environ 16%.
Mesurer l'impact
Ces modifications ont permis de réduire le nombre de longues tâches consécutives de Mercado Libre de deux secondes à une seconde:
Lighthouse a montré une réduction de 57% du maximum potentiel du premier retard d'entrée:
Deuxième itération
L'équipe a continué à s'attarder sur de longues tâches afin de trouver des améliorations ultérieures.
Sur la base de ces informations, elle a décidé d'apporter les modifications suivantes:
- Continuez à réduire la taille du bundle principal pour optimiser le temps de compilation et d'analyse (par exemple, en supprimant les dépendances en double dans les différents modules).
- Appliquez la scission du code au niveau du composant pour diviser le code JavaScript en plus petits segments et permettre un chargement plus intelligent des différents composants.
- Différez l'hydratation des composants pour permettre une utilisation plus intelligente du thread principal. Cette technique est communément appelée hydratation partielle.
Mesurer l'impact
La trace WebPageTest obtenue a affiché des fragments encore plus petits de l'exécution JS:
Par ailleurs, la durée maximale du FID potentiel dans Lighthouse a été réduite de 60%supplémentaires:
Visualisez la progression pour les utilisateurs réels
Bien que les outils de tests de laboratoire tels que WebPageTest et Lighthouse soient parfaits pour itérer les solutions pendant le développement, le véritable objectif est d'améliorer l'expérience des utilisateurs réels.
Le rapport d'expérience utilisateur Chrome fournit des métriques sur l'expérience d'utilisateurs réels de Chrome sur des destinations populaires sur le Web. Les données du rapport peuvent être obtenues en exécutant des requêtes dans BigQuery, PageSpeedInsights ou l'API CrUX.
Le tableau de bord CrUX permet de visualiser facilement la progression des métriques principales:
Étapes suivantes
Les performances Web ne sont jamais terminées, et Mercado Libre comprend la valeur de ces optimisations pour ses utilisateurs. Bien qu'elle continue à appliquer plusieurs optimisations sur le site, y compris le préchargement dans les pages de fiches produit et les optimisations d'images, entre autres, elle continue d'améliorer les pages des fiches produit afin de réduire le temps de blocage total (TBT) et le FID de proxy, entre autres. Ces optimisations incluent les éléments suivants:
- Itération de la solution de division du code
- Amélioration de l'exécution des scripts tiers.
- Améliorations continues du regroupement d'éléments au niveau du bundler (webpack).
Mercado Libre bénéficie d'une vue globale des performances. Par conséquent, tout en continuant à optimiser l'interactivité sur le site, l'entreprise a également commencé à évaluer les possibilités d'amélioration des deux autres métriques Core Web Vitals actuelles: LCP (Largest Contentful Paint) et CLS (Cumulative Layout Shift).