Quelqu’un qui filtre une liste ou tape dans le champ de recherche ne fait pas du lèche-vitrine : il sait ce qu’il veut. Ce sont les visiteurs les plus prêts à acheter, et ce sont justement eux que PrestaShop fait le plus attendre. Chaque clic sur un filtre, et chaque pause pendant la saisie dans la recherche, est une requête au serveur : PrestaShop démarre, lance des requêtes lourdes sur la base de données et renvoie le résultat. Et aucune de ces réponses ne peut être mise en cache.
Cet article explique ce qui se passe à chaque clic, ce que cela pèse sur une vraie boutique, et comment Instant Filters et Instant Search déplacent le travail : du serveur vers le navigateur du client.
Ce qui se passe à chaque clic
La recherche à facettes de PrestaShop et son champ de recherche fonctionnent de la même façon : le navigateur demande au serveur le résultat de chaque changement. La recherche standard le fait chaque fois que le client marque une pause en tapant (quelques dixièmes de seconde), pour afficher des suggestions.
Le chemin d’un clic sur un filtre ou d’une lettre dans la recherche
Ce qu’on économise quand le catalogue est déjà dans le navigateur
- Clic ou touche
- →
- Requête
- →
- Démarrage de PrestaShop
- →
- Requêtes à la base de données
- →
- Compteurs et prix
- →
- Réponse
- Clic ou touche
- →
- Le navigateur cherche dans ses fichiers
- →
- Résultat
Avec peu de visiteurs, on ne le voit pas. Avec du trafic, ces requêtes entrent en concurrence avec celles des clients qui paient : la recherche et les filtres font partie des pages les plus coûteuses d’une boutique, et comme chaque combinaison de filtres ou de lettres est différente, un cache de pages ne peut pas les garder.
Requêtes au serveur pendant une seule visite
Exemple : taper « t-shirt » dans la recherche, puis cocher 5 filtres
Exemple illustratif : jusqu’à 7 requêtes pendant la saisie (une à chaque pause du client) et 5 en filtrant. Avec les modules, le navigateur télécharge une fois les fichiers statiques, qu’un CDN peut servir, puis il n’interroge plus le serveur.
La vitesse, ce sont des ventes
Ce n’est pas un détail technique. Quand la réponse tarde, le client s’en va :
Ce que disent les études
Un filtre qui met une seconde à répondre se sent à chaque clic. Une recherche qui ne suggère rien tant que le serveur n’a pas répondu semble en panne. Et un produit que le client ne trouve pas est un produit qu’il n’achète pas.
Déplacer l’endroit où le travail se fait
Les deux modules partagent la même idée : la boutique prépare les données une fois, et le navigateur du client fait le reste.
- PrestaShop écrit des fichiers JSON statiques avec le catalogue : ce qu’on peut filtrer (catégories, marques, caractéristiques, attributs, prix, stock) et ce qu’on peut chercher (nom, références, marque, catégories, mots-clés, descriptions…). Il y a un jeu par langue, devise et groupe de clients : les prix sont toujours ceux que paie ce visiteur.
- Le navigateur les télécharge une seule fois : la recherche, au premier clic dans le champ ; les filtres, à l’ouverture d’une liste. Ce sont des fichiers statiques : le serveur web les envoie sans PHP, ou un CDN s’en charge.
- Ensuite, filtrer, compter, trier, paginer et chercher se fait dans le navigateur, en quelques millisecondes et sans aucune autre requête.
- Quand vous modifiez un produit, son stock, un prix ou une catégorie, les hooks de PrestaShop mettent à jour seulement ce qui a changé. Aucune tâche cron.
La liste imprimée par le serveur ne change pas : Google et les visiteurs sans JavaScript la voient comme avant.
Une recherche qui comprend ce que tapent les clients
Comme la recherche se fait dans le navigateur, elle peut se montrer généreuse avec la saisie : comparer des milliers de mots y prend quelques millisecondes. Instant Search ignore les majuscules et les accents, trouve les mots pendant qu’on les tape et pardonne les fautes : « t-shrit caost » trouve « T-shirt Coast », même avec des lettres inversées. Si aucun produit ne contient tous les mots, il montre ceux qui en ont le plus, au lieu d’une page vide.
Et c’est vous qui décidez où chercher et combien compte chaque endroit : nom, référence et codes-barres, marque, catégories, caractéristiques, attributs, mots-clés et descriptions, chacun avec un poids de 1 à 10. Une zone « Essayez » dans le back-office classe vos produits avec les poids que vous déplacez, avant d’enregistrer.
Avant et après, sur une boutique de 20 000 produits
Plutôt que de deviner, nous avons monté une boutique PrestaShop 9 avec 20 000 produits sur un serveur comme celui de nombreuses boutiques : 4 cœurs et 8 Go de RAM, avec PHP et la base de données sur la même machine. Nous avons simulé 50 visiteurs en même temps, chacun faisant ce que fait un client : ouvrir une catégorie, cocher deux filtres, chercher « mountain fox » et ouvrir les résultats, avec quelques secondes entre chaque action. D’abord avec la recherche et les filtres standard de PrestaShop, puis avec Instant Filters et Instant Search.
Ce qui change avec 50 visiteurs en même temps
| Avec 50 visiteurs en même temps | Sans les modules | Avec les modules |
|---|---|---|
| Clic sur un filtre | 0,20 s (1 sur 10 au-delà de 0,42 s) | 0,02 s dans le navigateur, 0,09 s sur un mobile moyen. Aucune requête au serveur |
| Suggestions de recherche | 0,45 s (1 sur 10 au-delà de 2,2 s) | De 1 à 6 ms dans le navigateur, de 2 à 25 ms sur un mobile moyen. Aucune requête au serveur |
| Page de résultats | 0,48 s (1 sur 10 au-delà de 2,4 s) | 0,04 s (1 sur 10 au-delà de 0,06 s) |
| Page de catégorie | 0,33 s (1 sur 10 au-delà de 1,2 s) | 0,27 s (1 sur 10 au-delà de 0,33 s) |
| Requêtes PHP par seconde | 15,4 | 5,2 |
| Processeur de la base de données | ~300 % (3 des 4 cœurs) | ~32 % |
| Téléchargements une fois par visite | — | 0,38 Mo de filtres et 0,31 Mo de recherche, compressés |
Mesures d’ecom-addons, novembre 2026 : PrestaShop 9.0.2 en mode production avec 20 000 produits, recherche standard (ps_searchbar) et recherche à facettes standard (ps_facetedsearch) face à Instant Search et Instant Filters. Serveur de 4 cœurs et 8 Go simulé avec Docker ; 50 visiteurs avec des pauses d’environ 5 secondes, pendant 90 secondes. « Mobile moyen » : Chrome avec le processeur 4 fois plus lent. Les temps sont des médianes.
Ce qu’attend le client à chaque action
Avec 50 visiteurs en même temps sur un serveur de 4 cœurs et 8 Go : du temps typique (médiane) jusqu’à l’attente des 10 % de visiteurs les plus lents
Ce qui change, ce n’est pas seulement le temps de chaque clic :
- La recherche et les filtres ne touchent plus le serveur. Chaque suggestion et chaque filtre passent d’une requête à PHP et à la base de données à quelques millisecondes dans le navigateur du client.
- Le serveur respire. Les requêtes PHP tombent au tiers, et la base de données passe de 3 des 4 cœurs au tiers d’un seul. C’est pourquoi même les pages qui passent encore par PHP, comme les catégories, deviennent plus rapides et plus régulières : sans les modules, 1 sur 10 prenait plus de 1,2 s ; avec eux, 0,33 s.
- Les longues attentes disparaissent. Sans les modules, 1 suggestion sur 10 prenait plus de 2 secondes, justement quand le plus de monde cherchait. Avec les modules, il n’y a pas de file d’attente, car il n’y a pas de requête.
Utilisation du processeur par la base de données
Avec 50 visiteurs en même temps, sur un serveur de 4 cœurs (400 % = les 4 entiers)
Avec plus de visiteurs, ou sur un hébergement mutualisé, l’écart se creuse : sans les modules, le travail du serveur augmente avec chaque visiteur qui cherche ou filtre ; avec eux, non.
Les textes de cette boutique de test se répètent beaucoup, d’où une si bonne compression : dans un catalogue aux textes très variés, les fichiers de 20 000 produits peuvent peser jusqu’à 1,5 Mo compressés. Cela reste le poids de quelques photos de produits, téléchargé une seule fois par visite.
Le trio de la vitesse
Une boutique rapide a besoin que les trois choses que fait le plus un visiteur aillent vite :
- La page. Page Cache sert des pages déjà prêtes aux nouveaux visiteurs, en une demi-seconde environ au lieu de plusieurs, sans risque pour les paniers ou les prix. Nous l’expliquons dans cet article.
- Les filtres. Instant Filters filtre, compte et trie dans le navigateur, sans une requête par clic.
- La recherche. Instant Search répond à chaque touche, fautes comprises, sans interroger la base de données.
Les trois fonctionnent sur PrestaShop 8.2 et 9.0, avec n’importe quel thème et sans toucher au serveur. Et les trois rendent le même service à votre serveur : ils lui retirent le travail qu’il est inutile de refaire pour chaque visiteur.
Envie de tout voir au même endroit ? Accélérer PrestaShop réunit le cache de pages, les filtres, la recherche et le tunnel de commande, avec nos mesures et par où commencer.
Sources
- Deloitte Digital et Google, Milliseconds Make Millions (2020).
- Portent, Site Speed is (Still) Impacting Your Conversion Rate (2022).
- Think with Google, statistiques sur le temps de chargement.
- Mesures d’ecom-addons avec un catalogue de test de 20 000 produits (novembre 2026).