Nous avons annoncé il y a quelques semaines une innovation qui est venue bousculer le petit monde de l’A/B testing en nous attaquant à un problème aux lourdes conséquences : l’effet flicker. Nous sommes ravis de l’engouement suscité par cette innovation. Nos clients nous ont fait des retours très positifs sur cette nouvelle technologie qui a été automatiquement déployée sur leur site et dont ils ont pu immédiatement mesurer les bénéfices. D'autres acteurs du marché ont pris le temps de livrer leur analyse et expertise sur le sujet. Avec visiblement une grosse incompréhension. Parce que la volonté de Kameleoon est de toujours être force de proposition, nous apportons dans cet article quelques précisions sur le fonctionnement de notre technologie 100% anti-flicker.

Une technologie 100% anti-flicker : Info ou Intox ?

Pour rappel, l’effet flicker est visible lorsqu’un visiteur se rend sur une page ciblée par un test A/B et aperçoit la version de référence avant la variante.

 

Kameleoon persiste et signe : sa nouvelle technologie 100% anti-flicker est une véritable innovation durable pour éviter tout problème d’effet flicker sur votre site ! Tous les experts du sujet s’accordent sur un point : l’effet flicker est une réalité induite par les solutions d’A/B testing. Plutôt que de nous cantonner aux bonnes pratiques pour limiter au maximum l’apparition de l’effet flicker, nous avons décidé de nous attaquer à la source du problème et de le résoudre une fois pour toutes. Certains vous diront qu’il n’existe pas de solution miracle, nous sommes convaincus qu’il est essentiel de ne pas se satisfaire du statu quo et apporter des solutions innovantes à des problématiques connues de tous. “Si j’avais demandé aux gens ce qu’ils voulaient, ils m’auraient dit des chevaux plus rapides” Henri Ford, industriel fondateur de Ford Motor Company

D’où vient l’effet flicker

En réalité, l’effet flicker peut provenir de deux causes distinctes. Une précision essentielle pour comprendre le fonctionnement de notre nouvelle technologie 100% anti-flicker.

A. Côté installation utilisateur : ce que vous devriez faire

La première cause qui peut créer un effet flicker tient au chargement du script lui-même et le moment où celui-ci est disponible, actif et prêt à exécuter les modifications souhaitées sur les pages de votre site. Les bonnes pratiques avancées par les acteurs de l'A/B testing agissent principalement sur ce paramètre (attention, toutes ne sont pas pertinentes, voir plus d'explications à la fin de cet article). À ce niveau-là, rien de nouveau sous le soleil : plus tôt le script de votre solution d’A/B testing est disponible, mieux c’est. Les facteurs influents sur ce premier périmètre sont les suivants (les deux premiers étant les plus importants et tenant essentiellement à la méthode d’intégration du script au code de votre site) :

• script écrit en dur dans le code HTML vs une intégration via un gestionnaire de tag,
• l’emplacement du script dans la page et par rapport aux autres ressources (haut de page, bas de page…),
• le poids du script et la performance des serveurs l’hébergeant (plus le script est léger et plus les serveurs sont puissants, plus rapidement il sera téléchargé par le navigateur du visiteur),
• la capacité de mise en cache navigateur.

Script synchrone ou asynchrone : comment s’y retrouver Vous entendez régulièrement parler de script synchrone ou asynchrone et des implications qu’ils ont sur le chargement des pages de votre site et sur l’effet flicker. En synchrone, le navigateur bloque l’exécution et l’affichage de tout le reste de la page tant que le script n’est pas téléchargé et disponible. Ce comportement vient du fait que le navigateur considère que les instructions du script sont prioritaires : il veut les exécuter à tout prix avant toute autre action et par conséquent, ne peut rien faire d’autre tant que le script n’est pas téléchargé. C’est vrai, et cela a une conséquence simple : tant que le script n’est pas téléchargé, vous aurez un effet “page blanche”. Et pour peu que les serveurs hébergeant le script ne répondent pas, cet effet page blanche sera même permanent, rendant le site inaccessible. Personne ne voudrait voir ça sur son site et il s’agit pourtant d’une bonne pratique recommandée par certains acteurs : malheureusement, quelques-uns de leurs clients en ont été victimes. Oups… En asynchrone, le script est téléchargé parallèlement aux autres ressources. Pas de blocage possible. En revanche, la garantie de disponibilité du script avant les autres éléments de votre page est perdue. Ceci favorise potentiellement l’effet flicker puisque les éléments à modifier peuvent apparaître avant que le script ne soit téléchargé. La méthode que nous avons développée il y a 4 ans appelée « intégration asynchrone bloquante » essaie de réaliser le meilleur compromis possible entre synchrone et asynchrone. Le script est demandé de manière asynchrone mais la page est gardée blanche tant que celui-ci n’est pas disponible ou qu’un certain temps (par exemple une seconde) n’est pas écoulé. Cela revient donc de fait à une intégration synchrone en termes de temps pendant lequel la page reste blanche, mais avec la sécurité additionnelle que dans l’éventualité où le serveur (CDN) de Kameleoon ne répondrait pas, la page s’affichera quand même au bout d’une seconde. Résultat : une performance similaire à l’intégration synchrone du point de vue de la gestion de l’effet flicker, mais des garanties de sûreté supérieures. Nous avons régulièrement donné à nos clients nombre de ces bonnes pratiques  et nous continuons d’innover également sur ces aspects de manière permanente.

