Cette étude de cas décrit un workflow étape par étape de débogage et d'amélioration d'INP dans React, utilisé par Trendyol à l'aide d'outils Google tels que PageSpeed Insights (PSI), les outils pour les développeurs Chrome et l'API scheduler.yield
.
Les deux composants essentiels d'un site Web d'e-commerce sont la page des fiches produit et la page d'informations détaillées sur le produit. Le trafic d'e-commerce provient souvent des pages de fiches produit, que ce soit par le biais de campagnes par e-mail, de réseaux sociaux ou de publicités. Par conséquent, il est essentiel de s'assurer que l'expérience PLP est soigneusement conçue pour réduire le temps nécessaire à l'achat. Donner la priorité à la qualité de l'expérience utilisateur est essentiel pour réussir. Des publications telles que Milliseconds Make Millions ont déjà révélé l'impact significatif des performances Web sur la disposition des consommateurs à dépenser de l'argent et à interagir avec les marques en ligne.
Trendyol est une plate-forme d'e-commerce comptant environ 30 millions de clients et 240 000 vendeurs, ce qui nous a permis de devenir la première entreprise de Turquie avec une valeur de plus de 10 milliards de dollars, et l'une des meilleures plates-formes d'e-commerce au monde.
Pour atteindre son objectif de fournir la meilleure expérience utilisateur possible à grande échelle tout en conservant la flexibilité du contenu et en utilisant une ancienne version de React, Trendyol s'est concentré sur l'Interaction to Next Paint (INP) comme métrique clé à améliorer. Cette étude de cas décrit le parcours de Trendyol pour améliorer l'INP sur son PPP, ce qui a entraîné une réduction de 50% de l'INP et une augmentation de 1% des résultats de recherche.
Processus d'investigation de l'INP de Trendyol
L'INP mesure la réactivité d'un site Web aux entrées utilisateur. Un bon INP indique que le navigateur est capable de répondre de manière rapide et fiable à toutes les entrées utilisateur et de repeindre la page, ce qui est un élément clé d'une bonne expérience utilisateur.
Le parcours de Trendyol pour améliorer INP sur son PLP a commencé par une analyse approfondie de l'expérience utilisateur avant toute amélioration. D'après un rapport PSI, l'expérience utilisateur réelle du PLP avait un INP de 963 millisecondes sur mobile, comme illustré dans la figure suivante.
![L'INP de Trendyol, d'après le résultat de l'expérience utilisateur CrUX dans PageSpeed Insights. L'INP de Trendyol au 5 septembre 2023 était de 963 millisecondes, ce qui se situe dans la plage "faible".](https://web.dev/static/case-studies/trendyol-inp/image/fig-1.png?authuser=6&hl=fr)
Pour garantir une bonne réactivité, les propriétaires de sites doivent viser un INP inférieur à 200 millisecondes, ce qui signifie qu'à ce moment-là, l'INP de Trendyol se trouvait dans la plage "faible".
Heureusement, l'outil PSI fournit à la fois des données réelles pour les pages incluses dans le rapport d'expérience utilisateur Chrome et des données de diagnostic détaillées d'ateliers. En examinant les données de l'atelier, l'audit du temps d'exécution JavaScript de Lighthouse suggère que le script search-result-v2
occupe le thread principal plus de temps que les autres scripts de la page.
![Lecture des sources de longues tâches dans Lighthouse pour le site Web Trendyol. L'une des principales sources de longues tâches est un script qui gère les résultats de recherche sur PLP de Trendyol.](https://web.dev/static/case-studies/trendyol-inp/image/fig-2.png?authuser=6&hl=fr)
Pour identifier les goulots d'étranglement réels, nous avons utilisé le panneau des performances de Chrome DevTools afin de résoudre les problèmes liés à l'expérience PLP et d'identifier la source du problème. L'émulation des performances mobiles avec un ralentissement du processeur quatre fois supérieur dans les outils pour les développeurs Chrome a révélé une tâche d'une durée de 700 à 900 millisecondes sur le thread principal. Si le thread principal est occupé par d'autres tâches pendant plus de 50 millisecondes, il risque de ne pas pouvoir répondre aux entrées utilisateur en temps opportun, ce qui nuit à l'expérience utilisateur.
![Capture d'écran d'une session de profilage des performances dans la PLP des outils pour les développeurs Chrome pour Trendyol. La longue tâche décrite dure 737, 6 millisecondes et fait partie d'un rappel "Intersection Observer".](https://web.dev/static/case-studies/trendyol-inp/image/fig-3.png?authuser=6&hl=fr)
La tâche la plus longue a été causée par un rappel de l'API Intersection Observer sur le script des résultats de recherche dans un composant React. À ce stade, nous avons commencé à diviser cette longue tâche en petites parties afin de donner au navigateur plus de possibilités de répondre aux tâches prioritaires, y compris les interactions utilisateur.
Il s'avère que l'utilisation de l'opération setState
qui déclenche le nouveau rendu de React dans le rappel "Intersection Observer" entraîne un coût élevé, ce qui peut être problématique pour les appareils d'entrée de gamme, car ils occupent le thread principal trop longtemps.
L'une des méthodes utilisées par les développeurs pour diviser les tâches en tâches plus petites consiste à utiliser setTimeout
. Nous avons utilisé cette technique pour différer l'exécution de l'appel setState
dans une tâche distincte. Bien que setTimeout
permette de reporter l'exécution JavaScript, il ne fournit aucun contrôle sur la priorité. Nous avons donc rejoint la phase d'évaluation scheduler.yield
afin d'assurer la continuité de l'exécution du script après avoir cédé la ligne au thread principal:
/*
* Yielding method using scheduler.yield, falling back to setTimeout:
*/
async function yieldToMain() {
if('scheduler' in window && 'yield' in scheduler) {
return await scheduler.yield();
}
return new Promise(resolve => {
setTimeout(resolve, 0);
});
}
/*
* Yielding to the main thread before changing the state of the component:
*/
const observer = new IntersectionObserver((entries) => {
entries.forEach(handleIntersection);
const maxNumberOfEntries = Math.max(...this.intersectingEntries);
if (Number.isFinite(maxNumberOfEntries)) {
await this.yieldToMain();
this.setState({ count: maxNumberOfEntries });
}
}, { threshold: 0.5 });
L'ajout de cette méthode de rendement au code PLP a amélioré l'INP, car la tâche principale longue a été divisée en une série de tâches plus importantes, telles que les interactions utilisateur et les tâches de rendu ultérieures.
![Capture d'écran d'une session de profilage des performances dans la PLP des outils pour les développeurs Chrome pour Trendyol. La longue tâche qui s'exécutait auparavant pendant 737,6 millisecondes est maintenant divisée en plusieurs tâches plus petites.](https://web.dev/static/case-studies/trendyol-inp/image/fig-4.png?authuser=6&hl=fr)
Notez que Trendyol utilise le framework PuzzleJs pour implémenter une architecture de micro-interface à l'aide de React v16.9.0. Avec React 18, vous pouvez obtenir les mêmes performances, mais pour plusieurs raisons, Trendyol ne peut pas être mis à niveau pour le moment.
Résultats commerciaux
Pour mesurer l'impact de l'amélioration de l'INP, nous avons effectué un test A/B afin de déterminer l'impact sur les métriques commerciales. Globalement, les modifications que nous avons apportées au PLP ont entraîné une amélioration significative, y compris une réduction de 50% de l'INP et une augmentation de 1 % des taux de clics depuis la page des fiches vers la page d'informations détaillées sur le produit par session utilisateur. La figure suivante, vous pouvez voir comment INP a amélioré le PPP au fil du temps:
![Capture d'écran de l'INP du 75e centile de Trendyol sur six mois. À la fin des six mois, l'INP de Trendyol est passé de près de 1 400 millisecondes à près de 650 millisecondes.](https://web.dev/static/case-studies/trendyol-inp/image/fig-5.png?authuser=6&hl=fr)
Conclusion
L'optimisation de l'INP est un processus complexe et itératif, mais il peut être simplifié par un workflow clair. L'approche simple pour déboguer et améliorer l'INP de votre site Web varie selon que vous collectez ou non vos propres données de terrain. Si ce n'est pas le cas, PSI et Lighthouse constituent un bon point de départ. Une fois que vous avez identifié les pages présentant des problèmes, vous pouvez utiliser les outils de développement pour creuser plus en détail et tenter de les reproduire.
Si vous utilisez le thread principal de temps en temps pour donner au navigateur plus d'occasions d'effectuer des tâches urgentes, votre site Web sera plus réactif. Vos clients bénéficieront ainsi d'une meilleure expérience utilisateur. Les API de planification plus récentes telles que scheduler.yield()
facilitent cette tâche.
Nous remercions Jeremy Wagner, Barry Pollard et Houssein Djirdeh de Google, ainsi que l'équipe d'ingénieurs de Trendyol pour leur contribution à ce travail.