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 (code Google Analytics par exemple). Il est codé au format html (de moins en moins), javascript et/ou iframe (de plus en plus).

Voici à quoi ressemble un tag :

Vous êtes e-commerçant et aimeriez améliorer votre analytics ? Découvrez comment installer facilement le commerce électronique amélioré sur Google Analytics avec Google Tag Manager.

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. Du coup, on aurait tendance à dire : choisissez plutôt la version asynchrone pour vos tags, sauf pour les tags de testing. Dans ce cas, il est plus prudent d’opter pour un tag synchrone.

Google Tag Manager permet de gérer plus facilement les tags installés sur votre site web. Découvrez comment mettre en place Google Tag Manager sur son site web.

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. C’est pour éviter cet effet qu’une solution comme Optimizely a choisi de ne proposer que des tags synchrones. 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.

Découvrez 8 segments personnalisés Google Analytics pour rendre vos données plus intéressantes.

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.
• Ne pas insérer la librairie jQuery dans le tag si vous l’utilisez déjà ailleurs sur le site.
• 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.
• 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

Kameleoon a récemment annoncé (mi-janvier 2017) avoir trouvé la solution magique permettant de supprimer définitivement l’effet Flicker. La solution d’A/B Testing garantit un anti-flickering « en toutes circonstances », quelque soit le site. Comment ça marche ?

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é. Cette nouvelle technique, qui repose sur le standard des DOM Mutation Observers, permet d’afficher immédiatement les modifications apportées aux éléments, dès leur apparition sur la page. Ce qui supprime l’effet « page blanche ». Cette solution « miracle » serait compatible avec 92% des navigateurs selon Kameleoon. Sur les autres navigateurs, la technologie anti-flicker n’est pas activée. Ce qui, au passage, maintient l’importance des bonnes pratiques évoquées plus haut.

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 que vous puissiez vous faire votre propre opinion, voici la critique d’ABTasty et la réponse apportée à cette critique par Kameleoon (l’article explique, en gros, qu’ABTasty n’a rien compris à la solution anti-flicker et revient dans le détail sur son fonctionnement).

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.