B. Côté solution A/B testing : les performances indispensables

La seconde cause de l'effet flicker tient à la manière dont la solution d’A/B testing interagit avec la page web pour effectuer les modifications. Contrairement à ce que l’on pourrait penser, même une fois le script chargé et disponible, les problèmes ne sont pas finis pour autant ! L’effet flicker peut encore avoir lieu. Ici, les facteurs importants à considérer sont la qualité du code du logiciel et les technologies qu’il utilise : la solution d’AB testing doit utiliser le moins possible de CPU et de RAM, tout en interagissant le plus rapidement possible avec les éléments nécessaires sur la page. Notre nouvelle technologie 100% anti-flicker se concentre uniquement sur ce second point, et non, comme un acteur concurrent a cru le comprendre, sur la problématique d’installation du script (en l'occurence la méthode asynchrone bloquante cachant la page le temps du chargement du script : cela fait déjà des années que nous proposons cela).  

Une nouvelle technologie 100% anti-flicker disponible sans installation supplémentaire et compatible avec 92% des navigateurs.

Nous sommes allés beaucoup plus loin. Notre innovation technologique intervient sur la façon dont Kameleoon interagit avec les éléments de votre page une fois le script disponible. Les difficultés causées par les cycles de rafraichissement du navigateur sont désormais prises en compte : les modifications sont immédiatement apportées aux éléments dès que ceux-ci apparaissent sur la page, sans avoir besoin de passer par une “page blanche” et sans risquer de "faire planter" votre site. Pour les plus techniques d’entre vous : notre technologie se base sur le standard des DOM Mutation Observers, comme l’ont d’ailleurs deviné correctement plusieurs personnes nous ayant fait part de commentaires ou de retours suite à l’annonce de notre innovation (well done guys !). Il s’agit d’un standard implémenté dans tous les navigateurs (desktop comme mobile) supportés par Kameleoon, à l’exception de IE 9 et 10 (qui ont d’autres problèmes par ailleurs, mais ce n’est pas le sujet de cet article).

La nouvelle technologie anti-flicker est donc compatible avec 92% des navigateurs actuels.

De plus, bonne nouvelle, aucune adaptation de code n’est nécessaire pour en bénéficier, tout est automatique. Sur les navigateurs non compatibles, la technologie anti-flickering n’est tout simplement pas activée, mais vos variations continuent à fonctionner sans aucune perturbation. Simplement, sur ces navigateurs, vous risquerez un effet flicker, mais pas plus qu’avec n’importe quelle autre solution d’A/B testing. En résumé : la nouvelle technologie 100% anti-flicker de Kameleoon est une amélioration certaine de vos performances sans aucune dégradation possible.

Et les bonnes pratiques dans tout ça ?

Les performances de l’innovation technologique que nous avons développée permettent d’éradiquer l’effet flicker. Reste qu’il convient de respecter également de bonnes pratiques. Étant largement connues de tous, vous en retrouverez également une partie chez nos confrères, corrigées par nos soins pour certaines. Pour limiter au maximum l’apparition de l’effet flicker, il convient de :

