
A/B testing : Comment notre nouvelle technologie éradique l'effet 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.
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 !
- 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.