Article

21min lecture

Tag JavaScript d’AB Tasty : performance et rapport d’analyse

Bonjour, je m’appelle Léo ! En tant que Product Manager chez AB Tasty, je suis responsable, entre autres, de notre tag JavaScript qui est utilisé actuellement par nos clients, sur des milliers de sites internet. Comme vous pouvez l’imaginer, ma roadmap est remplie de sujets liés à la collecte de données, à la confidentialité et… à la performance.

Dans cet article d’aujourd’hui, nous allons parler de la performance du tag JavaScript, de la surveillance de l’open data et de la concurrence. Allez, c’est parti !

Enquête sur la performance

Étant donné que la performance est devenue un sujet important et très discuté ces dernières années, notamment grâce à l’initiative de Google visant à déployer les Core Web Vitals, mon équipe et moi-même avons concentré nos efforts sur ce sujet. Nous avons apporté de nombreux changements, amélioré de nombreux aspects de notre tag et atteint d’excellents résultats. Beaucoup de nos utilisateurs ont témoigné de leur satisfaction à ce sujet. J’ai d’ailleurs déjà rédigé une (longue) série d’articles de blog à ce sujet ici

De temps en temps, nous sommes taquinés par nos concurrents au sujet d’un rapport sur les performances qui semble montrer que nous ne sommes pas à la hauteur de nos ambitions, selon certains indicateurs. Certains concurrents prétendent être jusqu’à 4 fois plus rapides que nous ! Et c’est vrai. Enfin, c’est ce que montre le rapport.

Vous pouvez facilement imaginer à quel point ceci peut être nocif pour notre image de marque et à quel point cela peut être difficile pour notre équipe business lorsqu’un client utilise cet argument. C’est particulièrement démoralisant pour moi et mon équipe après tout le travail que nous avons accompli sur ce sujet ces dernières années.

Bien que ce soit la première impression que j’ai eue en voyant ce rapport, je sais pertinemment que nos performances sont excellentes. Nous avons réalisé d’énormes améliorations après la sortie de plusieurs projets et optimisations. Aujourd’hui, tous les tests et audits que j’ai effectués sur les sites Web de nos clients montrent de très bonnes performances et un faible impact sur les fameux Core Web Vitals.

De plus, il est très rare qu’un client se plaigne de nos performances. Cela peut arriver, c’est certain, mais la plupart du temps, tous leurs doutes disparaissent après une courte discussion, quelques explications et des conseils sur les meilleures pratiques d’optimisation.

Mais ce rapport est toujours là, n’est-ce pas ? Alors peut-être que j’ai raté quelque chose. Peut-être que je ne regarde pas les bons indicateurs. Peut-être que j’ai uniquement audité des clients où tout va bien, mais qu’il y a une immense armée de clients qui ne se plaignent pas du fait que notre tag ralentisse considérablement leur site Web.

Le CRO, est ce que c’est la même chose que l’Analytics ?

Sur le rapport (je promets d’en parler plus en détail ci-dessous 😄), nous sommes mentionnés dans la catégorie Analytics. Cependant, l’optimisation du taux de conversion n’est pas la même chose que de l’Analytics. Un outil d’analyse ne fait que collecter des données tandis que nous activons des campagnes, mettons en place des personnalisations, implémentons des widgets, ajoutons des pop-ins et bien plus encore. Ainsi, notre impact est bien plus important.

Parlons de nos concurrents : même si nous avons la meilleure solution du marché (😇), nos concurrents font à peu près les mêmes choses que nous en utilisant les mêmes techniques, avec les mêmes limites et problèmes. Il est donc légitime de nous comparer selon les mêmes indicateurs. Il est possible que nous allions un peu plus loin qu’eux, mais cela ne devrait pas expliquer une différence de performance 4 fois supérieure.

