Les premiers jours des soldes de Janvier ou des périodes comme BlackFriday, peuvent représenter jusqu’à 20% du chiffre d’affaire de l’année pour certains e-commerçants. Alors pour que tout se passe bien et sans plantage, voici les 5 conseils de Quanta pour maximiser vos ventes le jour J.
Une mise en ligne “à blanc” avant 8h00
L’état français imposant une ouverture des soldes au minimum à 8h00 du matin, le gros problème de chaque e-commerçant est donc que les utilisateurs sont souvent en pôle position dès 7h30 ! De ce fait, un changement majeur de l’ensemble des pages du site (typiquement la mise à jour de l’ensemble des prix, ou encore l’affichage de la mention “Soldes”), alors que le site est rempli de visiteurs, conduit généralement à une très forte charge sur les serveurs. En effet, quand l’ensemble des visiteurs se retrouve à accéder à des pages qui n’ont pas encore été mises en cache (puisque “nouvelles”), et le CMS va devoir effectuer pour chaque clic un lourd travail de calcul machine entrainant un fort risque de surcharge des serveurs.
Alors si vous souhaitez faire respirer votre plateforme d’hébergement à 8h00, nous vous conseillons de fermer le site aux visiteurs dès minuit la veille. Vous perdrez très peu de ventes cette nuit là, car qui achète dans la nuit la veille des soldes?? 0_0 Et c’est pour la bonne cause, en plus! 😉 Tips supplémentaire, pensez à mettre vos designers à contribution pour faire une belle page de maintenance qui indique l’ouverture des soldes à 8h00 (avec un peu de teasing, et pourquoi pas, un compte à rebours !). En parallèle de cette « fermeture du site », mettez en place “silencieusement” la version soldée du site accessible uniquement depuis vos adresses IP et celle de votre agence Web.
De cette manière, entre minuit et 8h du matin vous serez en mesure de vérifier le fonctionnement du tunnel de vente, dans sa version remisée, en production.
J’insiste sur le “en production” car même si vous avez validé avec votre agence la version « Remisée » de votre site en environnement de pré-production, il reste rassurant de valider le fonctionnement de l’ensemble du tunnel de vente dans l’environnement final, jusqu’au paiement, avant l’ouverture.
Résultat : à 8h, vous enlevez votre (belle) page de maintenance et le site est prêt à accueillir vos acheteurs dans de bonne conditions de web performance. Votre équipe aura gagné quelques cernes pendant la nuit, mais ils vous remercieront plus tard lorsque toute la période de soldes sera vécu enfin sans stress.
Préchauffer les caches de façon automatique
Au lieu d’accéder vous-même aux principales pages, à la main, sur la version “soldes” de votre site avant l’ouverture, il est plus efficace de demander à un robot d’aller visiter chacune des pages du site de façon exhaustive.
L’objectif ? Que la plupart des pages du site soient pré-générée avant l’ouverture des soldes, de sorte qu’elles figurent déjà dans les cache (Varnish, Full Page Cache ou encore le cache applicatif de votre CMS) avant l’arrivée de vos acheteurs.
Il suffit d’accéder à une page, une seule fois après la mise en ligne du site en mode Soldes pour que celle-ci soit mise dans l’ensemble des caches. L’opération consiste donc à utiliser un outil automatique pour accéder progressivement à l’ensemble des pages de votre site E-commerce.
Quelques outils pour mener ces actions :
- mage-perftest
- HTTrack
- Nutch
- Sphider
- Crawler4j
Attention ce sont des outils plutôt geeks, et il est nécessaire de lancer cette opération à un rythme raisonnable pour ne pas faire tomber votre site sous un afflux trop rapide de requêtes. Alors notre conseil : convenez de cette action avec votre agence web !
Empêcher les actions Back-office lors du pic !
De simple clics dans le back-office de votre CMS peuvent se révéler dangereux (car consommateur en ressources serveurs) lorsque son utilisation est faite en parallèle d’un fort taux de commande en cours.
Notre conseil est, à minima, de prévenir l’ensemble de l’équipe e-commerce que le premier jour des soldes le back-office de votre CMS ne doit pas servir à rentrer de nouveaux produits, ou modifier des descriptions.
Ce jour là on ne fait plus de retouches ! Et si vous voulez vraiment assurer vos arrières, vous pouvez aussi désactiver temporairement l’accès de vos utilisateurs au back-office. Au moins comme ça, il n’y aura pas de doute ! 😉
A quelle point cela peut-être problématique ? Et bien sachez qu’on l’a constaté et mesuré régulièrement chez Quanta et un simple clic back-office peut invalider les caches d’un grand nombre de pages, ce qui amène à une forte perturbation sur le site (Cf point 2, pour ceux qui suivent :P).
Plus d’info sur ce sujet dans cet article.
Ajoutez temporairement des serveurs frontaux
Attention, minute un peu tech ! Avec la plupart des CMS, mais plus particulièrement sur Magento et Prestashop, on remarque chez Quanta que les pics de visites s’illustrent par des montée en charge d’occupation processeur sur les serveurs frontaux (ceux qui font tourner l’application e-commerce), bien plus que sur le serveur de base de donnée. Bien qu’il soit généralement tout seul, le serveur de base de donnée est généralement moins sollicité que le reste de l’architecture.
La vie est plutôt bien faite car il est complexe de faire travailler plusieurs serveurs de base de donnée en parallèle pour tenir une charge plus importante, alors qu’il est très simple d’ajouter des serveurs frontaux pour répartir les requêtes sur une suite de serveurs (communément appelé un “pool de serveurs”).
En d’autres termes, plutôt que de multiplier les serveurs de base de donnée, pour tenir la charge le jour des soldes, multiplier les serveurs frontaux.
Cependant, il ne faut pas faire ça à l’arrache. Si vous aviez jusqu’ici un seul serveur frontal, il est important de vérifier que l’architecture de votre site est prête pour accueillir d’autres frontaux. Les implications potentielles sont à discuter avec votre agence, mais la plus courante est le cas des sessions (cookies) utilisateurs. La question à se poser est : une session utilisateur dans votre configuration est-elle stockée sous forme d’un fichier dans un répertoire du serveur frontal, ou bien est-elle stockée dans un système partageable comme la base de donnée, ou encore un serveur de cache type Redis ? La session doit être partagée et accessible par chacun des serveurs frontaux pour que la navigation (Login, Ajout au Panier) de l’utilisateur ne soit pas perturbée.
Imaginez un peu s’il met un article en panier, puis est redirigé vers un serveur qui n’arrive plus à trouver sa session et son produit. Il y a de grandes chances pour qu’il claque la porte de votre site.
Il reste qu’au delà de ce point de configuration à vérifier, ajouter des serveurs frontaux reste la façon la plus simple d’accroître la capacité d’accueil de votre site pour les premiers jours des soldes.
Dernier conseil, ajoutez vos nouveaux serveurs au minimum 2 ou 3 jours avant, histoire de vous assurer :
- du bon fonctionnement du tunnel de vente depuis chacun des serveurs (Oui, j’insiste là dessus lourdement, je sais.)
- d’avoir installé vos sondes de monitoring sur ces nouveaux serveurs afin de garder une vue complète de la santé de votre architecture pour le jour J.
Effectuer des tests de montée en charge
Afin d’être sûr que vous pourrez accueillir davantage de visiteurs que d’habitude sur votre site, je vous conseille de simuler un pic de trafic supérieur à celui que vous attendez le jour des soldes.
Oui, et encore oui ! Prenez de la marge ! Il serait quand même extrêmement frustrant que vos campagnes d’emailing aient trop bien fonctionné, et que vous vous retrouviez avec un site planté, flinguant ainsi votre chiffre d’affaire. Tiens ! Ca me rappelle d’ailleurs l’histoire d’un directeur e-commerce le premier jour des soldes… 😛
Pour effectuer des tests de charge, de nombreuses solutions existent, regroupées dans 2 catégories :
- Les tests maisons effectués par vos équipes, avec des outils généralement gratuits et consommateur de temps comme siege, wget, curl, ab, etc.
- Les tests “pro” effectués par des tiers indépendants comme CloudNetCare, Neotys ou Quanta.
Quelle que soit la solution choisie, lors de ces tests il est important de :
- simuler ce que ferait un acheteur sur votre site, en calquant le scénario de votre test de charge sur le comportement moyen enregistré en réel par vos visiteurs dans votre historique Google Analytics.
- effectuer vos calculs de sorte à exprimer facilement quelle a été la limite atteinte. Exemple non parlant de résultat donné : “Nous tenons 13 422 requêtes HTTP par minutes avec 60% de CPU… Ok ? Mais euh… C’est bien ou pas bien ??”. Exemple parlant de résultat donné : “Mon site en version soldes arrive à tenir, sans perturbation, 5 fois le trafic enregistré pendant nos précédentes soldes, et ce avec des visiteurs virtuels effectuant un parcours complet d’achat.” Ok là je suis sereint pour le jour J.
Si vous voulez en savoir plus sur les éléments importants à prendre en compte avant de vous lancer; nous avions déjà écrit ici un guide complet sur la mise en place des tests de charge.
Sur ce, bonnes opérations commerciales à vous tous !!