Comment VWO crée une expérience de visiteur sans friction lors de l'exécution d'expériences sur une application à page unique (SPA)

Une plongée profonde dans la façon dont le support natif de VWO pour les sites Web dynamiques vous facilite l'expérimentation tout en créant des expériences transparentes pour vos visiteurs.

De nombreux sites Web sont conçus comme des applications à page unique (SPA) car ils présentent peu d'avantages clés par rapport aux sites Web statiques traditionnels : les sites Web dynamiques sont rapides, compacts et réactifs. Ces sites Web vous permettent d'optimiser le contenu que votre utilisateur voit pour créer des expériences attrayantes et uniques. Si votre équipe de développement vous dit que votre site Web est construit à l'aide de React, Vue, AngularJS, Ember ou Backbone, vous travaillez probablement avec un SPA et cet article vous concerne.

Dans cet article, nous expliquons comment nous, chez VWO, rendons l'expérimentation sur des sites Web dynamiques efficace et facile avec un support intégré pour les tests SPA afin que vous vous concentriez uniquement sur les efforts d'optimisation de l'expérience de votre site Web et rien d'autre.

Mais d'abord, parlons du problème qui vous a amené ici en premier lieu.

Défis liés à l'exécution d'expériences sur des sites Web dynamiques

Vous êtes probablement ici parce que lorsque vous exécutez des expériences sur un SPA, les modifications que vous apportez à votre page de destination ne sont pas visibles pour les utilisateurs finaux. Par conséquent, vous ne pouvez pas tester et valider vos idées aussi rapidement que vous le souhaitez et cela vous laisse frustré.

Tout d'abord, comprenons que les SPA sont différents des sites Web traditionnels. La page Web entière se charge chaque fois que quelqu'un visite un site Web conventionnel. Dans SPA, cependant, seules certaines sections de la page sont mises à jour. En effet, dans les SPA, les ressources telles que HTML, CSS, Scripts, etc., qui définissent l'apparence de votre page Web, ne sont chargées qu'une seule fois.

En fonction de la façon dont l'utilisateur interagit avec les différentes parties de la page Web, ce que vous voyez sur une section spécifique de la page change dynamiquement en réponse à l'action de l'utilisateur. Supposons que si un utilisateur clique sur un bouton, une fenêtre contextuelle s'ouvre. Cette fenêtre contextuelle est la modification dynamique apportée par le framework en fonction de l'interaction de l'utilisateur sans affecter les performances. Quelques autres exemples où il y a un changement dynamique sur un SPA sont comme ci-dessous :

• Éléments d'une liste de résultats de recherche qui peuvent être développés pour afficher ses détails.
• Dans un formulaire, certains champs apparaissent sur la page uniquement lorsqu'un visiteur sélectionne une valeur prédéfinie dans une liste déroulante.
• Le site Web utilise certains composants comme un calendrier, un sélecteur de couleurs, etc. qui sont rechargés chaque fois que l'utilisateur a besoin de les utiliser.

Bien que cela soit bon pour l'expérience utilisateur, exécuter une campagne de test avec des modifications apportées à l'un de ces éléments dynamiques (comme les listes de résultats de recherche, les listes déroulantes, les widgets, les pop-ups, les bannières, etc.) sur vos pages Web devient difficile. En effet, les modifications apportées à un composant doivent être appliquées chaque fois que quelque chose change dynamiquement sur le site Web.

Pensez-y de cette façon - vous exécutez un test sur une page Web. Chaque fois que la page Web se charge (par un utilisateur visitant la page) ou que la page crée un élément dynamique comme décrit ci-dessus, le framework SPA affiche l'état d'origine (différent de la variation que vous souhaitez afficher dans le cadre de votre test).