À l’époque, et avant de me plonger dans son contenu, j’ai pris les résultats du rapport avec humilité. Par conséquent, mon ambition était d’analyser les données, d’analyser les sites Web où le tag de nos concurrents était utilisé et d’essayer de trouver ce qu’ils font de mieux que nous. Nous appelons ceci de la rétro-ingénierie, et je trouve cela sain car cela peut nous aider à garantir un Web plus rapide pour tout le monde.

Mon engagement envers ma hiérarchie a donc été de trouver les zones où nous avions des fuites de performance et de les résoudre afin de réduire notre temps d’exécution moyen et de nous rapprocher de nos concurrents.

Mais d’abord, j’ai dû analyser les données. Et, wow, je n’étais pas préparé à ça.

Le rapport en question

Le rapport est un ensemble de données généré mensuellement par The HTTP Archive. Voici ce que nous pouvons lire à propos d’eux sur leur site Web :

“Successful societies and institutions recognize the need to record their history – this provides a way to review the past, find explanations for current behavior, and spot emerging trends. In 1996, Brewster Kahle realized the cultural significance of the Internet and the need to record its history. As a result he founded the Internet Archive which collects and permanently stores the Web’s digitized content.”

“In addition to the content of web pages, it’s important to record how this digitized content is constructed and served. The HTTP Archive provides this record. It is a permanent repository of web performance information such as size of pages, failed requests, and technologies utilized. This performance information allows us to see trends in how the Web is built and provides a common data set from which to conduct web performance research.”

Chaque mois, ils effectuent un audit, grâce à Lighthouse, sur des millions de sites Web et génèrent un ensemble de données contenant des résultats bruts.

Comme il s’agit d’un projet open-source, tout le monde peut l’utiliser pour créer des visualisations de données et faciliter ensuite l’accès à ce type d’informations.

C’est ce qu’a fait l’inventeur de Google Lighthouse, Patrick Hulce. Sur son site Web, GitHub, il propose une belle visualisation de cet énorme ensemble de données et permet à quiconque d’en explorer les détails à travers plusieurs catégories telles que l’analyse, les publicités, les médias sociaux, et bien plus encore. Comme je l’ai cité auparavant, vous trouverez les outils CRO dans la catégorie Analytics .

Le site web est entièrement open-source. La méthodologie est connue et accessible.

Alors, c’est quoi le problème avec ce rapport ?

Eh bien, techniquement, rien. Nous pourrions trouver décevant que l’ensemble de données ne soit pas automatiquement mis à jour chaque mois, mais le référentiel est open-source, donc toute personne motivée pourrait le faire.

Cependant, cela se limite à afficher les données de manière attrayante et ne fournit aucune information, ni analyse approfondie. Toute faille ou incohérence restera cachée et cela pourrait conduire à une situation où une tierce partie est considérée comme ayant de mauvaises performances par rapport à d’autres acteurs. Alors que ce n’est pas nécessairement le cas.

Un problème, cependant, qui n’est pas lié au rapport lui-même, est l’oubli des informations capitales dont la moyenne, en tant que mesure statistique, ne peut rendre compte. C’est quelque chose dont nous sommes tous conscients mais que nous avons tendance à oublier. Si vous prenez 10 personnes, dont 9 gagnent 800€ par mois mais qu’une personne gagne 12 millions d’euros par mois, alors nous pourrions conclure que tout le monde gagne 1,2 million d’euros en moyenne/mois. C’est certes statistiquement correct, mais cela semble un peu faux, n’est-ce pas ? Nous y reviendrons dans un instant.

Sachant cela, il était temps de mettre les mains dans le cambouis. Avec mon équipe, nous avons téléchargé l’ensemble des données de février 2023 pour effectuer notre propre audit et comprendre où se situaient nos fuites de performance.

Notez que le téléchargement de l’ensemble des données est quelque chose que nous faisons régulièrement depuis environ un an et demi pour suivre notre tendance. Cependant, cette fois, j’ai décidé d’approfondir le rapport de février 2023 en particulier.

L’analyse

