Commencer gratuitement

DROPFIND FILTERS · PRESTASHOP

Vos filtres ne devraient pas pouvoir
mettre la boutique à terre.

Les filtres de catégorie sont le deuxième moteur de recherche de votre boutique : beaucoup de gens n'écrivent rien du tout et arrivent au produit en cochant des options. Mais dans PrestaShop cette fonction se paie cher — et la facture n'arrive pas sous forme de lenteur, elle arrive sous forme de boutique en panne un mardi ordinaire, sans que personne n'ait rien touché.

Dropfind Filters fait le même travail sans le demander à votre base de données.

inclus dans tous les forfaits · s'installe à côté du moteur de recherche

Il ne touche pas à votre base de donnéesLes compteurs de chaque option sortent de l'index de recherche, qui est fait pour cela.
Il écarte les robotsIl marque les adresses filtrées comme non indexables et ajoute les règles au robots.txt tout seul.
Et il ne déplace pas les résultatsOuvrir un filtre ne pousse pas la liste vers le bas : on voit l'effet pendant qu'on l'applique.
Découvrez pourquoi

Pourquoi elle tombe, exactement

Pas besoin de s'y connaître en bases de données. Chaque fois que quelqu'un coche un filtre, votre boutique ne cherche pas seulement les produits qui correspondent : elle recompte aussi combien il en resterait sous chacune des autres options, pour afficher ces nombres entre parenthèses. Ce recomptage est le travail coûteux, et il recommence en entier à chaque clic. Avec peu de produits cela ne se voit pas ; le problème est que les combinaisons possibles ne grandissent pas doucement, elles explosent.

3filtres à 5 valeurs chacun
215combinaisons, en choisissant une seule valeur par filtre
× 40catégories avec filtres dans un catalogue ordinaire
8.600adresses distinctes qu'un robot peut demander
chacune d'ellesoblige à tout recompter depuis zéro
32.767et ce chiffre était l'optimiste : avec la sélection multiple, ces trois filtres à eux seuls

Comment Dropfind Filters le résout

Quatre décisions, et aucune n'est magique : il s'agit de déplacer le travail coûteux là où il est bon marché.

C'est un autre qui compte

Les nombres de chaque option sont calculés par un moteur de recherche dédié, qui tient son propre index prêt pour exactement cela. Votre base de données n'apprend jamais que quelqu'un filtre, donc elle reste entière pour ce qui compte : le panier et la commande.

Une requête par page, pas une par produit

Les données des fiches —nom, photo, prix— viennent bien de votre boutique, parce qu'elles doivent être exactes. Mais en une seule requête pour toute la page, au lieu d'une par produit comme le fait le listing natif. Sur une page de 24 produits, cela fait 24 fois moins de travail.

Les robots cessent d'entrer

Les adresses avec filtres sont marquées non indexables, et quand vous générez le robots.txt depuis votre back-office, le module ajoute tout seul les seules règles qui écartent les moteurs de recherche de ce labyrinthe. Il ne s'agit pas de cacher quoi que ce soit : ces pages n'apportent rien à l'index de Google et elles vous coûtent du serveur.

Et ce qui se répète n'est pas recalculé

Un même état de filtres renvoie toujours la même chose tant que votre catalogue ne change pas, donc la réponse est gardée sur votre propre serveur. Mesuré dans une vraie boutique : de trois requêtes au moteur à zéro dès que quelqu'un répète la combinaison. Et elle s'invalide toute seule à la réindexation.

Rien de tout cela n'exige de toucher à votre thème ni de renoncer à votre design : les filtres s'ancrent là où vous le décidez et les fiches produit sont dessinées avec le gabarit que votre boutique utilise déjà.

Essayez-le ici même

Un catalogue inventé, de vrais filtres. Regardez les nombres de chaque option : ils changent tout seuls et ne laissent jamais d'impasse.

12 sur 12 produits 0 requêtes à votre base de données

Filtres (12)

Le petit délai quand vous cochez une option est simulé exprès : il reproduit le voyage jusqu'au moteur de recherche, qui dans une vraie boutique existe bel et bien.

Votre acheteur y gagne aussi

Supprimer le problème technique, c'était la moitié. L'autre moitié, c'est que filtrer cesse d'être pénible — parce qu'un filtre que personne n'utilise n'économise aucun serveur, mais ne vend rien non plus. La plupart des filtres de boutique poussent les résultats hors de l'écran juste au moment où vous voulez voir l'effet de ce que vous venez de cocher.

0 sautles résultats ne bougent pas quand on ouvre un filtre
en lignechaque groupe est un bouton ; ses options s'ouvrent par-dessus, sans rien pousser
mobileun panneau qui glisse depuis le bas, avec le compteur de résultats sur le bouton
votre couleuril hérite de la couleur que vous configurez : on dirait une partie de votre boutique, pas de la nôtre
Et un avertissement honnête. Le cache économise sur le trafic répété, mais un robot qui parcourt de nouvelles combinaisons paie chacune d'elles. C'est pour cela que les règles du robots.txt comptent autant que la performance — et pourquoi le module vous recommande en plus une limite de requêtes sur votre serveur, la seule chose qui arrête celui qui ignore ces règles.

C'est compris. Ce n'est pas une option.

Filters fait partie de tous les forfaits, à côté du moteur de recherche : même index, même compte, même facture. Nous ne le facturons pas à part parce qu'il ne nous coûte pas à part — il partage l'index que votre recherche entretient déjà, donc son coût marginal pour nous est nul.

Et parce que facturer séparément précisément ce qui évite que votre boutique tombe nous semblerait une drôle de façon de faire des affaires.

Voir les forfaits Lire sur la recherche en e-commerce

Demandez-nous ce que vous voulez

Si vous ne savez pas si cela convient à votre boutique, écrivez-nous. Nous répondons en heures, pas en jours.

Nous n'utilisons ce que vous écrivez que pour vous répondre. Si vous préférez, hola@dropfind.es.

Et personne n'a besoin de vous attaquer

Les moteurs de recherche envoient des programmes qui ouvrent, un par un, tous les liens de votre site. Si chaque combinaison de filtres a sa propre adresse —et par défaut c'est le cas—, ils vont tous les ouvrir.

Ce n'est pas une attaque : c'est Google qui fait son travail. Mais votre serveur encaisse des milliers de recomptages à la suite, et c'est pour cela que la boutique tombe un mardi matin sans que personne n'ait rien fait d'étrange.

Pire encore : cet effort ne vous rapporte rien. Ces pages n'apportent rien à l'index de Google —ce sont des variantes d'une catégorie déjà indexée— donc vous payez du serveur pour un trafic qui ne vous amène pas un seul client.

Le détail technique

Chaque comptage de facettes se résout avec des requêtes agrégées —GROUP BY avec JOIN— sur product_attribute, feature_value et leurs tables de liaison. Elles ne se mettent pas en cache facilement, car le résultat dépend des filtres posés, c'est-à-dire exactement de ce qui change à chaque visite.

De plus le comptage doit être disjonctif: à l'intérieur d'un même groupe les valeurs s'additionnent, donc les nombres de ce groupe doivent être calculés en appliquant tous les filtres sauf le sien. Cela multiplie les requêtes par le nombre de groupes ayant une sélection.

Et le listing qui les accompagne se résout d'habitude avec une requête par produit au lieu d'une pour toute la page — le motif connu sous le nom de N+1. Sur une page de 24 produits, cela fait 24 allers-retours vers la base de données là où un seul suffisait.