AB testing

 

Saviez-vous que 1 seconde de page blanche en plus au moment d’afficher un contenu = 1000 points de Speed Index en moins ? Lors d’un test A/B, un site met inévitablement plus de temps à s’afficher pour les internautes. Nous avons discuté avec Jean-Pierre Vincent, expert webperf indépendant, qui nous rappelle que si cette démarche est souvent indispensable et bénéfique en marketing, elle est aussi à aborder avec précaution parce qu’elle a un impact sur les temps de chargement.

Fasterize : Quels impacts sur la webperf avez-vous observés lors de tests A/B ?

Jean-Pierre Vincent : Comme toute application tierce - ou Third Parties -, les tests A/B ne sont pas neutres pour le budget performance. D’après des tests que j’ai menés en ADSL via WebPageTest, j’ai constaté que tous les tests A/B augmentent les temps de chargement de minimum 1 seconde. Ainsi, lorsqu’on décide de se lancer, il faut vraiment avoir présent à l’esprit que le risque de perdre du trafic et des conversions existe (1 seconde en plus = 12 % de conversions en moins - ndlr). C’est un mal pour un bien, néanmoins si un test A/B est une démarche souvent indispensable pour améliorer un site, il ne faut pas la prendre à la légère.

Il y a aussi un risque à dépendre du serveur d’un prestataire pour afficher sa page : même s’il vous garantit une haute disponibilité, ses temps d’indisponibilité potentiels s’ajoutent aux vôtres.

Fz : Pourquoi les temps de chargement sont-ils ralentis lors de tests A/B ?

J-P. V. : Pour éviter l’effet de flickering, l’internaute voit une page blanche en attendant que la page définie dans le cadre du test A/B s’exécute et s’affiche. Autrement dit, l’affichage est volontairement ralenti pour éviter de servir une première version de page qui disparaîtrait pour laisser place à celle qui doit s’afficher pour le test. En effet, ce clignotement pourrait donner l’impression qu’il y a un problème sur le site.

Grâce au développement de solutions SaaS clés en main ces 10 dernières années, les tests A/B sont devenus très simples à exécuter. L’avantage est de faire gagner du temps aux équipes techniques qui n’ont plus à intervenir dans le déploiement des tests, et aux équipes métiers (marketing, e-commerce, contenus, UX, UI...) qui sont ainsi autonomes pour mettre en production les tests dont ils ont besoin sans solliciter l’IT. Mais malheureusement, cela se fait souvent au détriment des temps d’affichage. 

Fz : Comment y remédier ?

J-P. V. : Dans la conception même d’un test A/B, il faudrait penser l’écriture du code en intégrant des bonnes pratiques webperf. Or ces éléments viennent aujourd’hui de l’extérieur via des solutions tierces, ils ne passent plus par les processus de vérification et de validation habituels par un service IT.
Idéalement, il faudrait que les test A/B soient réalisés côté serveur, comme c’était le cas il y a une dizaine d’années. Le serveur voyait alors l’utilisateur.rice arriver avec ses cookies et décidait du cas A ou B à lui proposer. Mais comme je l’évoquais plus tôt, ce procédé imposait d’autres contraintes aux équipes marketing et IT.

Une autre option moins lourde pour éviter de dépendre du serveur du prestataire consiste à héberger son propre script via une solution de reverse-proxy, avec cache par exemple. Enfin, une bonne solution de test A/B doit fournir une option de “timeout”, pour limiter le temps maximum que certains utilisateur.rice.s subissent.

Fz : Avez-vous déjà rencontré des cas de ralentissement extrêmes ?

J-P. V : Oui, chez Lesfurets.com, l’un de mes clients, le temps nécessaire pour afficher les pages dans le cadre d’un test A/B est passé à 3 secondes au lieu de 1 ! Cela s’expliquait par le fait que le design des versions A et B était tellement différent qu’il ne s’agissait pas de modifier une page en live, mais de faire une redirection. L’utilisateur.rice devait alors charger la page 2 fois, en version “normale” (jamais affichée) et en version “test”, et la webperf en était fortement dégradée. Le trafic SEO avait aussi chuté de 50 %.

Fz : Quelles solutions de contournement ont été déployées ?

J-P. V. : Etant donnée la nature du test qui impliquait 2 UI radicalement différentes, le test a finalement été réalisé côté serveur à l’aide de développements maison plutôt qu’une solution Javascript clés en main. Cela a nécessité un budget important pour le développement, mais que mon client pouvait se permettre et qu’il souhaitait engager.

Dans ce contexte, il aurait été difficile d’automatiser les optimisations Front-End. Ainsi, en plus du budget lié au développement du test A/B, il a fallu envisager un budget webperf et y consacrer des ressources puisque les optimisations ont dû être réalisées “à la main”, notamment :

  • la compression des images (les UI étant différentes, il ne s’agit pas de les resizer pour du responsive design, mais de proposer des UI distinctes selon les tailles d’écran)
  • le font-display
  • le passage des polices en WOFF2
  • le lazy-loading et subsetting des fonts...

Fz : Dans ce cadre, comment gérer au mieux son budget ?

J-P. V. : Dans la mesure où le test A/B était effectué côté serveur et non côté client, les équipes IT ont fait le choix d’investir de façon conséquente dans la formation de ressources, de faire une veille continue et d’assurer un suivi et une passation des connaissances. C’est une option que l’entreprise pouvait se permettre, mais dans d’autres circonstances, un outil d’automatisation de la webperf reste une solution intéressante et économique pour améliorer ses temps de chargement, même dans le cadre d’un test A/B - à condition qu’il soit déployé côté client.

Retour d’expert et d’expérience

Chez Fasterize, nos clients sont évidemment amenés à faire appel à des solutions d’A/B Testing. Comme évoqué, ces solutions permettent aux équipes marketing et e-commerce d’être autonomes tout en soulageant les équipes IT.
Mais attention ! Nous observons aussi une tendance qui se révèle parfaitement contre-productive : l’utilisation de solutions d’A/B test... pour faire du développement Front.
A force de vouloir gagner du temps en contournant l’IT, ce sont aussi leurs compétences et leurs connaissances qui sont contournées, ainsi que les process qui garantissent le bon déroulement d’un projet (tests, validation, monitoring…), ce qui mène à des développements mal maîtrisés.

 

Vous souhaitez aller plus loin sur le sujet “webperf et stratégie digitale” ?

Je télécharge le livre blanc

 


Hello SMX Paris !