Sur cet ensemble de données, nous avons pu trouver la liste complète des sites Web utilisant AB Tasty et qui ont été analysés, ainsi que l’impact de notre tag. Pour être plus précis, nous disposons du temps d’exécution exact de notre tag, en millisecondes.

Voici ce que nous en avons extrait. La colonne pixellisée représente l’URL du site Web. La dernière colonne représente le temps d’exécution en millisecondes.

Avec les données brutes, nous avons pu calculer de nombreux indicateurs utiles.

Gardez à l’esprit que je ne suis ni mathématicien, ni expert en statistiques. Ma méthodologie peut sembler étrange, mais elle est adaptée à cette analyse.

  • Le temps d’exécution moyen

Il s’agit du premier indicateur que j’obtiens : la moyenne brute de tous les sites Web. C’est probablement très proche, voire égal, à ce qui est utilisé par le site Web thirdpartyweb.today. Nous avons déjà évoqué les inconvénients d’avoir une moyenne, cependant, c’est toujours une valeur intéressante à surveiller.

  • Moyenne de la moitié supérieure et moyenne de la moitié inférieure

Ensuite, je divise l’ensemble du jeu de données en deux moitiés. Si j’ai 2000 lignes, je crée deux groupes de 1000 lignes. La « partie supérieure » et la « partie inférieure ». Cela me permet d’avoir une vue sur les sites Web où nous avons de bonnes performances par rapport aux sites Web où nous avons les pires performances. Ensuite, je calcule la moyenne de chaque moitié.

  • L’écart entre les deux moitiés

La différence entre les deux moitiés est importante car elle montre la disparité au sein de l’ensemble de données. Plus elle est proche de zéro, moins nous avons de valeurs extrêmes.

  • Le nombre de sites Web avec une valeur supérieure à 6 000 ms

Il s’agit simplement d’un indicateur interne que nous suivons pour nous fixer un objectif à moyen terme : celui de n’avoir 0 site Web avec une valeur supérieure à cette limite.

  • L’évolution du dernier ensemble de données

Je calcule l’évolution entre le dernier ensemble de données dont je dispose et le dernier en date. Cela me permet de voir si nous nous améliorons en général, ainsi que le nombre de sites web qui quittent ou rejoignent le tableau.

Les résultats

Voici les résultats que nous avons obtenus :

Voici les graphiques correspondants :

Voici l’évolution entre octobre 2022 et février 2023 :

Attention : c’est une échelle logarithmique ! Les données sont triées par temps d’exécution en février 2023 de gauche à droite.

Les chiffres parlent d’eux-mêmes. Mais si je peux esquisser une conclusion générale, c’est que nous avons réalisé d’énormes optimisations au cours des six premiers mois, puis nous nous sommes stabilisés un peu après, au moment d’ajustements plus subtils (le fameux principe des 80/20 de Pareto).

Le gain net initial est impressionnant, néanmoins, deux chiffres clés devraient ici retenir votre attention.

Tout d’abord, la différence entre les deux moitiés se réduit considérablement. Cela signifie que nous n’avons plus beaucoup de fuites de performances potentielles (des fonctionnalités qui entraînent une augmentation anormale du temps d’exécution). C’est notre première victoire récente.

Ensuite, l’évolution montre que, en général, à l’exception des pires cas, cela reste stable ou diminue. C’est une autre nouvelle victoire.

Rentrons dans les détails

Ce que je viens de vous partager sont les résultats bruts, sans examiner les détails de chaque ligne et de chaque site Web parcouru.

Cependant, comme on dit, le diable se cache dans les détails. Creusons un peu plus.

Concentrons-nous sur les sites Web où AB Tasty met plus de six secondes à s’exécuter.

Six secondes peuvent sembler beaucoup (et c’est le cas), mais n’oublions pas que l’audit simule un processeur bas de gamme qui n’est pas représentatif de l’appareil moyen. Il montre plutôt le pire scénario possible.

