Tags synchrones et asynchrones, et l’art d’éviter l’effet flicker

Qu’ils soient utilisés pour mesurer l’audience de son site, pour afficher des contenus publicitaires ou pour réaliser des tests A/B, les tags sont omniprésents et de plus en plus utilisés sur les sites web. Ces petits bouts de code permettent de relier le serveur de votre site web et les serveurs des applications tierces que vous utilisez (logiciels analytics, régies publicitaires, outils de tests A/B…).

Désormais, la plupart des solutions tierces proposent de choisir entre tag synchrone et tag asynchrone. Qu’est-ce que c’est ? Quelle est la différence entre les deux ? Quel format choisir ? Comment éviter « l’effet Flicker » associé aux tags de testing asynchrones ? Répondons sans plus attendre à toutes ces questions. On revient aussi à la fin de l’article sur la solution « magique » anti-flicker proposée par Kameleoon depuis quelques semaines.

Tag synchrones & Tags asynchrones

Retour sur la définition d’un tag dans le contexte du marketing digital

Dans le contexte du marketing digital, un tag (en français, on parle aussi de « balise ») est un bout de code inséré dans le code source d’une page web provoquant un appel de données vers un serveur tiers lors du chargement de la page par l’internaute. Un tag peut avoir plusieurs destinations et prendre différentes significations. On rencontre notamment des :

• Tag analytics : le tag permet d’enregistrer les données de navigation du site web et de les faire remonter vers le serveur de la solution analytics. Un tag analytics (on parle aussi de tag de tracking) sert à mesurer l’audience et la conversion d’une page ou d’un site.
• Tag publicitaire : dans ce cas, le tag fait appel à un serveur publicitaire et permet d’afficher des contenus publicitaires ciblés sur la page.
• Tag de testing : permet d’afficher des variantes d’une page web de référence et de faire des tests de performance. Les tags de testing, comme les tags publicitaires, permettent d’afficher sur une page web des éléments extérieurs, en provenance d’une application tierce (logiciel de testing ou régie publicitaire).

Les tags permettent de générer des flux entre le site web et les solutions tierces utilisées. L’extrait de code que constitue le tag est le plus souvent fourni par la solution tierce elle-même. Un tag peut être intégré sur une seule page (code testing) ou sur tout le site (par exemple, le code d’une solution d’analytics). Il est généralement codé en JavaScript, et l’utilisation de balises HTML ou d’iframes a été largement remplacée par des scripts JavaScript modernes, souvent optimisés pour le chargement différé (lazy loading) et la compatibilité avec les frameworks front-end actuels (comme React, Vue ou Svelte), afin de répondre aux exigences de performance, de sécurité et de respect de la vie privée.

Voici à quoi ressemble un tag :

Différences entre tags synchrones & asynchrones

En choisissant un tag « synchrone », les scripts de votre site se chargent les uns à la suite des autres, de manière séquentielle. On voit tout de suite l’inconvénient des tags synchrones : si un script se bloque, tous les scripts qui suivent seront eux aussi bloqués. En clair, si votre tag bloque, c’est toute la page web qui risque de ne pas s’afficher. Pour éviter ce genre de catastrophe, on a tendance à intégrer les tags synchrones tout en bas des pages. Voici un schéma qui permet de se représenter le fonctionnement d’un tag synchrone (source : Abtasty) :

Lorsque le tag est dit « asynchrone », tous les scripts de la page web se chargent en même temps, c’est-à-dire en parallèle. Si le script du tag bloque, cela ne bloquera pas le chargement des autres scripts de la page.

Les tags synchrones sont problématiques, en raison des problèmes de blocage qu’ils peuvent générer. C’est pour cette raison que la plupart des solutions proposent aujourd’hui une version asynchrone. Certains, comme Google Analytics, ne proposent d’ailleurs plus que la version asynchrone. Sauf que les tags asynchrones ne sont pas sans poser quelques soucis…eux aussi. Cela porte un nom : l’effet Flicker. Nous y reviendrons. Du coup, que faut-il choisir – quand on a le choix ? Tag synchrone ou tag asynchrone ?

