Gérer la performance dans un projet de tag JavaScript : le récit d’un Product Manager #1.
Je suis Product Manager chez AB Tasty, et aujourd’hui je vous parle du projet d’amélioration des performances de notre tag JS.
Performance du tag, Total Blocking Time, main thread, Core Web Vitals, SEO, monitoring, audit performance,…
Ça, ce sont les mots qui rythment mon quotidien depuis le mois de Décembre 2020. Intéressé par le sujet ? Restez donc lire le point de vue d’un Product Manager d’un tag JavaScript.
D’abord, qui je suis ?
En très bref, je suis Product Manager chez AB Tasty. AB Tasty est un outil SaaS qui permet à ses utilisateurs de doper les performances commerciales de leur site web par la mise en place d’A/B Tests, de personnalisations, de widgets et de plein d’autres trucs.
Le plus important à retenir c’est que la magie de notre technologie repose sur une phrase très simple que tous nos clients ont entendu lorsqu’ils n’étaient alors que des prospects : “ben vous avez juste à mettre notre tag sur votre site et, bim !, tout est prêt.”.
Et c’est vrai : à quelques exceptions près, vous mettez notre tag sur votre site et la solution est prête à fonctionner à 99% de ses fonctionnalités.
Il y a cependant un principe qui tend à devenir de plus en plus vrai à mesure que les équipes tech/produit s’investissent de plus en plus dans ces projets et que prolifèrent les notions de “low-code/no-code” (ce qui est paradoxal, vous allez voir) c’est que si tu veux être au top des performances, tu ne peux pas QUE te contenter de “mettre un tag et voilà”.
Les attaques magiques ont un coût en mana dans les jeux vidéos, elles ont un coût en performance dans le monde du numérique.
(hop, la référence geek est placée)
J’ai hérité du périmètre Tag vers début 2020. En Décembre, Google annonce en fanfare que les performances d’un site joueront un rôle important dans son référencement naturel (SEO). Forcément, les clients commencent à faire des audits, nous secouent et on déclenche des réunions de crise en interne.
Les règles de Google restent, aujourd’hui encore, très floues et mouvantes, mais on s’en accommode. Ça me rappelle la CNIL et la gestion du consentement utilisateur avec ePrivacy (oui, l’autre sujet tumultueux que j’ai dû gérer en parallèle).
C’est acté : on bosse sur la performance jusqu’à ce que mort (des problèmes) s’ensuive, on recrute des devs et on forme une équipe dédiée.
Aujourd’hui, en Janvier 2022, ça fait pratiquement 1 an que je bosse sur le sujet et je peux d’ores et déjà vous donner les sujets sur lesquels on est devenu experts avec mon équipe :
- la compréhension du monstrueux onglet “Performance” de Chrome
- la compréhension des Core Web Vitals, leur impact et le rythme auquel leurs spécifications changent (spoiler: t’as pas idée)
- le jeu d’équilibriste entre le “Plug’n Play” (fun fact, le terme Plug’n Play a été démocratisé avec Windows 95) et le “tag sans impact”.
Ce projet est en revanche un excellent cas d’école que je souhaitais partager au plus grand nombre. Il est bourré d’enseignements (pour moi et mon équipe en tout cas, je ne me considère pas apte à vous donner un cours) et beaucoup plus intéressant à regarder maintenant qu’on n’est plus très loin de la fin. 🤞
Disclaimer
J’ai beau avoir travaillé 12 mois avec mon équipe sur le sujet, je suis loin d’avoir tout compris. Je me targue d’avoir mieux compris que beaucoup de mes interlocuteurs et au sein d’AB Tasty l’équipe est clairement la mieux placée pour parler de ce sujet. En revanche, je ne suis pas un expert et des erreurs d’interprétation peuvent s’être glissées dans mes analyses. Comme toute information disponible librement sur Internet, traitez-la avec des pincettes et remettez la en question si doute il y a.
La situation pré CWV-era
Le sujet de la performance d’un tag JavaScript a toujours été sur la table. On a toujours eu des sprints, des “task-forces”, bref, des rushs, pendant lesquels on a optimisé, allégé, refacto le tag pour contenter des utilisateurs mécontents (à plus ou moins juste titre, selon les cas).
Ca a toujours été un sujet parmi d’autres néanmoins, et l’année écoulée est la première qui a vu l’objectif “Performance” rester en tête de gondole jusqu’à en devenir la priorité numéro 2 de l’entreprise.
Un autre sujet, intimement lié, et qui explique pourquoi la question de la perf est particulièrement importante dans le cadre de notre outil est celui du flickering.
On appelle flickering le fait de voir la version originale d’un site web avant de voir sa version modifiée (comprendre => A/B testée ou personnalisée), et ce pendant un temps qui va d’un battement de paupière au temps nécessaire pour réaliser une moue dubitative devant l’étrangeté du phénomène.
J’ai toujours eu du mal à savoir dans quel sens prendre le problème du flickering. Il est en effet extrêmement dépendant de l’implémentation qui est faite de notre tag et de la manière dont les campagnes de tests sont conçues. Il y a même certain cas où il n’y a absolument rien que nous puissions y faire, notamment dans le cas où le site se charge de manière extrêmement rapide : tu appelles une ressource externe sans bloquer le rendu de ta page => ça prend du temps et tu as du flickering.
C’est d’autant plus frustrant que la vision de l’utilisateur qui s’attend à voir un flickering est fatalement plus biaisée que celle du visiteur qui surfe sur son site préféré en demie-4G et qui, naturellement, ne se charge pas tout d’un bloc. Qu’un élément supplémentaire change de position ou de couleur sous ses yeux ne devrait pas l’alarmer plus que cela, on le vit tous au quotidien.
C’est un autre sujet qui mériterait un autre article, mais c’est essentiel pour comprendre les problématiques de performance et résume bien notre position d’équilibriste : il faut afficher les modifications aussi vite que possible mais sans bloquer le chargement du site. 🤯
Cela met pas mal en valeur notre difficile travail pour lequel on doit réussir à trouver le bon compromis entre afficher les variations rapidement mais ne pas trop impacter les performances du site web.
Puis est arrivé Google, avec ses Core Web Vitals et sa décision d’impacter le référencement en fonction des performances du site web. L’impact n’est pas encore vraiment là, si j’en crois les sources semi-officielles, en revanche ça a bel et bien eu pour effet de déclencher de très nombreuses réunions avec des clients inquiets (à juste titre !) et des réunions d’urgence en interne.
Temps de téléchargement vs temps d’exécution
Je suis un geek. J’ai compris dès ma pré-adolescence que la rapidité de la connexion Internet n’a rien à voir avec la puissance du CPU. Pourtant, il n’était pas évident tout de suite que la même logique s’applique à des tags JavaScript.
Notre métrique principale a toujours été les temps de téléchargement, les fameux “< 100 ms”, qui sont facilement visibles par n’importe qui et représentatif de la capacité d’AB Tasty (ou de n’importe quelle autre tierce partie) à délivrer son script le plus rapidement possible en fonction de la géolocalisation de l’internaute.
Etait-ce parce que ça nous arrangeait bien ? Il faut dire que la partie infrastructure (CDN en tête) d’AB Tasty a fait maintes l’objet de gros travaux et a aujourd’hui atteint un niveau d’excellence grâce au travail de notre équipe DevOps qui l’a optimisé aux petits oignons et continue de se tenir informé des derniers standards pour l’ajuster en permanence.
Etait-ce parce que c’est ce que le marché regardait ? Je penche davantage sur cette solution. Les précieuses millisecondes de téléchargement était l’indicateur clé permettant d’attester de la performance d’un outil tiers.
Aujourd’hui, tout a changé. Google, via ses Core Web Vitals s’intéresse à beaucoup d’autres métriques EN PLUS de la vitesse de téléchargement. Mon côté militant (ou masochiste) pour un web simple, rapide et clair me ferait m’écrier “TANT MIEUX”. Mon côté Product Manager a plutôt réagi de manière assez pragmatique en constatant que personne, sauf quelques experts ultra pointus, ne comprend exactement comment les multiples ressources JavaScript impactent l’exécution des sites web et encore moins les Core Web Vitals.
Allez, pour le plaisir, une liste de choses importantes qu’on a (que j’ai) (re)découvertes au fur et à mesure lors de ce projet :
- Les navigateurs n’ont qu’un seul processus principal (main thread). Il est dédié à la peinture (oui, oui, c’est le terme) du site web. Toutes les ressources JavaScript qui l’occupent retardent d’autant l’affichage du site.
- Les navigateurs peuvent récupérer plusieurs ressources synchrones en parallèle. Sauf que le nombre exact dépend du navigateur 😵. Pour des raisons de marché, on ne s’intéresse qu’à Chrome et Safari. Désolé petit panda roux, RIP les valeurs du libre.
- Google s’intéresse particulièrement aux “long tasks”, ces tâches JS qui prennent plus de 50 ms (oui c’est court). Chacune d’elle va impacter négativement le score Lighthouse.
- Les Core Web Vitals, en dehors du fait qu’elles changent tous les 4 matins, ont une définition et des interactions entre elles très spécifiques et qu’il est essentiel de bien comprendre. Dans un prochain épisode vous entrerez avec moi dans le beau monde des Time To Interactive et First Contentful Paint.
- L’onglet Performance de Chrome est aussi incompréhensible qu’une peinture contemporaine. MAIS, il est aussi incroyablement utile et riche d’informations quand on prend le temps de bien le connaître.
- Les mesures de performance sont à prendre avec des pincettes. On en fait, nos clients en font, les agences des clients en font, Google en fait, mais jamais elles ne diront la même chose. Il faut comprendre leur caractère indicatif, leur particularité et surtout apprendre à les analyser.
D’ailleurs, la partie mesure, c’est exactement le thème de notre prochain chapitre.
Mesurer, mesurer, mesurer
C’est le b-a-ba du Product Management, on ne commence pas à travailler avant d’avoir mesuré / qualifié.
Je l’ai dit plus haut, notre seul indicateur connu jusque-là était le temps de téléchargement. Cet indicateur, depuis longtemps dans les honneurs chez AB Tasty car excellent, cachait néanmoins l’abominable vérité : oui, il y a des cas, beaucoup de cas, où le tag AB Tasty est un enfer pour le CPU de nos chers visiteurs, particulièrement les moins bien lotis, et ce indépendamment du temps qu’il met à se télécharger.
Lorsque que la bombe de Google a été lâchée, on s’est retrouvé face à une montagne d’indicateurs qui ne nous parlaient pas plus que ça, les fameux Core Web Vitals et leurs dérivés.
La première étape a donc été de prendre le temps de comprendre et d’analyser.
Première douche froide : la compréhension, ça ne se provoque pas. Il faut pratiquer, voir des cas différents, tester, bouger des paramètres et seulement là on commence à comprendre. 12 mois après, on continue encore à comprendre des choses essentielles.
Seconde douche froide : analyser, c’est vraiment pas simple. D’une part, parce que chaque environnement client est différent (mais genre, VRAIMENT), ensuite parce qu’AB Tasty a un spectre de fonctionnalités (et donc d’impact) plutôt grand. Enfin parce qu’on s’est vite rendu compte que l’on impactait pas toujours les mêmes indicateurs, donc retour à l’étape de compréhension dont je viens de parler.
Je vous passe évidemment les difficultés d’implémentation d’un tel monitoring de masse, nécessitant de ne pas se faire passer pour un bot, de contourner les cookies-walls (kikoo la CNIL 👋) et d’assurer la constance dans le temps.
Je suis honnêtement plutôt satisfait de la solution que l’on a retenue. Exit le monitoring de masse, c’est irréaliste, on est plutôt parti sur un suivi site web par site web en fonction de la demande et de nos besoins. Cela nous a permis de vérifier le bon fonctionnement du monitoring et surtout sa pertinence.
Toutes les heures, un robot se rend sur une liste d’URL qu’on lui fournit et effectue deux mesures en utilisant l’API de Lighthouse : la première, sans restriction, la seconde, en bloquant le tag AB Tasty. Le résultat complet est récupéré et un point est dessiné sur un graphique. Chaque élément mesuré par Lighthouse a son propre graphique. On se retrouve donc avec une bonne vingtaine de graphiques possédant chacun 2 points (avec et sans AB Tasty) par heure.
Pour être encore plus pertinent, chaque nouvelle release du tag change de couleur sur le graphe afin d’identifier précisément l’incrément.
Voici les enseignements principaux :
Avec AB Tasty vs sans AB Tasty
Tout d’abord, ce graphique nous permet d’avoir une vue immédiate, précise et neutre (oui, j’ose employer ce terme en parlant de Lighthouse) de l’impact réel d’AB Tasty sur un site web.
Spoiler alert: y a des clients sur qui l’impact est colossal, d’autres sur lequel l’impact est inexistant.Dans cette deuxième catégorie, on a quand même des clients qui se plaignent des performances. Alors, rêve d’un objectif irréaliste ou problème de non utilisation des mêmes méthodes de mesure ? A vous de voir, je n’ai pas encore décidé.
J’apprendrais 9 mois plus tard (🐣) que l’impact d’AB Tasty sur certaines métriques dépend lui-même de la performance du site web en général, le serpent qui se mord la queue en somme.
La métrique que l’on impacte le plus sévèrement
Ahah, glad you asked.
En vrai ? Ca dépend.
Voilà, c’est tout.
L’usage d’AB Tasty vs les scores Lighthouse
On a autant de typologie d’environnement que de clients. Chaque monitoring est différent, et c’était très déroutant au début. En creusant, on arrive à relier un impact à l’usage de telle ou telle fonctionnalité, mais ce n’est pas toujours évident et nécessite une étude au cas par cas.
Au final, c’était une étape très importante pour déterminer à quel point AB Tasty avait un impact, sur quelles métriques et en fonction de quel usage.
En revanche, on était encore loin d’avoir tout compris.
Les Core Web Vitals
Au final, avoir les mesures sous les yeux en permanence et le fait de les présenter aux clients demandeurs nous a obligé à bien comprendre ce qu’elles signifiaient exactement.
Au lieu de vous rediriger vers un article d’experts vous expliquant mieux que moi chacun des CWV (vous saurez le faire vous même de toute façon), je vous en donne une explication avec mes mots :
- Le score principal est simplement une compilation pondérée de tous les autres indicateurs, sur 100. Cf leur calculateur : https://googlechrome.github.io/lighthouse/scorecalc/#FCP=1160&SI=3070&LCP=2500&TTI=4090&TBT=350&CLS=0.09&FMP=2075&FCI=18124&device=mobile&version=6
- Le Total Blocking Time est le temps pendant lequel le main thread est bloqué sur le chargement des ressources additionnelles (coucou les tags synchrones).
- Le Cumulative Layout Shift est le rapport de décalage visible des éléments sur la page. Pour visualiser : si un carrousel apparaît tardivement, il y a fort à parier qu’il va pousser une bonne moitié de la page vers le bas. Votre CLS va être gargantuesque.
- Le First Contentful Paint est le moment où le premier élément pertinent du site a été peint (en général, la structure grossière)
- Le Largest Contentful Paint est le moment où le plus gros élément pertinent du site a été peint (les bannières, carrousels et autres gros blocs, mais Lighthouse ne garde que le plus large)
- Le Speed Index, honnêtement je n’ai pas encore vraiment compris ce qu’il mesure précisément
- Le Time To Interactive, qui est une métrique qui m’intéresse particulièrement et qui va faire l’objet d’un paragraphe dédié ⬇
Comme dit plus haut, Google n’aime pas les “longs tasks”, ces tâches de 50 ms minimum qu’il accuse d’être le frein principal à l’interactivité de la page. Tant qu’il y a des long tasks qui tournent, Lighthouse considère que la page n’est pas encore interactive. Il faut un minimum de 5 secondes sans long tasks pour que le TTI soit validé et ramené à 5 secondes en arrière (jusqu’à la fin de la dernière long task quoi).
De ce que je comprends, le TTI est aussi le moment où Lighthouse arrête de mesurer. En d’autres termes, si vous avez un script, type AB Tasty, qui exécute beaucoup de petites choses entre l’initialisation et le TTI, il sera d’autant plus représenté dans Lighthouse. En d’autres termes, encore, si votre TTI est extrêmement élevé pour des raisons diverses et variées, l’impact des scripts qui font plein de petites choses sur le site sera amplifié de manière extrême.
Vous devez voir que je vous prépare le terrain : à cause de certaines spécificités des CWV, TTI en tête, l’impact d’AB Tasty est parfois injustement amplifié. Je ne suis pas du genre à chercher des excuses, et ça ne nous empêchera pas de nous adapter comme précisé plus tard dans cette série d’articles !
Les impacts d’AB Tasty sur les CWV
L’impact direct d’AB Tasty est limité à certaines CWV spécifiques. On en a déjà parlé, et de toute évidence, le Total Blocking Time ne nous aime pas trop, puisqu’on ralentit forcément le chargement de la page.
Mais de manière plus vicieuse, AB Tasty va probablement impacter le FCP, LCP et CLS. Pourquoi j’insiste sur le terme “probablement” ? Parce que ça va dépendre de l’usage que vous en ferez.
Si vous supprimez et/ou créez des blocs entiers, forcément votre CLS va en prendre un coup. Plus ces blocs seront nombreux et massifs (proportionnellement au reste des blocs qui ne bougent pas), plus l’impact sera grand.
Je vous arrête tout de suite, le principe même de l’A/B Testing est de modifier des choses sur votre site web, donc ne vous arrêtez pas à ça, il est tout à fait OK d’avoir un peu de CLS.
En revanche, voici quelques idées de ce que vous pouvez faire pour limiter sa croissance :
- Prévoir des blocs (vides ou non) dans lesquels s’appliqueront les campagnes. Le contenu changera, mais les autres blocs ne seront pas poussés pour lui faire de la place. Ça demande pas mal d’agilité de votre côté niveau devs, mais c’est loin d’être inenvisageable.
- Privilégiez toujours les modifications de blocs existants en prenant soin de conserver la taille de leur enveloppe. Le procédé sera totalement transparent d’un point de vue décalage.
- Évitez les changements d’envergure 100% géré par AB Tasty : la création de hero banner, les carrousels et ne chargez pas d’images trop lourdes qui prendront des plombes à se télécharger.
De la même manière, charger et/ou changer le plus gros bloc de la page va nécessairement impacter le LCP.
La mauvaise nouvelle pour vous donc, c’est qu’a priori vous allez devoir vous intéresser sérieusement à la manière dont ces métriques sont calculées (et comment elles évoluent dans le temps !) pour mesurer si vos campagnes d’optimisation ne sont pas trop à risque. C’est un coup à prendre, donc ça devrait aller, et j’espère que cette première partie vous aura aidé à y voir plus clair, mais il y a des tonnes d’autres ressources bien plus précises qui traînent de-ci de-là.
L’onglet Performance de Chrome : entre enfer et paradis.
Qu’on ne se mente pas : Chrome, que ce soit souhaitable ou non, est aujourd’hui le navigateur le plus utilisé (même le successeur d’Internet Explorer, Edge, repose sur les mêmes fondations !). Rien d’alarmant donc à ce que nos développements soient principalement faits sur Chrome. De la même façon, quand nous auditons les performances de notre tag, ce sera presque exclusivement sur la navigateur de Google.
Chrome propose d’ailleurs un onglet extrêmement intéressant dans sa console pour développeurs : l’onglet Performance.
Cet outil est typique des meilleurs outils informatiques : illisible, inutilisable en un coup d’oeil et avec une UX contestable pour celui qui ne prend pas le temps de s’y pencher. J’ai été contraint malgré moi de m’y pencher sérieusement et je ne regrette pas. Maintenant que je le maîtrise (en grande partie), c’est pratiquement la meilleure source de vérité et d’analyse que j’ai pu trouver à ce jour.
Dans cet outil, vous avez absolument tout : les timings et durée de téléchargement des ressources (tierces ou pas), le détail de chaque frame, le détail de l’exécution de chaque script avec leur fonction précise ainsi que leur durée, les timings des Core Web Vitals, les tâches longues et plein d’autres choses encore.
Bref, mon nouveau fond d’écran.
Retrouvez la suite de cette aventure dans un prochain épisode littéraire !
