Bots et recherche à facettes PrestaShop : CPU à 100 % et pannes

Samedi après-midi. Un e-mail de votre hébergeur vous prévient que votre compte est à 100 % de CPU depuis des heures. Vous ouvrez vos statistiques en espérant une avalanche de clients et vous trouvez l'inverse : quarante mille pages vues et zéro commande.

Ce n'est ni une attaque, ni un module cassé, ni votre boutique qui fait n'importe quoi. C'est que quelqu'un s'est mis à parcourir, un par un, tous les filtres de votre catalogue.

Ce qui se passe exactement

Votre boutique dispose d'une recherche à facettes : taille, couleur, marque, prix, disponibilité, et par-dessus l'ordre des résultats. C'est ce qui la rend agréable à utiliser.

Le problème, c'est que chaque combinaison de ces filtres est une adresse web différente. Taille M en bleu d'une marque triée par prix en est une. Taille M en bleu de cette marque triée par nouveauté en est une autre. Et ainsi de suite pour toutes les combinaisons possibles : dans une boutique moyenne, cela donne des centaines de milliers ; dans une grande, des millions.

Les robots des réseaux sociaux et des services d'intelligence artificielle —ceux de Facebook, ceux de TikTok, ceux d'une demi-douzaine d'entreprises dont vous n'avez jamais entendu parler— ont décidé qu'ils devaient toutes les voir. Et ils les demandent toutes, en même temps, sans pause.

Chacune de ces adresses n'est pas une page que vous avez en réserve : c'est une nouvelle recherche dans votre base de données.

Le module derrière tout ça : la Recherche à facettes de PrestaShop

Les filtres de votre boutique sont affichés par un module précis, Recherche à facettes (ps_facetedsearch), celui livré avec PrestaShop depuis la 1.7, qui a remplacé l'ancienne Navigation à facettes. Si vous avez des filtres dans vos catégories, il est actif.

Le repérer dans vos journaux est simple : chaque combinaison voyage dans le paramètre q de l'adresse, sous cette forme.

/12-tee-shirts?q=Taille-M/Couleur-Bleu/Marque-Adidas

Si votre journal d'accès affiche des milliers de lignes avec ?q=, toutes différentes et à la suite, vous savez ce qui dévore la machine.

Et voici pourquoi c'est si coûteux. Quand une de ces requêtes arrive, le module ne cherche pas seulement les produits correspondant au filtre : il recalcule aussi les compteurs de tous les autres filtres —ce « Bleu (12) », « Vert (5) » à côté de chaque case— et lance pour cela plusieurs requêtes de comptage sur ses tables d'index. Multipliez par un grand catalogue et par des milliers de requêtes à la minute.

Deux leviers qui se trouvent dans le module lui-même et que presque personne ne touche, dans Catalogue → Recherche à facettes :

• Retirer le nombre de produits à côté de chaque filtre. C'est la partie la plus coûteuse de chaque requête et, dans la plupart des boutiques, celle qui manque le moins.
• Revoir les modèles de filtres par catégorie. Chaque filtre laissé en place multiplie les combinaisons possibles. Huit filtres dans une catégorie, ce ne sont pas huit adresses : ce sont des milliers.

Aucun des deux ne règle le problème à lui seul, mais tous deux réduisent le coût de chaque coup avant même de toucher au reste.

Pourquoi cela fait si mal

Une recherche filtrée est l'une des opérations les plus coûteuses d'une boutique : il faut parcourir tout le catalogue, croiser les attributs, compter combien de produits restent sous chaque filtre et trier le résultat. Un client en fait trois ou quatre sur toute sa visite. Un robot en fait trois ou quatre par seconde.

Et voici la partie qui déroute tout le monde : le cache ne vous sauve pas. Le cache sert quand beaucoup de visiteurs demandent la même chose. Ici rien ne se répète : chaque combinaison est unique, donc ce sont toutes des « premières visites » et elles arrivent toutes jusqu'à la base de données.

Le résultat est toujours le même. Les requêtes s'empilent, le serveur n'a plus de place et la boutique cesse de répondre — au robot comme au client sur le point de payer. Si cela tombe en pleine campagne, vous avez payé de la publicité vers un site qui n'ouvrait pas.

Comment savoir si c'est votre cas

Quatre signaux, et deux qui se cumulent rendent la chose quasi certaine :

