# Filtres à facettes PrestaShop lents : diagnostic et pistes > Une page de catégorie filtrée qui exécute trois cents requêtes a un problème de conception, pas de puissance serveur. Comment mesurer avant de supposer, lire un plan d'exécution, et pourquoi les décisions fonctionnelles ont souvent plus d'effet que l'optimisation technique. - Page: - Langue: fr - Publié le: 2026-09-30 - Mis à jour le: 2026-09-30 - Autres langues: [en](https://www.datafirefly.com/en/2026/09/30/slow-faceted-filters-prestashop-diagnosis/index.md), [es](https://www.datafirefly.com/es/2026/09/30/filtros-facetas-lentos-prestashop-diagnostico/index.md), [de](https://www.datafirefly.com/de/2026/09/30/langsame-facettenfilter-prestashop-diagnose/index.md), [it](https://www.datafirefly.com/it/2026/09/30/filtri-faccette-lenti-prestashop-diagnosi/index.md), [pl](https://www.datafirefly.com/pl/2026/09/30/wolne-filtry-fasetowe-prestashop-diagnoza/index.md), [nl](https://www.datafirefly.com/nl/2026/09/30/trage-facetfilters-prestashop-diagnose/index.md), [pt](https://www.datafirefly.com/pt/2026/09/30/filtros-facetas-prestashop-lentos-diagnostico/index.md) - Index: Un panneau de filtres qui met quatre secondes à répondre est perçu comme cassé. Le problème est rarement le module lui-même : il vient de la façon dont les requêtes sont construites et de ce que la base doit parcourir pour y répondre. Voici comment localiser la cause avant de changer quoi que ce soit. ## Mesurer avant de supposer Trois relevés, dans cet ordre. **Le temps de réponse réel** d'une requête de filtrage, mesuré dans l'onglet réseau du navigateur sur votre plus grosse catégorie avec deux ou trois filtres actifs. Notez la valeur : c'est votre point de départ. **La part de ce temps passée en base.** Activez le profilage de PrestaShop en environnement de test : il affiche le nombre de requêtes exécutées et leur durée cumulée. Si le temps base représente 80 % du total, inutile de regarder ailleurs. **Le nombre de requêtes exécutées.** C'est souvent la révélation : une page de catégorie filtrée qui exécute trois cents requêtes a un problème de conception, pas de puissance serveur. Ce troisième point mérite attention. Une multiplication des requêtes signale généralement un calcul de compteurs valeur par valeur, ou un chargement de produits un par un dans une boucle. ## Les quatre causes principales **Les jointures sur les tables d'attributs.** Filtrer sur trois attributs suppose de joindre plusieurs fois les tables de valeurs. Sur un catalogue de vingt mille combinaisons, ces jointures produisent des ensembles intermédiaires considérables. **Le calcul des compteurs.** Afficher le nombre de résultats derrière chaque valeur suppose une agrégation par valeur. Sur un panneau à soixante valeurs, cela peut faire soixante agrégations à chaque changement de sélection. **Le comptage total pour la pagination.** Compter les lignes d'une sélection large coûte presque autant que de les lire. **Les index manquants.** Sur les tables de liaison entre produits, attributs et catégories, un index absent transforme une recherche en parcours complet de table. ## Diagnostiquer les index C'est la vérification la plus rentable et la plus rapide. Récupérez la requête de filtrage la plus lente depuis le journal des requêtes lentes de votre base, puis exécutez-la précédée du mot-clé d'explication de plan d'exécution. Trois signaux à repérer dans le résultat. **Un type d'accès indiquant un parcours complet** sur une table volumineuse. C'est le signe d'un index manquant ou inutilisable. **Un nombre de lignes examinées** sans commune mesure avec le nombre de lignes retournées. Examiner deux cent mille lignes pour en retourner quarante indique que le filtrage se fait après lecture plutôt que par index. **La mention d'un tri temporaire ou d'une table temporaire**, qui signale que la base ne peut pas satisfaire le tri par index et doit matérialiser un résultat intermédiaire. Point pratique : les index utiles sur ces tables portent souvent sur des colonnes combinées, et leur ordre compte. Un index sur produit puis attribut ne sert pas les mêmes requêtes qu'un index sur attribut puis produit. ## Réduire le travail plutôt que l'accélérer Avant l'optimisation technique, trois décisions fonctionnelles ont souvent plus d'effet. **Réduire le nombre de filtres.** Chaque attribut filtrable ajoute des jointures potentielles et des compteurs à calculer. Douze filtres dont quatre sont utilisés coûtent trois fois trop cher. **Renoncer aux compteurs sur les gros catalogues**, ou ne les calculer que sur les filtres les plus utilisés. Le confort perdu est réel, le gain de temps aussi. **Limiter la profondeur de combinaison.** Au-delà de trois filtres simultanés, les sélections deviennent rares et coûteuses. Vous pouvez plafonner sans que personne ne s'en aperçoive. Ces trois mesures ne demandent aucun développement et se testent en une après-midi. ## L'index dédié Quand les mesures précédentes ne suffisent pas, la réponse structurelle consiste à ne plus interroger les tables de catalogue au moment du filtrage. Le principe : une table plate, pré-calculée, contenant pour chaque produit ses valeurs filtrables, son prix, sa disponibilité et ses catégories. Le filtrage devient une requête simple sur une seule table indexée. Trois points de mise en œuvre. **La mise à jour** doit se déclencher à chaque modification de produit, de prix ou de stock. Un index désynchronisé affiche des produits qui n'existent plus ou masque des nouveautés. **La reconstruction complète** doit rester possible, et son temps d'exécution mesuré : sur un gros catalogue, elle peut prendre plusieurs minutes et ne doit pas s'exécuter en heure de pointe. **Le déclenchement en masse.** Un import de catalogue modifiant dix mille produits ne doit pas déclencher dix mille reconstructions unitaires. Prévoyez un mode différé. ## Le cache, et ses limites Le cache est utile et il est souvent mal employé sur ce sujet. Mettre en cache les résultats de filtrage fonctionne bien quand les combinaisons demandées sont peu nombreuses et répétées. C'est le cas sur la plupart des boutiques : quelques dizaines de combinaisons couvrent l'essentiel du trafic. Deux limites à connaître. Le cache ne **traite pas la première visite** de chaque combinaison, qui reste lente. Et il doit être **invalidé** à chaque changement de stock ou de prix, faute de quoi vous affichez des informations fausses. Sur les données de disponibilité, la durée de cache doit rester courte, quelques minutes, ce qui réduit fortement son intérêt. Une approche courante consiste à mettre en cache la liste des produits correspondants et à récupérer prix et stock en direct. ## Les vérifications côté infrastructure Trois points qui ne relèvent pas du code. **La mémoire allouée à la base.** Une base qui ne peut pas garder ses index en mémoire les relit depuis le disque à chaque requête. C'est la cause la plus fréquente de lenteur généralisée après une croissance de catalogue. **La configuration du cache de requêtes** et des tampons, à ajuster selon la taille réelle de vos données plutôt que de rester sur les valeurs par défaut de l'installation. **Les ressources concurrentes.** Un export de catalogue ou une tâche planifiée qui s'exécute en même temps que le pic de trafic dégrade tout. Décalez ce qui peut l'être. ## La démarche complète Six étapes, dans cet ordre de rentabilité décroissante. **1.** Mesurez le temps de réponse et le nombre de requêtes. **2.** Vérifiez les index avec un plan d'exécution sur la requête la plus lente. **3.** Réduisez le nombre de filtres proposés aux seuls utilisés. **4.** Désactivez ou limitez les compteurs si le catalogue est important. **5.** Mettez en place un cache sur les combinaisons fréquentes. **6.** Envisagez un index dédié si les cinq premières étapes ne suffisent pas. Point de méthode : mesurez après chaque étape. Franchir plusieurs étapes d'un coup vous prive de savoir laquelle a produit l'effet, et donc de savoir où concentrer l'effort la prochaine fois. Le intègre ces mécanismes sur PrestaShop 8 et 9 : index dédié pré-calculé avec mise à jour incrémentale, compteurs de résultats en agrégation unique, cache par combinaison avec invalidation sur les changements de stock et de prix, et limitation paramétrable de la profondeur de combinaison.