• Installer le script de votre solution d’A/B testing le plus haut possible dans le header de votre site.
• Installer le script en asynchrone bloquant comme expliqué plus haut. Si votre solution ne vous permet pas cette option, nous vous conseillons d‘éviter d’installer votre script en synchrone comme recommandé par nos confrères. Cela réduit l’effet flicker par rapport à une intégration asynchrone, mais pas par rapport à une intégration asynchrone bloquante, et induit un risque de faire planter tout votre site, qui même s’il est faible est bien réel !
• Ne pas utiliser de gestionnaire de tags pour garder le contrôle sur l’ordre de chargement des scripts.
• Réduire la taille du script. Kameleoon a développé il y a plusieurs années déjà un pre-processing permettant d’accélérer encore la vitesse du script en ne chargeant que le strict nécessaire. Par exemple, si votre test A/B ne nécessite pas de ciblage avancé, pas besoin de charger tous les critères de ciblage !
• Optimiser le temps de chargement de votre site et de tous ses éléments.
• Passer par un CDN pour accélérer la vitesse de chargement du script.
• Ne surtout pas utiliser des tests par redirection. Une redirection effectuée par une solution d’A/B testing ne peut être malheureusement effectuée qu’en JavaScript. Contrairement à un « vrai » redirect serveur (statut HTTP 302 par exemple), qui est très léger, cela correspond à un chargement extrêmement lourd. En effet, pour réaliser un redirect JavaScript par la solution d’A/B testing, la première page et toutes ses ressources (images, scripts, etc) doivent se charger une première fois, puis, une fois seulement le script chargé, la seconde page commencera à se charger. On se retrouve donc, non pas avec un effet flicker, mais avec un temps de chargement initial de la page qui augmente fortement. De fait, il faut absolument réserver les tests par redirect aux situations où on ne peut pas faire autrement, car ceux-ci ont un réel impact en termes de performance. Un bon exemple est la réalisation d’un test sur une refonte de site totale, quand le nouveau site est hébergé sur un autre serveur : une redirection est ici presque obligatoire. Dans les autres cas, évitez les redirections JavaScript !

Et si vous utilisez la nouvelle technologie 100% anti-flicker de Kameleoon, vous n’aurez plus à vous soucier de :

• Se reposer au maximum sur les feuilles de style : avec Kameleoon, cela ne fait plus vraiment de différence, vous êtes libres de choisir l’implémentation qui vous convient le mieux sans vous soucier de la performance qui est prise en compte automatiquement.
• Ne pas utiliser jQuery. Kameleoon ne fait appel à aucune librairie externe, permettant de réduire encore plus la taille du script. Les nouveaux sites (et vous êtes nombreux à entreprendre des refontes de site en ce moment) se basent plutôt sur de nouveaux frameworks comme Angular ou React, ce qui rend jQuery une charge inutile de plus en plus souvent. D’autant qu’attention: même si votre site a déjà jQuery, le retirer de la solution d’A/B testing n’est pas suffisant. Là encore, si le script jQuery charge tardivement, vous retrouverez un effet flicker. Bref, beaucoup de soucis inutiles.
• Optimiser le code de vos modifications pour ne pas insérer d’instructions JavaScript inutiles. L’éditeur visuel de Kameleoon ne génère pas d’instructions JavaScript et se repose sur un moteur appliquant les modifications faites par l’utilisateur, ce qui évite totalement ce problème.

Certains mettent également en avant une autre bonne pratique à laquelle nous adhérions auparavant mais qui n’est plus nécessaire désormais: le « setInterval» pour modifier le plus rapidement possible les éléments ciblés par vos modifications. Nous touchons bien là le cœur du problème que nous avons solutionné. Il faut jouer avec les bonnes valeurs pour parvenir à trouver le paramètre idéal qui fera disparaître le flicker, sans compromettre le temps CPU utilisé par la solution d’A/B testing. C’est justement le défi auquel nous nous sommes attelés : notre solution élimine le travail « au doigt mouillé » associé à l’utilisation de setInterval, pour permettre aux développeurs des tests A/B de gagner du temps. SetInterval, qui est une solution de polling, n’est plus nécessaire : les modifications sont appliquées dès que l’élément souhaité est injecté dans le DOM de la page.

Conclusion

Comme le souligne très justement notre partenaire Altima, il faut suivre les bonnes pratiques données par l’éditeur, sans quoi une technologie aussi novatrice soit-elle ne pourra pas tenir ses promesses. Nous sommes animés par une volonté d’innovation permanente au service de nos clients. Nous leur avons permis de franchir un cap en passant d’une situation où l’effet flicker était très minime (mais malheureusement présent) à une situation où celui-ci est désormais totalement absent. Et cela change tout pour eux ?