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 sur l'expérience utilisateur Chrome.
Mercado Libre est le plus grand écosystème d'e-commerce et de paiements d'Amérique latine. Présente dans 18 pays, elle est leader du marché au Brésil, au Mexique et en Argentine (d'après le nombre de visiteurs uniques et de pages vues).
Les performances Web sont un sujet de préoccupation de longue date pour l'entreprise, mais elle a récemment constitué une équipe pour surveiller les performances et appliquer des optimisations à différentes parties du site.
Cet article résume le travail effectué par Guille Paz, Pablo Carminatti et Oleh Burkhay de l'équipe d'architecture du frontend de Mercado Libre pour optimiser l'une des métriques Core Web Vitals: le First Input Delay (FID) (Délai de première entrée) et son proxy de laboratoire, le Total Blocking Time (TBT) (Temps de blocage total).
90%
Réduction du FID potentiel maximal dans Lighthouse
9 %
Plus d'utilisateurs qui 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 peut réellement commencer à traiter les gestionnaires d'événements en réponse à cette interaction. Un site qui exécute du code JavaScript coûteux comporte probablement plusieurs tâches longues, ce qui aura un impact négatif sur le FID.
Pour offrir une expérience utilisateur de qualité, les sites doivent s'efforcer de ne pas dépasser un délai de première saisie de 100 millisecondes :
Bien que le site de Mercado Libre soit performant dans la plupart des sections, le rapport sur l'expérience utilisateur de Chrome a révélé que les pages d'informations détaillées sur les produits avaient un FID faible. Sur la base de ces informations, il 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 les 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. Toutefois, la métrique Total Blocking Time (TBT) est mesurable en laboratoire, présente une bonne corrélation avec le FID sur le terrain et capture également les problèmes qui affectent l'interactivité.
Dans la trace suivante, par exemple, alors que la durée totale consacrée à l'exécution de tâches sur le thread principal est de 560 ms, seules 345 ms de cette durée sont considérées comme temps de blocage total (somme des parties de chaque tâche qui dépassent 50 ms):
Mercado Libre a utilisé le TBT comme métrique de substitution en laboratoire 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'il a 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 au retard maximal potentiel (Max Potential FID).
Utiliser WebPageTest pour visualiser les tâches longues
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, ils ont choisi un appareil Moto 4G et Dulles (Virginie, États-Unis), car ils souhaitaient reproduire 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, il a constaté qu'une part considérable de ces deux secondes provenait de son module d'analyse. La taille du bundle principal de l'application était importante (950 ko) et l'analyse, la compilation et l'exécution prenaient beaucoup de temps.
Utiliser Lighthouse pour déterminer le FID potentiel maximal
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 sur les performances.
Lorsque Mercado Libre a exécuté Lighthouse sur les pages d'informations détaillées sur les produits, il a constaté que le FID maximal potentiel était la seule métrique marquée en rouge, avec une valeur de 1 710 ms.
Mercado Libre s'est donc fixé pour objectif d'améliorer son score FID maximal potentiel dans un outil de laboratoire tel que Lighthouse et WebPageTest, en supposant que ces améliorations affecteraient ses utilisateurs réels et, par conséquent, apparaîtraient dans des outils de surveillance des utilisateurs réels tels que le rapport sur l'expérience utilisateur Chrome.
Optimiser les tâches longues
Première itération
Sur la base de la trace du thread principal, Mercado Libre s'est fixé pour objectif d'optimiser les deux modules qui exécutaient du code coûteux.
Il a commencé à optimiser les performances du module de suivi interne. Ce module contenait une tâche gourmande en CPU qui n'était pas essentielle au fonctionnement du module et pouvait donc être supprimée en toute sécurité. Cela a permis de réduire de 2% le code JavaScript pour l'ensemble du site.
Ils ont ensuite commencé à améliorer la taille globale du bundle:
Mercado Libre a utilisé webpack-bundle-analyzer pour détecter des opportunités d'optimisation:
- Au départ, il fallait le module Lodash complet. Il a été remplacé par une exigence par méthode pour ne charger qu'un sous-ensemble de Lodash au lieu de la bibliothèque entière, et utilisé en conjonction avec lodash-webpack-plugin pour réduire encore Lodash.
Ils ont également appliqué les optimisations Babel suivantes:
- Utilisation de @babel/plugin-transform-runtime pour réutiliser les assistants de 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 grand fichier de configuration dans le bundle principal.
- Ajout de babel-plugin-transform-react-remove-prop-types pour économiser quelques octets en supprimant les types de propriétés.
Grâce à ces optimisations, la taille du bundle a été réduite d'environ 16%.
Mesurer l'impact
Ces modifications ont réduit le temps de traitement des tâches longues consécutives de Mercado Libre de deux à une seconde:
Lighthouse a enregistré une baisse de 57% du temps de latence de saisie maximal potentiel:
Deuxième itération
L'équipe a continué à examiner les tâches longues afin d'identifier des améliorations ultérieures.
Sur la base de ces informations, il a décidé d'implémenter 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 division du code au niveau des composants pour diviser le code JavaScript en petits morceaux 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 générée a révélé des segments d'exécution JavaScript encore plus petits:
Le temps de FID potentiel maximal dans Lighthouse a été réduit de 60%supplémentaires:
Visualiser la progression des utilisateurs réels
Bien que les outils de test en laboratoire tels que WebPageTest et Lighthouse soient excellents pour itérer sur les solutions pendant le développement, l'objectif réel est d'améliorer l'expérience pour les utilisateurs réels.
Le rapport d'expérience utilisateur Chrome fournit des métriques sur l'expérience utilisateur Chrome réelle des destinations populaires sur le Web. Vous pouvez obtenir les données du rapport en exécutant des requêtes dans BigQuery, PageSpeedInsights ou l'API CrUX.
Le tableau de bord CRUX vous permet de visualiser facilement la progression des métriques clés:
Étapes suivantes
Les performances Web ne sont jamais une tâche terminée, et Mercado Libre comprend la valeur que ces optimisations apportent à ses utilisateurs. Ils continuent d'appliquer plusieurs optimisations sur le site, y compris le prefetching sur les pages de fiches produit, l'optimisation des images, etc., et ils continuent d'améliorer les pages de fiches produit pour réduire encore plus le temps de blocage total (TBT) et, par proxy, le FID. Ces optimisations incluent les éléments suivants:
- Itération sur la solution de fractionnement du code.
- Amélioration de l'exécution des scripts tiers.
- Améliorations continues du regroupement d'assets au niveau du bundler (webpack).
Mercado Libre a une vision globale des performances. Par conséquent, tout en continuant d'optimiser l'interactivité sur le site, il a également commencé à évaluer les possibilités d'amélioration des deux autres métriques Core Web Vitals actuelles: le LCP (Largest Contentful Paint) et le CLS (Cumulative Layout Shift).