Ce dont vous avez besoin, c'est d'une plate-forme d'expérimentation qui garantit que votre variante de test remplace la vue d'origine afin que les utilisateurs voient la variante que vous souhaitez qu'ils voient. Ainsi, lors de la configuration d'un test sur un SPA (par exemple, vous testez le contenu dans une boîte de dialogue), vous vous attendez à ce que le contrôle et la variation du test ressemblent à ceci :

Mais, en l'absence de support SPA, les modifications apportées à la variation reviendront au contrôle, ce qui rendra les deux identiques. Tout à fait comme ça :

Ceci n'est qu'une version simplifiée de ce qui se passe. Si vous souhaitez comprendre techniquement ce qui se passe derrière l'écran, continuez à lire, sinon vous pouvez passer à la section suivante de l'article.

Certains frameworks de sites Web tels que GatsbyJS, Next.js, ReactJS, etc. utilisent le rendu côté serveur et stockent un instantané de votre page Web d'origine telle qu'elle doit être chargée. Ainsi, lorsque vous modifiez un élément sur la page à des fins de test, le framework détecte le changement comme un "problème" et rétablit la page à son état d'origine tel qu'il apparaît dans l'instantané stocké. Ceci, à son tour, entrave votre test A/B.

Deuxièmement, les derniers frameworks comme React, Gatsby, Next.js, Vue.js, Angular, etc., utilisent le concept de rendu basé sur l'état. Par exemple, dans React, chaque fois qu'un changement est mis en œuvre dans l'un des états en raison de la variation du test A/B, l'interface du site Web se recharge automatiquement dans sa forme d'origine, de sorte que les utilisateurs ne voient jamais la variation. Cela crée une expérience sous-optimale pour les visiteurs du site Web.

Comment VWO facilite l'expérimentation sur les applications à page unique

Maintenant que nous avons discuté du problème, parlons de la solution. Le support SPA natif avancé de VWO dans son éditeur visuel, qui fait partie de VWO Testing, garantit que les modifications apportées lors d'une expérience sont appliquées dans les SPA pour garantir la fiabilité des campagnes et offrir une expérience fluide à vos visiteurs.

1. Tester les éléments dynamiques sur votre site Web

Bien que les éléments dynamiques aient été définis dans la section précédente, examinons-les de près avec un exemple spécifique. Considérez que vous avez un site Web de commerce électronique. En cliquant sur le bouton 'X' (Fermer) sur la 'page Panier', une alerte apparaît sous forme de pop-up. Maintenant, vous souhaitez tester les modifications de copie sur la zone d'action pour voir si la messagerie actionnable et l'appel à l'action pourraient empêcher les gens de fermer la page du panier. La boîte d'alerte n'est pas initialement présente sur le code du site Web mais est ajoutée par le framework SPA lorsque le visiteur clique sur le bouton 'X' (Fermer). Ici, le bouton qui ouvre la fenêtre contextuelle sur laquelle vous exécutez le test est appelé l'élément cible.

VWO s'assure que la modification que vous souhaitez tester est appliquée à la fenêtre contextuelle dès son chargement. Tout ce que vous avez à faire est d'activer un paramètre en un clic. Vous pouvez en savoir plus sur ce paramètre dans notre article de la base de connaissances.

Comment VWO s'assure-t-il que les changements sont appliqués correctement ?

Facile.

VWO surveille les éléments de la page (vidéos, images, tableaux, sections, etc.) pour les modifications qui leur sont apportées à tout moment. Par conséquent, lorsque l'élément cible (le bouton Fermer 'X' dans l'exemple ci-dessus) se charge, VWO le détecte et applique la modification que vous avez apportée à la Variation. Cela se produit même si la page Web n'est pas rechargée, mais que l'utilisateur interagit simplement avec une section du site Web.

Soyons un peu techniques et explorons-le davantage. Vous pouvez confortablement ignorer cela et passer au point suivant si les détails techniques ne vous conviennent pas.