• Une consommation élevée sans ventes. Énormément de pages vues, aucun panier. Les visites et les commandes ne collent pas du tout.
• L'hébergeur vous avertit que vous consommez trop, ou suspend le compte un moment « pour protéger les autres clients ».
• Cela tombe à des heures étranges : la nuit, un dimanche, par à-coups sans logique commerciale.
• Dans le journal d'accès, des milliers d'adresses successives avec des paramètres de filtre, toutes différentes, demandées en quelques secondes.

Si le back-office rame pendant ce temps, vous avez la confirmation : ce n'est pas la partie publique, c'est la machine qui sature. Nous l'expliquions dans quand la lenteur vient de la boutique et quand du serveur.

Ce qu'on va vous proposer, et pourquoi cela ne suffit pas

Ce problème attire beaucoup de solutions populaires qui ne tiennent pas à l'usage :

1. « Bloquez-les dans le fichier robots.txt ». Ce fichier est une demande polie, pas une porte. Les robots qui le respectent ne sont pas votre problème ; ceux qui vous mettent à terre ne le lisent pas. Et si vous forcez la dose, celui qui obéit, c'est Google, et vous vous effacez tout seul des résultats.
2. « Bloquez Facebook et TikTok par leur nom ». Cela marche une semaine. Ils changent d'identité, arrivent depuis des milliers d'adresses différentes, et trois nouveaux apparaissent chaque mois. C'est une liste que vous n'aurez jamais fini d'entretenir.
3. « Marquez-les en noindex, c'est tout ». Une page portant la balise noindex coûte quand même : le robot doit la demander pour pouvoir lire cette balise. Cela aide le moteur, pas votre processeur.
4. « Prenez un serveur plus gros ». Payer le double pour servir gratuitement votre catalogue à un robot est une mauvaise affaire : le pic suivant sera plus gros, car mieux vous répondez, plus vite on vous demande.
5. « Désactivez la recherche à facettes ». Cela règle la charge et casse la boutique : les filtres sont la façon dont les gens trouvent ce qu'ils vont acheter. Cela se voit dans la conversion dès le lendemain.
6. « Mettez un CDN devant et c'est réglé ». Un CDN accélère ce qui se répète. Ici rien ne se répète : chaque combinaison est unique et finit quand même dans votre base de données.
7. « Activez le mode sous attaque ». Soit vous compliquez aussi la vie de vos clients — et de Google —, soit les robots passent quand même. Cela permet de tenir un après-midi, pas de vivre ainsi.

Toutes partagent le même défaut : elles traitent le symptôme, le trafic, au lieu de la cause, à savoir que votre boutique est prête à fabriquer des millions de pages différentes pour qui les demande.

Où se trouve la vraie solution

Ce qui tient se construit en trois couches, et aucune ne consiste à éteindre les filtres :

• Décider quelles combinaisons existent. Sur toutes celles que votre boutique pourrait générer, une poignée seulement a du sens pour un client ou pour Google. Les autres n'ont pas besoin d'adresse propre, et le terrain de jeu passe de millions à quelques milliers.
• Empêcher le coûteux d'arriver en bas. Les requêtes qui sont du bruit reçoivent une réponse avant de toucher la base de données, et on limite le nombre de recherches par minute qu'une même source peut lancer. Un client en fait trois ; celui qui en fait trois cents n'est pas un client, quel que soit son nom.
• Séparer ceux qui se disputent les ressources. L'exploration ne devrait jamais se battre pour le même processeur que le paiement de quelqu'un. Bien monté, le robot peut attendre ; le client, non.

Avec cela, la consommation chute en général dès le premier jour et la boutique cesse de tomber, sans toucher un seul filtre côté client et sans perdre de terrain sur Google. Au contraire : quand vous cessez de dépenser le temps de Google sur quatre cent mille pages répétées, il commence à regarder celles qui vous intéressent — c'est justement ce que nous expliquions dans par où commencer quand on n'apparaît pas.

Si vous vous battez avec ça depuis des mois

C'est un problème pénible parce qu'il ne se montre jamais : il n'y a pas d'erreur à regarder, juste une boutique qui marche certains jours et pas d'autres, et un hébergeur qui vous renvoie la faute.

Si vous avez déjà essayé deux ou trois solutions de la liste et que rien n'a changé, écrivez-nous. Nous regardons vos journaux, nous vous disons combien de ces requêtes sont réelles et combien sont du bruit, et nous laissons le filtrage en place et sous mesure. Nous l'avons fait plusieurs fois et cela se voit dès le premier jour.

Parlez-nous de votre cas