Redis pour PrestaShop : l’accélération dont votre boutique a probablement besoin

La plupart des conseils d’optimisation des performances pour PrestaShop finissent par arriver au même mot : Redis. On le recommande comme un remède miracle. « Ajoutez Redis, votre boutique sera plus rapide », généralement sans expliquer ce qu’il remplace réellement, quelles boutiques en ont vraiment besoin, ni quelles pages lentes il ne changera absolument pas. Cet article est la version honnête de cette discussion. Il s’agit de savoir si Redis est la bonne prochaine étape pour votre boutique précise, ce qu’il modifie sous le capot dans une installation PrestaShop, et comment décider, avant de payer une mise à niveau VPS dont vous n’avez peut-être pas besoin. Pour l’installation pas à pas et les réglages qui produisent les gains, nous vous renvoyons vers notre guide complémentaire sur la configuration du cache Redis et les gains de performance ; ici, l’objectif est la décision, pas les commandes à saisir.

Revu pour PrestaShop 1.6, 1.7, 8.x et 9.x. Nous utilisons Redis sur mypresta.rocks. Les compromis décrits reflètent cette expérience. Redis ne détermine pas à lui seul un score PageSpeed : comparez l’ensemble de la boutique avant et après une modification dans les mêmes conditions de test.

Ce qu’est vraiment Redis, en un paragraphe honnête

Redis est une base clé-valeur en mémoire, un dictionnaire très rapide qui vit en RAM au lieu de vivre sur le disque. Vous lui donnez une clé (par exemple, les données rendues de la catégorie 12) et il renvoie la valeur en une fraction de milliseconde, parce que rien ne touche le disque et rien n’interroge MySQL. C’est toute l’astuce : ce n’est pas un « module d’accélération », c’est un endroit plus rapide pour stocker des éléments que PrestaShop met déjà en cache. Ce n’est ni spécifique à PrestaShop ni nouveau, c’est une infrastructure open source mature qui fonctionne comme un service sur votre serveur (ou comme une option managée chez votre hébergeur). Ce que cela change pour un marchand : chaque élément de données servi par Redis est une requête de base de données qui ne s’exécute pas et une lecture disque qui n’a pas lieu ; sur une page fréquentée, ces économies s’additionnent jusqu’à rendre la boutique visiblement plus rapide.

Ce que Redis remplace dans PrestaShop, précisément

PrestaShop met déjà plusieurs éléments en cache ; par défaut, il les stocke sur le disque ou dans la base MySQL. Redis peut prendre le relais comme couche de stockage pour des caches sélectionnés et pour la gestion des sessions, mais uniquement lorsqu’un adaptateur de cache, un module ou un gestionnaire de sessions PHP compatible est configuré pour pointer vers lui ; ce n’est pas un stockage natif et automatique pour chaque cache intégré. Dans une boutique PrestaShop, les éléments concernés sont :

• Cache objet (le principal). La couche de cache de PrestaShop (Paramètres avancés → Performances → Cache, le réglage Cache dont les moteurs disponibles varient selon la version de PrestaShop et les extensions PHP installées, historiquement le système de fichiers (CacheFs), Memcached, APC/APCu et Xcache ; Redis n’est pas une option standard du cœur et nécessite un module ou un adaptateur personnalisé) stocke des objets que PrestaShop reconstruit sur presque chaque page, valeurs de configuration, arbre des catégories, listes de hooks, données de devise et de langue. Servi depuis le disque (CacheFs), cela devient une rafale de petites lectures de fichiers ; servi depuis Redis, c’est une recherche en mémoire. C’est là que se trouve l’essentiel du gain réel.
• Cache des templates Smarty. PrestaShop compile les templates .tpl et met le résultat en cache. Par défaut, ces fichiers compilés et mis en cache vivent sur le disque sous var/cache/ (les anciennes versions utilisaient cache/smarty), PrestaShop standard ne déplace pas le cache de compilation Smarty dans Redis, donc cela n’arrive que via une intégration personnalisée ou tierce, pas par un réglage intégré.
• Sessions PHP. Les données de session client, état de connexion, contenu du panier, utilisent par défaut des fichiers sur le disque (le gestionnaire de sessions fichier natif de PHP). Déplacer les sessions vers Redis retire cette charge de lecture/écriture au système de fichiers et, dans les configurations multi-serveurs, permet à chaque serveur applicatif de partager un même stockage de sessions au lieu de garder ses propres fichiers locaux.
• Cache pleine page. Des pages entières déjà rendues pour les visiteurs anonymes peuvent être conservées dans Redis et renvoyées presque instantanément. C’est un sujet à part entière, avec de vrais compromis, quoi mettre en cache, comment l’invalider, ce qui casse pour les clients connectés, nous le gardons donc dans l’explication des modules de cache pleine page plutôt que de le traiter trop vite ici.