Comment choisir entre tags synchrones ou asynchrones (quand vous avez le choix) ?

Encore une fois, si vous utilisez un tag synchrone, un problème de chargement au niveau du script entraîne le blocage de tous les scripts qui suivent. Cela peut avoir des conséquences très dommageables : un temps de chargement de la page très long ou même une page qui ne s’affiche pas… C’est la raison pour laquelle il est globalement conseillé de choisir une version asynchrone pour vos tags – quand on a le choix. D’autant que même lorsqu’il n’y a pas de blocages, un tag synchrone ralentit toujours un peu plus la page qu’un tag asynchrone. Pourquoi ? Parce que lorsqu’on utilise un tag synchrone, les scripts qui suivent le tag ne commencent à se charger que lorsque le script du tag est lui-même chargé. Ce qui peut poser des problèmes lorsque la connexion entre le serveur du site et celui de l’application tierce n’est pas optimale. Lorsque le tag est asynchrone, le reste de la page n’attend pas le chargement du tag pour se charger.

Néanmoins, les tags asynchrones posent le problème de l’effet Flicker – ce qui peut avoir un impact assez négatif sur l’expérience utilisateur. Cet effet Flicker est très problématique pour les tags de testing. De manière générale, il est recommandé de privilégier les tags asynchrones, y compris pour les tags de testing, en s’appuyant sur les fonctionnalités anti-flicker proposées par les solutions modernes.

Des solutions de gestion de tags comme Google Tag Manager, Matomo Tag Manager ou Tealium iQ Tag Management permettent de gérer plus facilement les tags installés sur votre site web. L’intégration de fonctionnalités avancées de gestion de la confidentialité et de la conformité (notamment RGPD) est désormais un critère clé dans le choix d’un tag manager.

L’effet flicker et les bonnes pratiques pour l’éviter

C’est quoi l’effet Flicker ?

« Flicker » signifie « scintillement » en anglais. Sur certains sites francophones, on parle d’ailleurs d’effet de scintillement. Alors, qu’est-ce que l’effet Flicker ? Lorsqu’on utilise un tag synchrone, le reste de la page ne se charge qu’après le chargement du script du tag. Le script du tag est chargé en priorité. Tant qu’il n’est pas chargé, la page reste blanche. Quand on utilise un tag asynchrone, à l’inverse, tous les scripts se chargent en parallèle. Le script du tag perd son caractère prioritaire. Autrement dit, le reste de la page peut se charger avant que le code du script ne soit exécuté

. Cela pose vraiment problème lorsque le tag en question est un tag de testing. Un tag de testing permet de modifier les éléments de la page web – dans une optique de tests A/B. Sauf qu’il arrive parfois que le tag de testing asynchrone se charge en dernier : du coup, la page de référence (version originale) s’affiche un court instant avant d’être remplacé par la variante (la version de test) une fois le tag chargé. Le « court instant », en l’occurrence, se mesure en milli-secondes, mais c’est suffisant pour pour produire le fameux effet Flicker et perturber l’expérience utilisateur. Voici le résultat :

L’internaute voit la version de référence avant de voir la variante. Il prend conscience qu’il est testé, ce qui est assez désagréable. Sans compter que cela fausse les résultats du test. Historiquement, certaines solutions comme Optimizely privilégiaient les tags synchrones pour limiter cet effet, mais la tendance actuelle est à l’adoption de solutions anti-flicker intégrées dans les tags asynchrones, désormais proposées par la plupart des plateformes majeures d’A/B testing. Notons-bien que l’effet Flicker ne concerne que les tags de testing. Le fait qu’un tag de tracking par exemple se charge quelques milli-secondes après l’affichage de la page ne pose en soi aucuns problèmes et n’affecte en rien l’expérience utilisateur.

Bonnes pratiques pour éviter le flickering

Il existe quelques bonnes pratiques qui, mises en application, permettent de limiter l’effet Flicker. Les voici :