Dans un site Web dynamique, en fonction du comportement de l'utilisateur, des éléments sont ajoutés, supprimés ou modifiés. Une arborescence DOM est comme un référentiel de tous les composants du site Web (boutons, bannières, fenêtres contextuelles, widgets, etc.) et conserve un instantané de l'état actuel du site Web.

La bibliothèque de VWO utilise Mutation Observer - une interface de navigateur qui permet à VWO d'observer les changements dans l'arborescence DOM d'un SPA. Cela permet de détecter tout nouvel élément ajouté, supprimé ou modifié sur la page. Dans un tel cas, VWO applique automatiquement les modifications sur les éléments. Ainsi, chaque fois que des éléments se chargent dynamiquement, les modifications sont appliquées avant d'être présentées au visiteur. Cela améliore la fiabilité des campagnes, garantissant que les changements dans les variantes sont appliqués complètement.

Comment VWO gère-t-il les changements gênés par le rendu du framework ?

VWO garde le bouton CTA caché jusqu'à ce que le rendu du cadre soit terminé. VWO vérifie à plusieurs reprises si le rendu est terminé. Une fois le rendu du framework terminé, la campagne VWO commence à s'exécuter.

Vous pouvez en savoir plus sur ces paramètres dans notre article de la base de connaissances.

2. Tester tout autre élément de page sur votre site Web

Lorsqu'une page se charge, les frameworks SPA modernes rétablissent les éléments modifiés à leur état d'origine à chaque chargement du site Web. Ainsi, si vous testez la page, toutes vos modifications seront rétablies à l'original. Pas seulement les éléments dynamiques, mais pour tous les éléments de la page, VWO garde une trace des modifications que vous avez apportées pour relever le défi des tests avec le framework SPA. Lors de l'application de ces modifications à votre page Web, VWO détecte toutes les modifications apportées à la page (insertion, suppression et modification des nœuds DOM) par le test et les réapplique pour garantir la régularité de l'expérience utilisateur.

Aucune action explicite n'est requise pour activer cette amélioration sur VWO. Il s'agit d'une fonctionnalité intégrée disponible pour toutes les campagnes VWO créées avec l'éditeur visuel, quel que soit le cadre sur lequel votre site Web est construit.

Examinons quelques exemples de cas d'utilisation de modifications que l'éditeur visuel VWO gère.

1. Supposons que vous avez supprimé un bouton CTA secondaire (dites « Ajouter à la liste de souhaits ») de votre site Web de commerce électronique pour tester si ce changement affecte le nombre de clics sur le CTA principal (dites « Ajouter au panier »). Il s'agit d'un cas d'utilisation de test où vous supprimez un élément sur le site Web. Même si vous avez supprimé le bouton, il persiste dans le DOM virtuel créé par des frameworks comme React et génère une erreur lors du chargement du site Web.

2. Imaginez maintenant que votre site Web de commerce électronique dispose d'un flux d'inscription qui affiche une zone de saisie de texte pour capturer les adresses e-mail des visiteurs en plus du bouton "Soumettre maintenant". Lorsque vous modifiez l'apparence de la zone de saisie de texte, les composants de style du site Web qui lui sont associés changent. L'éditeur visuel de VWO garantit que les derniers changements appliqués sont ce que les utilisateurs voient. Regardez comment vous pouvez apporter des modifications à un champ de formulaire dans un SPA et assurez-vous que les visiteurs échantillonnés pour la variation voient ces modifications au lieu de voir le contrôle.

Comment utiliser VWO pour votre application monopage ?

Pour utiliser VWO pour votre SPA, il vous suffit d'ajouter le VWO SmartCode dans la section principale de votre site Web et de profiter de la prise en charge par défaut des sites Web SPA.

Avec une intégration aussi simple que cela, vous pouvez commencer tout de suite. Inscrivez-vous pour un essai gratuit, explorez les capacités de VWO ou demandez une démonstration avec nos experts produit. Vous pouvez également en savoir plus sur nos dernières mises à jour passionnantes de produits.