Saviez-vous que 1 seconde de page blanche en plus au moment d’afficher un contenu sur un site = 1000 points de Speed Index en moins ? Lors d’un test A/B, une page web met inévitablement plus de temps à s’afficher pour les internautes. Nous avons discuté avec Jean-Pierre Vincent, expert web performance indépendant, qui nous rappelle que si cette démarche est souvent indispensable et bénéfique en marketing (pour identifier le meilleur CTA et les bons contenus, trouver l’emplacement ou la couleur idéaux pour un bouton…), il faut savoir la mettre en place avec précaution parce qu’elle a un impact sur la vitesse de chargement.
Fasterize : Quels impacts sur la performance web 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 points sur les taux de conversion existe (1 seconde en plus = 12 % de taux de conversion en moins – ndlr). C’est un mal pour un bien, néanmoins si un test A/B est une démarche souvent indispensable pour optimiser un site web et améliorer ses résultats business, il faut vraiment prendre la mesure de l’impact de cette action.
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 une page web est-elle ralentie lors d’un test A/B ?
J-P. V. : Pour éviter l’effet de flickering, les visiteurs voient une page blanche en attendant que le contenu de la page défini 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 à la version 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, un test A/B est devenu très simple à exécuter. L’avantage est de faire gagner du temps aux équipes techniques qui n’ont plus à intervenir dans le déploiement du test, et aux équipes métiers (marketing, e-commerce, contenus, UX, UI…) qui sont ainsi autonomes pour mettre en place les tests dont ils ont besoin sans solliciter l’IT. Mais malheureusement, cela se fait souvent au détriment de la vitesse d’affichage, et donc de l’expérience utilisateur.
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 de web performance. 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 le test A/B soit réalisé côté serveur, comme c’était le cas il y a une dizaine d’années. Le serveur voyait alors les visiteurs arriver avec leurs cookies, et décidait de proposer la version A ou B du contenu. 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 définir le temps maximum pendant lequel les utilisateurs peuvent attendre avant d’afficher une version A ou B du contenu d’une page.
Fz : Avez-vous déjà rencontré des cas de ralentissement extrêmes sur des pages web ?
J-P. V : Oui, chez Lesfurets.com, l’un de mes clients, le temps nécessaire pour afficher le contenu des pages dans le cadre d’un test A/B est passé à 3 secondes au lieu de 1 ! D’après ce que j’ai pu analyser, ces résultats s’expliquaient 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. Les utilisateurs devaient alors charger le contenu de la page 2 fois, en version “normale” (jamais affichée) et en version “test”, et les performances en termes de vitesse d’affichage se voyaient fortement dégradées. Le trafic SEO avait aussi chuté de 50 %.
Fz : Quelles solutions de contournement ont été déployées pour optimiser la vitesse de chargement avec ce test A/B ?
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 frontend. 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 lazyloading 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 performance web reste la solution la plus pertinente et économique pour optimiser la vitesse de chargement, même dans le cadre d’un test A/B – à condition qu’il soit mis en place côté client.
A/B testing et vitesse de chargement : retour d’expert et d’expérience
Chez Fasterize, nos clients sont évidemment amenés à faire appel à des solutions d’A/B test pour proposer différentes versions d’un contenu, d’un CTA, d’un bouton… et analyser l’impact sur les performances. 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. Par définition, ce n’est pas leur rôle.
A force de vouloir gagner du temps en contournant l’IT, ce sont aussi leurs compétences, leurs connaissances et leur expérience qui sont contournées, ainsi que les process qui garantissent le bon déroulement d’un projet web pour atteindre les résultats attendus (tests, validation, monitoring…). Cela qui mène à des développements mal maîtrisés, et des utilisateurs finalement frustrés car leur expérience n’est pas à la hauteur.