• Mettre le tag le plus haut possible dans le code source de la page, dans la balise <head> (avant les webfonts et les scripts JavaScript).
• Améliorer la vitesse de chargement de votre site web, en réduisant le poids des images, en limitant le nombre de plugin, en utilisant un hébergement adapté et un CDN, en faisant de la mise en cache, etc. sur ce sujet, découvrez 9 techniques pour améliorer la vitesse de chargement d’un site WordPress (ces techniques sont valables pour la plupart des CMS).
• Ne pas utiliser de gestionnaires de tags (type Google Tag Manager) pour vos tags de testing. Vous devez les écrire en dur dans le code HTML de la page, afin de pouvoir contrôle l’ordre de chargement des scripts. Il faut que ce soit vos tags de testing qui se chargent en premier.
• Évitez d’utiliser la librairie jQuery dans vos tags, car elle tend à être remplacée par du JavaScript natif ou des frameworks modernes, ce qui réduit le poids des pages et améliore la performance.
• Alléger la taille du script de votre tag de testing en supprimant les tests non actifs. Parfois, le tag de testing intègre tous les tests, y compris ceux qui ne sont pas utilisés ou en brouillon.
• Se reposer le plus possible sur les feuilles de style quand c’est possible (en ajoutant une classe CSS à un élément par exemple), plutôt que d’ajouter plusieurs lignes de scripts.
• Privilégier les solutions tierces qui utilisent un ou plusieurs CDN et qui proposent des points de présence locaux pour réduire la latence, tout en assurant la conformité avec les réglementations locales sur la localisation des données.
• Lors de la création de la version de testing : optimiser le code HTML de la version modifiée de votre page, en supprimant les éléments inutiles (certains scripts JavaScript s’ajoutent parfois inutilement). Plus la version modifiée de la page est différente de la version originale (au point de vue de son code), plus l’effet Flicker aura de chance de se produire.

Dans le cas où l’effet Flicker persisterait, une astuce consiste à cacher le contenu de la page tant que tous les éléments ne sont pas chargés. Plusieurs logiciels de testing y ont recours. Une autre solution consiste à paramétrer un délai d’affichage maximum pour vos tags. Par exemple : une seconde. Si le tag n’est pas chargé au bout d’une seconde, il ne se chargera pas. Cela permet d’éviter l’effet Flicker, en particulier pour les visiteurs qui ont une connexion lente.

Zoom sur la solution « magique » proposée par Kameleoon

Des solutions d’A/B Testing comme Kameleoon, AB Tasty ou Optimizely proposent désormais des fonctionnalités avancées d’anti-flicker, basées sur des techniques telles que les DOM Mutation Observers ou l’injection conditionnelle de styles, afin de limiter l’effet Flicker sur la majorité des navigateurs modernes.

La solution « magique » de Kameleoon se concentre non pas sur l’amélioration du délai de chargement du script, mais sur un nouveau mode d’interaction entre les éléments de la page du site web et la solution tierce une fois le script chargé. L’utilisation des DOM Mutation Observers pour limiter l’effet Flicker est désormais une pratique courante dans l’industrie, compatible avec la grande majorité des navigateurs modernes. Toutefois, il reste important d’appliquer les bonnes pratiques évoquées plus haut pour garantir une expérience optimale sur tous les navigateurs.

Certains concurrents ont essayé de dénigrer cette nouvelle méthode. On peut comprendre pourquoi. C’est en particulier le cas d’ABTasty, pour qui cette solution prétendument magique ne serait en vérité que l’application de vieilles recettes. Nous n’avons pas encore testé la méthode anti-flicker de Kameleoon et n’avons pour le moment aucuns retours clients sur son efficacité ou non. On ne dispose donc pas des éléments suffisants pour trancher.

Pour conclure : très clairement, privilégiez les tags asynchrones. Il n’y a que dans un cas où l’alternative synchrone/asynchrone se discute : celui des tags de testing, à cause de l’effet Flicker.