Le cadrage honnête : Redis ne fait pas faire moins de travail à PrestaShop. Il fait revenir depuis la RAM, au lieu du disque ou de MySQL, le travail que PrestaShop répète déjà, les mêmes lectures de configuration, le même arbre de catégories, les mêmes templates compilés, requête après requête.

Votre boutique a-t-elle vraiment besoin de Redis ? Un cadre de décision

C’est la question que les vendeurs de remèdes miracles évitent. Redis vaut le coup pour certaines boutiques et n’est qu’une surcharge pour d’autres. Passez votre boutique dans ce filtre avant de dépenser quoi que ce soit :

Si vous ne savez pas encore dans quel cas vous êtes, c’est l’étape préalable, pas Redis. Diagnostiquez d’abord : comment vérifier si votre boutique est lente et ce qui la ralentit, puis l’analyse de ce qui rend réellement PrestaShop lent, base de données, modules et hébergement. Acheter de la RAM pour Redis alors que le problème est finalement une image d’en-tête de 4 Mo est une erreur fréquente et évitable.

Ce que Redis ne corrigera pas (pour ne pas accuser la mauvaise cause)

C’est aussi important que les bénéfices, car un marchand qui installe Redis en pensant qu’il va tout corriger finit déçu et convaincu que le cache ne sert à rien. Redis ne fait rien pour :

• Requêtes impossibles à mettre en cache. Une vérification de stock en temps réel ou un calcul de prix par client s’exécute volontairement à chaque page. Il n’y a rien à cacher. Si une requête précise est lente, c’est la requête qu’il faut corriger, donc un sujet base de données : voir l’optimisation des performances, des requêtes base de données au cache pleine page.
• Modules lourds. Un module qui exécute du PHP coûteux à chaque requête continue de l’exécuter. Le cache accélère les lectures de données, pas les chemins d’exécution du code.
• Ressources front-end non optimisées. Redis est un cache côté serveur ; il ne touche jamais une image produit de 5 Mo ni un script qui bloque le rendu. C’est le rôle de CCC, de la compression d’images et d’un CDN.
• Base de données gonflée. Des années de paniers morts, de sessions invité obsolètes et de lignes orphelines ralentissent MySQL d’une manière que le cache ne fait que masquer. Nettoyez aussi l’accumulation : pourquoi votre boutique ralentit avec le temps, et le nettoyage qui inverse la tendance.
• API externes lentes. Un appel de paiement ou de livraison vers un tiers au chargement de page est une latence que vous ne maîtrisez pas ; Redis ne peut pas mettre en cache le serveur de quelqu’un d’autre.

Redis est un multiplicateur pour une boutique déjà propre, pas un sauvetage pour une boutique désordonnée. Le bon ordre est : alléger les modules, corriger les requêtes évidentes, nettoyer la base de données, puis ajouter Redis pour que les opérations restantes reviennent depuis la RAM.

Redis ou Memcached sur PrestaShop

La liste déroulante de cache de PrestaShop propose aussi Memcached, donc la comparaison mérite d’être clarifiée. Les deux gardent les données en RAM ; pour une boutique PrestaShop, les différences pratiques se résument ainsi :

Pour l’immense majorité des boutiques PrestaShop, Redis est le bon choix, la persistance et le vidage limité à un préfixe le justifient déjà à eux seuls, et le cas multi-boutique ci-dessous achève de trancher.

Redis pour le multi-boutique et le multi-serveur

Si vous exploitez plusieurs boutiques depuis une même installation PrestaShop, ou la même boutique sur plusieurs serveurs applicatifs, une seule instance Redis peut toutes les servir. Chaque boutique obtient son propre espace de clés via un préfixe, de sorte que les paniers et objets en cache ne fuient jamais d’une boutique à l’autre tout en partageant la RAM sous-jacente, moins cher et plus simple que de lancer un cache séparé par boutique. Cette discipline de préfixe est aussi ce qui rend possible un vidage ciblé : vider le cache de la boutique B après un import de prix sans redémarrer à froid la boutique A. Dans une configuration avec répartition de charge, la même instance donne à chaque serveur un cache unique et un stockage de sessions unique, afin qu’un client ne soit pas déconnecté parce que le répartiteur l’a envoyé vers un autre nœud.

Le piège de l’hébergement mutualisé