Dans le rapport de février 2023, il y 33 sites Web où c’est le cas. Cela correspond à un temps d’exécution moyen de 19877 ms. J’ai rapidement identifié que :

  • 27 d’entre eux proviennent du même client AB Tasty.
  • L’un d’entre eux est abtasty.com et l’exécution totale des ressources provenant de *abtasty.com sur ce site est évidemment très élevée
  • Deux autres proviennent également d’un seul client AB Tasty.

Finalement, il n’y a que 5 clients sur cette liste (mais toujours 33 sites Web, ne vous trompez pas).

Regroupons maintenant les deux clients qui ont des doublons, pour voir l’impact sur la moyenne. Le client avec 27 doublons a également des sites Web dont le temps d’exécution est inférieur à 6 000 ms, mais je vais les ignorer pour le moment (afin de simplifier les choses).

Pour chacun des ces deux clients, je vais calculer la moyenne de tous leurs doublons. Pour le premier, le résultat est de 21 671 ms. Pour le second, le résultat est de 14 708 ms.

Je vais également supprimer abtasty.com, qui n’est pas pertinent.

Avec la nouvelle liste, nous sommes passés de 1 223 ms pour la moyenne de la liste complète à 1 005 ms. Nous venons d’améliorer notre moyenne de plus de 200 ms ! 🎉

Attendez, quoi ? Vous supprimez simplement les pires sites Web. Évidemment, vous vous améliorez…

Oui, c’est vrai. C’est de la triche, c’est sûr ! Mais l’objectif de cet article est de démontrer que les données ne disent pas tout.

Parlons d’abord de ce qui se passe avec ce client qui a 27 doublons.

Le même tag a été déployé sur plus de 50 sites Web très différents ! Vous n’êtes peut-être pas très familier avec AB Tasty, alors laissez-moi vous expliquer pourquoi c’est un problème.

Il se peut que vous ayez plusieurs sites Web qui ont la même structure (c’est souvent le cas lorsque vous avez différentes langues). Il est logique d’avoir le même tag sur ces différents domaines pour pouvoir déployer les mêmes personnalisations sur tous en une seule fois. Ce n’est pas la façon la plus optimale de le faire, mais à ce jour, c’est la façon la plus facile de le faire avec notre outil.

Cependant, si vos sites Web sont tous différents, il n’y a absolument aucun intérêt à le faire. Vous allez créer de nombreuses campagnes (dans ce cas, des centaines !) qui ne seront presque jamais exécutées sur le site Web (parce que ce n’est pas le bon domaine), mais qui seront quand même partiellement incluses dans le tag. Ainsi, celui-ci va passer son temps à vérifier des centaines de campagnes qui n’ont aucune chance de s’exécuter car l’URL sera rarement valide.

Bien que nous travaillions sur un moyen de bloquer ce comportement (car nous avons des alternatives et de meilleures options), il faudra des mois avant que ces données ne disparaissent du rapport.

Note : si vous commencez à utiliser AB Tasty, on ne vous conseillera pas de faire cela et par conséquent, les performances de votre tag seront bien meilleures que celles-ci.

Encore une fois, je n’ai pas pris le temps de regrouper tous les domaines dupliqués car cela n’a pas de sens, le but étant de démontrer qu’il est facile d’améliorer les performances en excluant des anomalies qui ne sont pas représentatives. En ne conservant qu’un seul domaine dans le cas cité précédemment, nous pourrions imaginer une amélioration de plus de 200 ms de nos performances globales.

J’ai pris le cas le plus évident, mais un rapide examen du reste des données m’a montré d’autres exemples.

Les résultats de nos concurrents

Ayant en tête ce que nous avons évoqué précédemment et comment notre score peut sembler pire que ce qu’il est réellement à cause d’une seule anomalie, j’ai commencé à examiner les chiffres de nos concurrents pour voir s’ils ont le même type de problème.

Je le répète : je n’essaie pas de dire que nous sommes meilleurs (ou pires) que nos concurrents, ce n’est pas mon propos. Je cherche simplement à vous montrer pourquoi les statistiques doivent être analysées en profondeur pour éviter toute erreur d’interprétation.

