Pourquoi la recherche PrestaShop ralentit quand le catalogue grandit

Le symptôme

Avec un catalogue de démonstration de vingt ou trente produits, la recherche PrestaShop fonctionne toujours bien : quelle que soit la configuration choisie, la page répond en une fraction de seconde. Le problème n'apparaît que lorsque le catalogue devient vraiment grand, et à ce moment-là il est trop tard pour s'en apercevoir à temps : une boutique de 50 000, 100 000 ou 200 000 produits peut se retrouver avec une page de résultats de recherche qui met plusieurs secondes à répondre, ou une page catégorie filtrée qui devient la plus lente de tout le site.

Ce n'est pas une impression. Sur un catalogue synthétique de 200 000 produits, avec le moteur de recherche natif de PrestaShop (celui qui tourne dans la base de données de la boutique, sans moteur externe), une page de résultats de recherche mettait 28 secondes et une grande page catégorie 30 secondes avant un travail d'optimisation ciblé. Après, la même page répond entre 2 et 6 secondes. Ce sont toujours des secondes, pas des millisecondes : comprendre pourquoi, c'est tout l'objet de cet article.

Pourquoi le temps augmente plus vite que le catalogue

La cause la plus fréquente n'est pas « la base de données est lente », c'est que le même travail est refait plusieurs fois au cours d'une seule requête. Un moteur de recherche à facettes doit répondre à deux questions différentes sur chaque page : quels produits afficher, et pour chaque filtre disponible, combien de produits resteraient si le visiteur le sélectionnait. Si l'ensemble des produits correspondant à la recherche en cours est recalculé de zéro pour chaque filtre, au lieu d'être calculé une fois puis réutilisé, le coût cesse d'être proportionnel au nombre de produits et devient proportionnel au nombre de produits multiplié par le nombre de filtres. Sur un petit catalogue, la différence passe inaperçue. Sur 200 000 produits avec des dizaines de filtres actifs, une recherche qui en théorie ne concerne que cinq produits peut finir par parcourir tout le catalogue une dizaine de fois.

Il en va de même pour des tâches plus petites mais répétées un très grand nombre de fois : si le prix de chaque produit d'une page catégorie est demandé à la base de données un par un au lieu d'être récupéré en bloc, cent produits par page peuvent facilement devenir cent mille requêtes sur un gros catalogue avec des règles de prix par groupe ou par quantité. Aucune de ces requêtes n'est lente prise isolément. C'est leur nombre qui devient insupportable.

Le coût caché des chiffres à côté des filtres

Il existe un second coût, distinct du premier : afficher combien de produits correspondent à chaque valeur d'un filtre, le classique « Rouge (12) » à côté d'une case à cocher. Avec un moteur de recherche externe (Elasticsearch, OpenSearch, Meilisearch), ce chiffre est gratuit : il arrive avec la même requête qui calcule les résultats. Avec le moteur natif, qui travaille dans la base de données de la boutique, chaque valeur de chaque filtre peut nécessiter sa propre requête de comptage.

Sur un catalogue de 200 000 produits comptant environ 2 250 groupes d'attributs et de caractéristiques, désactiver le comptage exact des filtres (afficher la liste des valeurs sans le chiffre à côté) a fait passer une page catégorie avec un filtre actif de 43,3 secondes à 11,9 secondes. Sur les seules facettes de caractéristiques et d'attributs, le temps est descendu de 6,8 et 5,4 secondes respectivement à 15 et 19 millisecondes. Ce n'est pas un arrondi : c'est la différence entre une requête qui doit compter les lignes une à une dans la base et une requête qui se contente de lire une liste de valeurs distinctes jusqu'à une certaine limite, sans toutes les compter.

Pour le commerçant, la question pratique est simple : ce chiffre entre parenthèses vaut-il ce qu'il coûte ? Sur un catalogue de quelques milliers de produits, presque certainement oui. Sur un catalogue de centaines de milliers de produits avec beaucoup de caractéristiques, il peut être le poste le plus coûteux de toute la page, et le désactiver tient souvent à une case de configuration, pas à une réécriture du code.

Ce que montre un test réel sur un catalogue de cette taille

Sur un catalogue synthétique de 200 321 produits, un test interne de la page de recherche complète (calcul des résultats et de toutes les facettes) a mesuré des temps de réponse entre 2,2 et 2,4 secondes. C'est cohérent avec la fourchette de 2 à 6 secondes citée plus haut, obtenue sur une installation différente : deux mesures indépendantes qui racontent la même chose, un catalogue de cette taille répond en un temps qui se compte en secondes, pas en dixièmes de seconde, même après un bon travail d'optimisation. Quiconque promet le contraire pour un catalogue de cette taille avec le seul moteur natif de la base de données mesure probablement sur un catalogue plus petit qu'il ne le dit.

Ce qu'il faut vérifier avant de le découvrir en production

• Faites au moins un test avec un volume de produits proche du volume réel, pas avec le catalogue de démonstration. Ce type de problème est invisible sous les dix mille lignes et très visible au-dessus.
• Vérifiez la limite de mémoire PHP de votre hébergement. Beaucoup d'offres mutualisées restent à 128 ou 256 Mo : des opérations qui chargent des lignes de la base en mémoire au lieu de laisser la base faire le comptage peuvent la dépasser sur de gros catalogues avec beaucoup de caractéristiques ou d'attributs importés par CSV.
• Si vous utilisez le moteur natif sur un gros catalogue, vérifiez si vous pouvez désactiver le comptage exact des filtres, ou s'il vaut mieux passer à un moteur externe (Elasticsearch, OpenSearch ou Meilisearch) qui le calcule comme un sous-produit de la même requête.
• Quel que soit le module de recherche que vous évaluez, demandez si son coût a vraiment été mesuré sur un gros catalogue, avec un chiffre. « Rapide » sans chiffre à côté ne dit pas grand-chose.

En résumé

La recherche PrestaShop ne ralentit pas à cause d'un défaut mystérieux : elle ralentit parce qu'un même travail est répété plus souvent que nécessaire, et cela ne devient visible que lorsque le catalogue grandit assez pour le révéler. Les deux leviers les plus simples à contrôler sont de savoir si le même ensemble de résultats est réutilisé d'un filtre à l'autre, et si les chiffres à côté des filtres sont calculés de façon économique ou coûteuse. Nous avons passé des mois à mesurer et corriger précisément ce genre de problème dans cll_essearch, notre module de recherche et de navigation à facettes pour PrestaShop, qui fonctionne aussi bien avec le moteur natif qu'avec Elasticsearch, OpenSearch et Meilisearch : si vous reconnaissez dans votre boutique les symptômes décrits ici, c'est exactement le type de problème pour lequel il a été conçu.

Recherche Elasticsearch et Navigation à FacettesRecherche ultra-rapide, tolérante aux fautes de frappe, avec navigation à facettes moderne en panneau modal, a…99,99 €Voir le produit