L’impasse la plus fréquente : Redis a besoin d’un service en cours d’exécution sur le serveur, et l’hébergement mutualisé n’en fournit presque jamais (pas de SSH, aucun moyen de lancer un daemon). Si vous êtes sur un hébergement mutualisé et voulez Redis, la vraie décision n’est pas « quel module ». C’est de savoir si votre boutique a dépassé les limites du mutualisé. En général, une boutique assez grande pour bénéficier de Redis est déjà assez grande pour justifier un VPS, et le choix d’hébergement lui-même mérite un examen sérieux : ce qui compte vraiment dans l’hébergement PrestaShop par rapport au marketing. Ne payez pas pour une offre « compatible Redis » avant d’avoir confirmé que Redis est bien votre goulot d’étranglement.

Comment savoir si cela fonctionne vraiment

Le tableau de bord des performances affiche des cartes pour le TTFB, le LCP, le taux de succès du cache et les requêtes lentes, un graphique de tendance Web Vitals, et le backend de cache réglé sur fichier.

Un cache que vous ne voyez pas est un cache auquel vous ne pouvez pas faire confiance. Deux chiffres indiquent si Redis mérite sa place, et les journaux propres à PrestaShop ainsi que la sortie Redis INFO exposent les deux :

Depuis le terminal, le contrôle minimal utile est celui-ci :

redis-cli -h 127.0.0.1 -p 6379 INFO stats | egrep 'keyspace_hits|keyspace_misses'
redis-cli -h 127.0.0.1 -p 6379 INFO memory | egrep 'used_memory_human|maxmemory_human|used_memory_peak_human'

• Taux de succès du cache. Le ratio entre les succès de cache et le total des recherches (keyspace_hits vs keyspace_misses dans Redis INFO). Vous voulez qu’il soit nettement au-dessus de 90 %. Un taux faible signifie que le cache est constamment régénéré, généralement à cause d’un calendrier de vidage trop agressif ou d’un manque de mémoire, et que vous payez Redis sans en obtenir le bénéfice.
• Marge mémoire. Surveillez used_memory par rapport à votre limite maxmemory. Dès que Redis atteint le plafond, il commence à évincer des clés, le taux de succès du cache baisse, et votre boutique « rapide » ralentit discrètement. Comme ordre de grandeur pour planifier : jusqu’à ~5k produits tiennent souvent confortablement dans 256MB ; 5k–50k demandent plutôt 512MB–1GB ; les très grands catalogues, davantage, mais considérez ces valeurs comme des points de départ à vérifier avec votre vrai used_memory_peak, pas comme des garanties.

Et mesurez le résultat qui paie les factures, pas seulement les entrailles du cache. Avant de changer quoi que ce soit, notez votre Time to First Byte et le temps moyen de génération des pages (depuis le profileur de PrestaShop, activé via _PS_DEBUG_PROFILING_ dans config/defines.inc.php en préproduction, ou la barre de débogage Symfony, ou votre APM et les journaux serveur) ; une fois Redis en ligne et chaud, comparez les mêmes chiffres sur du trafic réel pendant plusieurs jours, pas un après-midi calme. Une réduction du temps de génération sur les pages catégorie et produit lourdes est le signal que cela a fonctionné.

Connecter PrestaShop à Redis sans YAML

Vous pouvez brancher Redis à PrestaShop à la main, modifier la configuration, définir la classe de cache, gérer les détails de connexion, redémarrer les services et espérer ne pas avoir mal saisi un hôte. C’est faisable, et notre guide de configuration détaille la voie manuelle. Si nous avons créé Redis Cache Manager & Monitor, c’est parce que la voie manuelle ne vous donne aucune boucle de retour : vous ne voyez pas votre taux de succès du cache, vous ne savez pas si la mémoire est sur le point d’évincer des clés, et vider le cache sans risque suppose de savoir exactement quelles clés appartiennent à quelle boutique.

Redis Cache Manager & Monitor gère toute cette relation depuis le back-office. Qu’est-ce que cela signifie concrètement ? Vous saisissez votre hôte et votre port Redis et testez la connexion avant de valider, il renvoie la version du serveur, la mémoire utilisée, les clients connectés et le temps de disponibilité, pour savoir qu’il est joignable au lieu de le deviner. Vous activez indépendamment le cache objet, le stockage des sessions et le cache pleine page, en n’allumant que ce dont votre boutique a besoin. Le tableau de bord affiche le taux de succès du cache et l’utilisation mémoire en direct. Les deux chiffres ci-dessus, pour que « est-ce que ça marche ? » devienne un coup d’œil, pas une session redis-cli. Et lorsque vous enregistrez la configuration, il peut vider uniquement les clés de votre boutique (par préfixe) plutôt que toute l’instance, ce qui le rend sûr sur un serveur multi-boutique. Le bénéfice n’est pas « nous avons rendu Redis sophistiqué ». C’est qu’un marchand, pas seulement un administrateur système, peut exploiter Redis correctement et prouver qu’il aide. Ce qui se passe si Redis devient indisponible dépend entièrement de la manière dont chaque couche est câblée : un adaptateur de cache ou un gestionnaire de sessions mal configuré peut casser les requêtes au lieu de se dégrader proprement, donc le repli propre se vérifie, il ne se suppose pas. Redis Cache Manager & Monitor est conçu pour revenir au cache par défaut de PrestaShop si Redis tombe, mais testez ce comportement sur votre propre configuration avant de vous y fier.