Commençons par comparer les chiffres d’AB Tasty de février 2023 avec ceux de l’un de nos concurrents, selon les mêmes mesures évidemment.

Competitor's figures

En général, ils semblent un peu meilleurs, n’est-ce pas ? Une meilleure moyenne et même les moyennes pour chaque moitié sont meilleures (celle de la moitié inférieure est nettement meilleure !).

Cependant, la différence entre les deux moitiés est énorme : 24 ! Cela signifie-t-il que selon l’utilisation qui en est faite, l’impact du tag pourrait être multiplié par 24 ?

Si je voulais les taquiner un peu, je dirais que lors de tests de leur tag sur votre site Web, vous pourriez constater d’excellentes performances, mais lorsque vous commencez à l’utiliser intensivement, vous pourriez rencontrer de sérieuses baisses de performance.

Mais, ce ne serait qu’une interprétation d’une très petite partie de ce que disent les données.

De plus, ils ont plus du double du nombre de sites Web qui dépassent le seuil de 6 000 ms (encore une fois : ce seuil est une référence interne à AB Tasty). Et cela, même en conservant les doublons que nous avons repérés ensemble précédemment ! Ils ont également des doublons, mais pas autant que nous.

Une première conclusion (prématurée) serait qu’ils présentent davantage de sites web sur lesquels leur impact est grand, mais que la moyenne globale est tirée vers le bas par une majorité d’autres sites.

Maintenant que je sais que dans notre cas, nous avons plusieurs clients qui ont des doublons, je voulais vérifier si nos concurrents rencontrent le même problème. Et c’est le cas pour celui-ci.

Parmi les 2 537 sites Web analysés, 40 % d’entre eux appartiennent au même client. Cela représente 1 016 sous-domaines du même domaine.

Comment cela impacte-t-il leur score ?

Eh bien, leur client n’utilisait pas la solution au moment où les données ont été collectées (j’en ai fait moi-même la vérification en visitant certains des sous-domaines). Cela signifie que le tag ne faisait absolument rien. Il était présent, mais inactif.

Le temps d’exécution moyen de ces 1 016 lignes de données est de 59 ms !! 😭 Elle a également une valeur maximale de 527 ms et une valeur minimale de 25 ms.

Je n’ai pas besoin d’expliquer pourquoi cette « anomalie » tire curieusement leur moyenne vers le bas, n’est-ce pas ?

Attention, ces 1 016 sous-domaines ne sont pas de faux sites Web. Je ne sous-entends pas que ce concurrent a triché délibérément pour paraître meilleur – je suis sûr que ce n’est pas le cas. C’est juste une très belle coïncidence pour eux, qu’ils en soient conscients ou non.

Pour conclure, comparons la moyenne de nos deux ensembles de données après avoir supprimé ces 1 016 sous-domaines.

AB Tasty est à 1 223 ms (ensemble de données non modifié) tandis que ce concurrent est maintenant à… 1 471 ms.

Ils sont passés de 361 ms meilleur que nous à 248 ms moins bien. Je vous ai dit que je peux faire dire aux chiffres ce que je veux. 🙂

J’aurais beaucoup d’autres choses à dire sur ces ensembles de données, mais je n’ai pas réalisé toutes les analyses qui auraient pu être effectuées ici. J’ai déjà passé trop de temps dessus, pour être honnête.

J’espère cependant avoir réussi à montrer que le même ensemble de données peut être interprété de bien des manières différentes.

Que pouvons-nous conclure de tout ça ?

La première chose que je veux dire, c’est : TESTEZ.

Notre solution est très facile à mettre en place. Vous placez simplement le tag sur votre site Web et effectuez un audit. Pour comparer, vous pouvez placer le tag d’un autre outil sur votre site Web et effectuer le même audit. Effectuez-le plusieurs fois dans les mêmes conditions et comparez. Le deuxième outil est-il meilleur sur votre site Web ? Très bien, alors il fonctionnera probablement mieux pour votre cas spécifique.

