Deux versions de tags sont aujourd’hui disponibles chez AB Tasty : une version synchrone et une autre asynchrone. Ce billet de blog vise à décrypter ce qui se cache derrière ces 2 notions et leurs implications pour bien comprendre lequel choisir.
La performance web au coeur des débats
Ce n’est plus un secret pour personne, les performances techniques de votre site ont un impact majeur sur vos taux de transformation et vous devez vous assurer que les pages de votre site se chargent le plus rapidement possible pour offrir une expérience fluide à vos utilisateurs qui sont de plus en plus impatients et s’attendent à un niveau de performance élevé. Quelques centaines de millisecondes peuvent avoir un impact de plusieurs centaines de milliers d’euros, voire plus, à l’image d’Amazon qui a chiffré que toutes les 100 ms gagnées correspondaient à 1 % de CA additionnel.
En parallèle, vos besoins de tracking sont de plus en plus importants, car vous faites appel à de multiples solutions, notamment concernant l’acquisition de trafic, lesquelles nécessitent que vous ajoutiez leur tag JavaScript à vos pages pour mesurer les performances de vos campagnes. Chaque nouveau tag vient donc augmenter un petit plus le poids de vos pages. On comprend alors aisément pourquoi certains éditeurs sont fébriles dès qu’une nouvelle solution doit être installée. Leur principale crainte tient naturellement au fait qu’ils ne maitrisent pas l’infrastructure derrière ces solutions et n’ont pas de garantie qu’elle soit toujours disponible (notion d’uptime). Le risque est alors que le tag, faisant un appel aux serveurs de la solution et n’ayant pas de réponse, bloque le chargement de la page du client. Il existe heureusement une parade à ce problème qui consiste à utiliser des tags asynchrones, en lieu et place des traditionnels tags synchrones.
Les modes synchrone et asynchrone
Schématiquement, en mode synchrone, les scripts sont chargés les uns à la suite des autres de façon séquentielle : un script ne peut être chargé que si le précédent a fini d’être chargé. Si, dans la liste de tous les scripts appelés, l’un d’eux ne se charge pas, il bloque alors le chargement de tous les autres, pouvant aller jusqu’à bloquer le rendu de la page. Pour limiter ce risque, on a longtemps suggéré de placer l’ensemble des scripts en bas de page pour éviter ce scénario catastrophe : tous les éléments importants pour le rendu de la page ayant déjà été chargé, le mal est moindre si un script pose problème. Dans la pratique cela n’est pas toujours possible ou recommandé, notamment pour des raisons de fiabilité du tracking. À l’inverse, en mode asynchrone, les appels aux différents scripts se font en parallèle et votre navigateur n’empêche pas l’exécution d’un script si un autre échoue. Cela veut également dire qu’il n’est pas possible de contrôler précisément l’ordre d’exécution des scripts.
Compte tenu de leurs avantages, les tags asynchrones sont vite devenus la panacée dans le milieu des solutions technologiques pour rassurer leurs clients sur cet enjeu de performance, et sont aujourd’hui la solution recommandée pour la plupart des outils (ex. : tracking des campagnes d’acquisition, mesure d’audience, collecte de données, etc.).
Quelle version utiliser pour le testing ?
Dès lors qu’une nouvelle solution veut montrer patte blanche chez un éditeur, la disponibilité d’une version asynchrone de son tag est donc un prérequis et nombreux sont ceux qui le réclament pour les solutions de testing. Si ces dernières peuvent sans difficulté se plier à cette demande en fournissant une version asynchrone de leur tag (ce qui est le cas chez AB Tasty), c’est malheureusement oublier les spécificités de leur fonctionnement. Celles-ci ne se contentent pas de collecter des données, elles appliquent également des modifications visuelles sur les pages.
Concrètement, le tag de la solution de testing appelle un fichier JavaScript qui va s’auto-exécuter dès qu’il est reçu par le navigateur de l’internaute. Ce fichier contient le code qui va modifier les éléments de la page et manipule le DOM (Document Object Model) qui schématiquement contient tous les éléments constituant votre page. L’application de ces modifications fait face à un enjeu d’immédiateté important pour respecter l’expérience utilisateur. En effet, si les modifications sont appliquées avec un délai de quelques centaines de millisecondes, l’utilisateur final peut noter un effet de scintillement et voir très temporairement la version initiale puis la version modifiée. Ce n’est, d’une part, pas acceptable pour son expérience de navigation et d’autre part pour la fiabilité de votre expérimentation puisqu’il peut se rendre compte qu’il participe à un test (on parle d’effet Hawthorne). C’est pour cette raison que le mode synchrone reste à privilégier pour les solutions de testing. NB : si le mode synchrone s’impose pour l’application des modifications, la collecte des données, elle, s’accommode très bien du mode asynchrone.
Exigez des garanties au niveau des performances !
Les spécificités et les conditions du bon emploi des solutions de testing étant rappelées, les inquiétudes techniques évoquées au début de cet article refont surface. C’est à votre prestataire de dissiper vos doutes en vous apportant des garanties sur la performance de son infrastructure technique. Chez AB Tasty, nous avons mis en place plusieurs optimisations pour limiter le temps de chargement de notre script.
- Nous utilisons un fichier statique mis en cache suite à son premier appel (ce qui évite d’avoir à effectuer de nouvelles requêtes au cours de la même session).
- Nous limitons également le poids de ce fichier en y intégrant que le code nécessaire aux tests actifs, contrairement d’autres solutions.
- Nous diffusons également ce fichier plus rapidement (moins de 100 millisecondes pour le premier appel) en le distribuant sur de multiples serveurs géographiquement proches de l’internaute. C’est le principe du Content Delivery Network (CDN).
- Nous travaillons avec plusieurs d’entre eux et faisons également appel un prestataire de CDN balancing qui permet d’acheminer les requêtes vers les CDN les plus rapides à un instant T.
- D’autres optimisations plus complexes sont également mises en œuvre.
Si, malgré toutes ces précautions, vous doutez encore de l’infrastructure de vos potentiels prestataires, nous ne pouvons que vous conseiller de comparer leurs performances.
- Prêtez attention à leurs références clients. Travaillent-ils avec des sites à forte volumétrie et à fort enjeu de performance, comme des sites e-commerce majeurs ?
- Effectuez des benchmarks et des mesures techniques.
- Demandez des engagements de services sur ces points (Service Level Agreement).