Les questions que les marchands posent avant d’adopter Redis

Redis mettra-t-il aussi en cache mon panier et mes pages de commande ? Pas comme cache objet, et vous ne le souhaitez pas. Le cache objet accélère les lectures répétées derrière une page, configuration, arbre des catégories, listes de hooks, pas le panier, le tunnel de commande ou l’état de connexion propres à chaque client, qui sont dynamiques par nature et doivent rester à jour. Redis peut stocker les sessions (pour qu’un panier survive entre serveurs), mais c’est un autre rôle que de mettre en cache une page rendue. Le cache pleine page est la couche qui renvoie du HTML complet, et elle est correctement limitée aux visiteurs anonymes, un client connecté ou toute personne avec un panier la contourne. Mettez en cache la vitrine, jamais le panier ni la connexion.

OPcache ou Redis : quelle est la meilleure première étape ? Activez OPcache d’abord. Il est quasi gratuit, livré avec PHP, et met en cache le bytecode compilé pour que le moteur cesse de réanalyser vos fichiers à chaque requête. Sur PHP 8, le JIT fait partie d’OPcache et constitue le plus gros gain serveur gratuit que les versions récentes de PHP offrent à une boutique limitée par le CPU. Redis met en cache les données ; OPcache met en cache le code. Ils sont complémentaires, mais OPcache est celui à activer avant de dépenser quoi que ce soit en RAM pour Redis.

Que se passe-t-il pour ma boutique si le serveur Redis tombe ? Cela dépend entièrement de la manière dont chaque couche est câblée, et cela mérite d’être vérifié plutôt que supposé. Un cache objet correctement câblé devrait revenir au cache par défaut de PrestaShop si Redis tombe ; un adaptateur de cache ou un gestionnaire de sessions mal configuré peut au contraire casser les requêtes. Testez le cas de panne sur votre propre configuration, arrêtez Redis en préproduction et chargez une page, avant de compter sur un repli propre en production.

Redis ou Memcached. Est-ce que cela compte vraiment pour une seule boutique ? Pour la plupart des boutiques PrestaShop, Redis. Les critères décisifs sont honnêtes et modestes : Redis survit à un redémarrage avec une persistance disque optionnelle (Memcached reconstruit tous les caches à froid après un redémarrage), et Redis vide par préfixe de clé, ce qui vous permet de nettoyer une boutique sans supprimer le reste. Memcached reste acceptable sur un existant et peut stocker les sessions PHP si vous le câblez au niveau PHP, mais sur une nouvelle configuration, il y a rarement une raison de le choisir plutôt que Redis. Varnish est encore un autre outil, un cache HTTP pleine page placé devant PHP, pas un moteur de cache objet interchangeable, donc comparez-le à votre décision de cache pleine page, pas à Redis comme cache objet.

Combien de RAM dois-je attribuer à Redis ? Partez de votre catalogue et vérifiez avec l’usage réel, ne surestimez pas au hasard. Comme ordres de grandeur : jusqu’à ~5k produits tiennent souvent dans 256MB ; 5k–50k demandent plutôt 512MB–1GB ; les catalogues plus grands, davantage. Surveillez ensuite used_memory_peak par rapport à votre maxmemory, si Redis atteint le plafond, il évince des clés, le taux de succès du cache baisse et votre boutique « rapide » ralentit discrètement. Le bon chiffre est celui que confirme votre propre sortie INFO memory.

Conclusion

Redis est l’une des améliorations au meilleur rapport effort/impact pour une boutique PrestaShop, une fois que c’est la bonne amélioration. Toute la discipline se trouve dans cette condition. Si votre boutique est sur un VPS, reçoit assez de trafic répété et possède une profondeur de catalogue suffisante pour remplir un cache, et si vous avez déjà traité les images, les modules lourds et la base de données gonflée, Redis transforme le travail que PrestaShop répète toute la journée en lectures mémoire, et vous le verrez dans votre TTFB. Si vous êtes sur un hébergement mutualisé, ou si votre vrai problème est une requête non mise en cache ou une image surdimensionnée, Redis n’est pas le bon outil et votre argent doit d’abord aller ailleurs. Diagnostiquez, nettoyez, puis mettez en cache, et mesurez le taux de succès du cache pour ne jamais deviner si Redis mérite sa RAM. Quand vous serez prêt à le connecter, le guide de configuration et de performance prend le relais.