Est-ce qu’un rapport aléatoire sur le Web affirme qu’une solution est meilleure qu’une autre ? Très bien, c’est un point de vue, mais vous devriez soit analyser les données pour le remettre en question, soit ne pas y accorder trop d’attention. Accepter simplement les chiffres tels qu’ils sont affichés (ou pire : vendus…) pourrait vous faire passer à côté d’une grande partie de l’histoire.

Est-ce que AB Tasty a de mauvaises performances ?

Non, ce n’est pas le cas. La plupart de nos clients ne se sont jamais plaints des performances et certains sont très reconnaissants pour les dernières améliorations que nous avons apportées à ce sujet.

Donc certains clients se plaignent ?

Oui. Cela arrive parfois qu’AB Tasty ait des performances inférieures en fonction de l’utilisation qui en est faite. Mais nous fournissons des outils pour vous aider à tout optimiser directement depuis notre plateforme. Nous l’appelons le Centre de Performance. C’est une section de notre outil dédiée à vous montrer quelle campagne a un impact sur vos performances et ce que vous pouvez faire pour l’optimiser. Il vous suffit de suivre les directives et tout ira bien. C’est une fonctionnalité très innovante et unique sur le marché, et nous en sommes très fiers.

Cependant, je dois admettre que quelques clients (seulement quelques-uns) ont des attentes irréalistes en matière de performances. AB Tasty est un tag JavaScript qui effectue des manipulations du DOM, des vérifications asynchrones, de la collecte de données et beaucoup d’autres choses complexes. Bien sûr, cela aura un impact plus important sur votre site Web qu’un simple outil d’analyse. Votre objectif est de vous assurer que l’impact de l’optimisation de vos conversions est supérieur à son coût en termes de performances. Et cela sera le cas, quel que soit l’outil d’optimisation des taux de conversion que vous utilisez, sauf si vous utilisez un outil côté serveur-side comme Flagship d’AB Tasty, par exemple.

Je suis convaincu que nous devrions aller chercher un site Web encore plus rapide. Je suis très préoccupé par mon impact sur l’environnement, et j’essaie de garder mes appareils aussi longtemps que possible. Mon smartphone a 7 ans (et je suis en train de passer à un “nouveau” qui en a 10) et mon ordinateur portable n’est pas très récent non plus. Donc, je sais qu’un site Web lent peut être une véritable source de frustration.

Le mot de la fin

Permettez-moi de vous assurer que chez AB Tasty, nous sommes pleinement engagés à optimiser nos performances. Cela est motivé par les attentes de nos clients, ma propre motivation personnelle et le défi amusant et intéressant que cela représente pour notre équipe (et aussi parce que ma direction me le demande 😅).

Je tiens également à féliciter HTTP Archive qui effectue un travail très important en collectant toutes ces données et en les partageant avec tout le monde. Félicitations à Patrick Hulce qui a pris le temps de construire un site Web très intéressant qui aide les gens à avoir une représentation visuelle des données de HTTP Archive. Félicitations à tous ceux qui travaillent pour construire un Web meilleur, plus rapide et plus sécurisé, souvent gratuitement et parce qu’ils y croient.

Vous souhaitez tester notre outil par vous-même ? AB Tasty est la plateforme best-in-class pour les expérimentations, la personnalisation de contenu et les recommandations alimentées par l’IA, équipée des outils dont vous avez besoin pour créer une expérience digitale plus riche pour vos clients, rapidement. Avec l’IA intégrée et l’automatisation, cette plateforme peut vous aider à atteindre une personnalisation omnicanal et révolutionner les expériences de votre marque et de vos produits.

 

Vous pouvez trouver le lien de l’article original ici.

Vous aimeriez aussi...

Abonnez-vous à
notre Newsletter

bloc Newsletter FR

La politique de confidentialité d'AB Tasty est disponible ici.