L’effet flicker consiste, lors d’un test A/B, à voir brièvement la page originale avant la page alternative, le temps pour le navigateur d’appliquer vos modifications. Il n’existe aucune méthode miracle pour éradiquer ce problème, certaines annoncées comme révolutionnaires ayant leurs limites. En revanche, il existe de nombreuses bonnes pratiques à suivre pour accélérer la prise en compte de vos modifications et rendre cet effet imperceptible.
L’effet flicker, c’est quoi ?
Si vous n’avez jamais entendu parler de l’effet flicker, vous en avez sans doute déjà fait l’expérience sans le savoir : la page testée se charge puis, au bout de quelques millisecondes, votre modification s’affiche. Résultat : vous voyez en un battement de cils, 2 versions de votre page : l’originale et la modifiée. Il en résulte un effet déplorable pour l’expérience utilisateur, sans parler de la pertinence de votre test puisque l’utilisateur peut prendre conscience qu’il est soumis à un test.
Cet effet est lié au principe de fonctionnement côté navigateur de nombreuses solutions d’A/B testing, lesquelles appliquent une surcouche JavaScript lors du chargement de la page pour en modifier les éléments. Dans la plupart des cas, vous ne constatez aucun effet mais si votre site est déjà long à charger ou qu’il fait appel à des ressources externes gourmandes, vos modifications prennent du temps à être appliquées. L’effet flicker, jusque-là passé inaperçu, est alors visible.
Existe-t-il une méthode miracle pour supprimer l’effet flicker ?
Certains fournisseurs annoncent utiliser des innovations techniques permettant d’éradiquer l’effet flicker. Attention, il ne s’agit ni plus ni moins que d’une technique déjà connue, laquelle présente des limites et qui est déjà implémentable par n’importe quelle solution. En analysant les documentations des principaux acteurs du marché, on constate également qu’ils ne poussent cette méthode qu’en dernier recours, si toutes les alternatives n’ont rien donné, car l’effet flicker varie pour chaque site et dépend beaucoup de leur performance initiale.
Alors en quoi consiste cette méthode ? Il s’agit de masquer temporairement l’affichage du contenu en ayant recours à une propriété CSS de type visibility: hidden ou display: none sur l’élément body. Cette propriété a pour effet de masquer le contenu de la page aussi rapidement que possible (pour peu que le tag de la solution soit placé dans la balise <head> de la page) puis à réactiver sa visibilité une fois que les modifications ont eu le temps de s’appliquer. Il n’y a donc plus d’effet flicker « avant/après ». Celui-ci est en revanche remplacé par un effet “page blanche/après”.
Le risque avec une telle méthode est que si la page rencontre le moindre problème de chargement ou que la méthode est mal implémentée, l’internaute peut se retrouver avec une page blanche pendant plusieurs secondes, voire bloqué sans aucun moyen d’action. Un autre inconvénient réside dans l’impression de lenteur que la méthode introduit. Il faut donc s’assurer que le blocage du rendu ne dure pas trop longtemps (quelques millisecondes) mais suffisamment pour laisser le temps aux modifications de s’appliquer. Et bien sûr, pour maintenir la validité de l’expérimentation, vous devez appliquer ce retardement d’affichage à la version de contrôle pour ne pas biaiser les comportements liés à une impression de vitesse différente.
Vous l’aurez compris, si vos modifications mettent du temps à s’appliquer, vous ne voudrez pas afficher une page blanche trop longtemps et devrez, au final, toujours vous en remettre aux bonnes pratiques présentées ci-dessous qui visent, elles, à accélérer l’application des modifications.
C’est pourquoi, chez AB Tasty, nous ne recommandons pas cette méthode pour la majorité de nos utilisateurs et ne la proposons pas par défaut. Elle reste toutefois facilement implémentable en utilisant un peu de code JavaScript.
Comment limiter l’effet flicker ?
Si vous ne souhaitez pas recourir à la méthode présentée ci-dessus, quelles solutions s’offrent à vous ? Voici les meilleures pratiques à suivre pour réduire cet effet et souvent y mettre fin complètement :
- Optimiser le temps de chargement de votre site en utilisant toutes les techniques disponibles : mise en cache des pages, compression, optimisation des images, utilisation d’un CDN, parallélisation des requêtes avec le protocole HTTP 2 …
- Placer le tag de la solution d’A/B testing le plus haut possible dans le code source, à l’intérieur de la balise <head> et avant l’appel à des ressources externes gourmandes (ex : web font, librairies JavaScript diverses et variées…).
- Utiliser la version synchrone du script AB Tasty, la version asynchrone augmentant les chances de flicker
- Ne pas utiliser un gestionnaire de tags pour appeler le tag de votre solution (ex : Google Tag Manager). Certes, c’est moins pratique mais vous pouvez facilement contrôler la priorité de déclenchement de votre tag.
- Ne pas insérer la librairie jQuery dans le tag de votre fournisseur si votre site y fait déjà appel. La majorité des solutions d’A/B testing côté navigateur repose sur jQuery. AB Tasty vous permet néanmoins de ne pas charger ce célèbre framework JavaScript si vous l’utilisez déjà par ailleurs. Ce sera autant de Ko à ne pas charger.
- Réduire la taille du script chargé par votre solution en supprimant les tests non actifs. Certaines solutions incluent dans leur script l’intégralité de vos tests, qu’ils soient en pause ou en draft. Chez AB Tasty, par défaut, seuls les tests actifs sont inclus, néanmoins, si vous avez de nombreuses personnalisations en cours, il peut être opportun de les passer en production de manière définitive et de les désactiver côté AB Tasty.
- Prêter attention à la nature des modifications apportées. Insérer plusieurs centaines de lignes de codes pour construire votre modification causera inévitablement plus d’effet flicker qu’une simple modification de style CSS ou de wording.
- Se reposer au maximum sur les feuilles de style. Il est souvent possible d’arriver à un même résultat visuel en utilisant des feuilles de styles. Par exemple, vous pouvez vous contenter d’une instruction JavaScript qui ajoute une classe CSS à un élément, cette dernière se chargeant de modifier son aspect, plutôt que plusieurs lignes de script qui manipulent le style de cet élément.
- Optimiser le code de vos modifications. En tâtonnant lors de la mise en place de vos modifications via l’éditeur WYSIWYG, vous pouvez ajouter sans le savoir plusieurs instructions JavaScript qui ne sont pas nécessaires. Analysez rapidement le code généré dans l’onglet “Edit Code” et optimisez-le en ré agençant ou en supprimant les parties inutiles.
- S’assurer que la solution utilisée fait appel à un (ou plusieurs) CDN pour charger le plus rapidement possible le script contenant vos modifications, quel que soit l’endroit où se trouve votre internaute.
- Pour les utilisateurs avancés : mettre en cache les sélecteurs jQuery en tant qu’objets pour ne pas avoir à retraverser le DOM à plusieurs reprises et/ou coder les modifications en JavaScript plutôt qu’en jQuery, notamment pour cibler les éléments par class ou id.
- Utiliser des tests par redirection dans la mesure du possible et si cela reste pertinent après avoir mis en relation la nature de la modification et le temps de mis en œuvre d’un tel test.
Si après avoir mis en place ces optimisations, vous constatez encore un effet flicker, vous pouvez vous résoudre à utiliser la technique consistant à masquer le contenu de la page tant que tous les éléments ne sont pas chargés. Si vous n’êtes pas sûr de comment vous y prendre, adressez-vous à notre support.
