Cache Redis pour PrestaShop : configuration et gains de performance

La plupart des conseils de performance PrestaShop s’arrêtent à « utilisez Redis » et vous laissent devant une liste déroulante du back-office, sans savoir quoi saisir dans les quatre champs juste en dessous. Ce guide couvre l’autre moitié : la configuration concrète. Où Redis s’intègre dans PrestaShop, ce que chaque champ de Paramètres avancés → Performances attend, comment envoyer vos sessions vers Redis (ce que le back-office ne peut pas faire pour vous), comment vérifier qu’il met réellement en cache au lieu de revenir silencieusement aux fichiers, et comment lire les chiffres ensuite pour savoir si cela a vraiment aidé. Si vous en êtes encore à décider si Redis vaut le coup pour votre boutique, commencez par les arguments présentés dans Redis pour PrestaShop : l’accélération dont votre boutique a probablement besoin, cet article part du principe que vous avez déjà décidé de l’utiliser et que vous voulez le faire fonctionner correctement.

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 que Redis met en cache dans PrestaShop, et ce qu’il ne met pas en cache

La principale source de déception avec Redis sur PrestaShop vient du fait qu’on lui demande quelque chose qu’il ne fait pas. D’abord, une précision qui conditionne toute la suite : PrestaShop 1.7/8 natif n’expose pas Redis comme backend de cache objet intégré sur la page Performances. Les choix standards du système de cache sont le système de fichiers et des backends de type Memcached (APC/APCu, XCache et Memcache/Memcached, selon votre version de PHP et les extensions chargées). Redis n’apparaît ici que lorsqu’un module ou un backend de cache personnalisé l’ajoute. Une fois disponible, ce réglage pilote exactement une chose : le cache objet interne de PrestaShop. Il s’agit de la couche de la classe Cache, qui stocke des éléments que PrestaShop devrait autrement reconstruire à chaque requête : configuration sérialisée, arbre des catégories, résultats de recherches ObjectModel répétées, enregistrement des hooks de modules et autres structures de données internes similaires. Sur une page très sollicitée, ces lectures ont lieu des dizaines de fois, et les déplacer du disque vers la RAM est précisément là que se trouve le gain.

Cela n’active pas le cache pleine page, et cela ne déplace pas les sessions client vers Redis. Ce sont deux tâches distinctes :

• Le cache pleine page est un mécanisme entièrement différent, il stocke des pages HTML déjà rendues, de sorte que PHP s’exécute à peine. PrestaShop ne propose pas de cache pleine page natif ; vous l’ajoutez avec un module ou un proxy inverse. C’est un sujet à part, traité dans Cache PrestaShop : les modules de cache pleine page expliqués. Redis peut servir de backend de stockage pour certains de ces modules FPC, mais sélectionner un backend de cache objet Redis sur la page Performances ne vous donne pas de cache pleine page.
• Le stockage des sessions dans Redis se configure dans PHP, pas dans le back-office de PrestaShop (voir plus bas). Le réglage Redis de la page Performances laisse les sessions exactement où elles étaient : sur le système de fichiers.

Et alors ? Le savoir dès le départ vous évite l’erreur Redis la plus courante : activer l’option dans le back-office, constater une amélioration modeste, puis conclure que « Redis ne change pas grand-chose ». Vous avez activé l’une des trois tâches possibles. Décidez volontairement lesquelles vous voulez, car chacune se configure à un endroit différent.

Prérequis : côté serveur, en bref

Ceci est un guide de configuration PrestaShop, pas un cours d’administration système Redis ; les étapes serveur sont donc volontairement courtes, et sur un hébergement PrestaShop infogéré, elles sont souvent déjà effectuées pour vous. Deux éléments doivent être présents avant que PrestaShop puisse utiliser Redis :

• Le serveur Redis lui-même, accessible depuis le serveur web (généralement sur 127.0.0.1:6379 lorsqu’il tourne sur la même machine). Vérifiez avec redis-cli ping, une installation saine répond PONG.
• L’extension PHP redis, chargée dans le même PHP que celui qui exécute votre boutique. C’est l’étape que beaucoup ratent : un php -m | grep redis en CLI peut afficher l’extension alors que votre pool PHP-FPM ne l’a pas, parce qu’ils chargent des fichiers php.ini différents. Vérifiez le PHP qui compte vraiment via la page Paramètres avancés → Informations de votre boutique (qui indique la configuration PHP active) ou avec un phpinfo() temporaire. S’il n’y a pas de section Redis à cet endroit, un backend de cache Redis ne fonctionnera pas, peu importe ce que dit la CLI, et n’oubliez pas que le backend lui-même doit être ajouté par un module avant même d’apparaître.

Si votre hébergeur ne fournit pas Redis du tout et refuse de le faire, c’est réellement une décision d’hébergement, pas une décision de cache, nous l’expliquons sans détour dans choisir un hébergement pour PrestaShop : ce qui compte vraiment et ce qui relève du marketing. La mise en cache ne peut pas sauver un hébergeur qui ne vous donne pas les bons outils.

Étape 1, Activer le cache objet depuis le back-office

Dans votre boutique, ouvrez Paramètres avancés → Performances et repérez la section Cache, son emplacement exact sur la page varie selon les versions. Ensuite :

• Réglez Utiliser le cache sur Oui.
• Dans Système de cache, choisissez le backend Redis. Rappelez-vous qu’il n’apparaît ici que si un module ou un backend de cache personnalisé l’a ajouté (et si l’extension PHP redis est chargée), PrestaShop natif ne liste que le système de fichiers et les options de type Memcached. S’il n’y a pas de choix Redis, installez/activez le module qui le fournit et confirmez que l’extension redis est chargée ; voir les prérequis.
• Renseignez les champs de connexion qui apparaissent :
  • Serveur (IP/nom d’hôte) : 127.0.0.1 pour Redis sur la même machine, ou le nom d’hôte du conteneur/service (par exemple redis) dans une configuration Docker ou orchestrée.
  • Port : 6379, sauf si vous l’avez volontairement modifié.
  • Base de données : 0 pour une seule boutique. Si plusieurs installations PrestaShop partagent un même serveur Redis, donnez à chacune un numéro de base différent afin qu’elles ne lisent pas les clés des autres, Redis propose par défaut les bases 0 à 15.
• Cliquez sur Ajouter un serveur, puis sur Enregistrer.

La liste de serveurs native ici suit une logique multi-serveur de type Memcached ; certains adaptateurs/modules Redis permettent d’ajouter plusieurs serveurs de cache, mais la redondance Redis multi-serveur n’est pas une fonctionnalité PrestaShop garantie. Vérifiez que votre module Redis la prend réellement en charge avant de vous appuyer dessus. Pour une boutique sur une seule machine, une seule entrée reste de toute façon la norme. Après l’enregistrement, le cache objet est actif immédiatement. Il n’y a pas d’étape distincte de « préchauffage » ; le cache se remplit au fil des visites.

Étape 2, Vérifier qu’il utilise vraiment Redis (ne partez pas du principe que oui)

L'écran de configuration Redis contient les champs de connexion : hôte, port, mot de passe, index de base de données et préfixe de clé.

Un réglage enregistré ne prouve rien. PrestaShop peut accepter une configuration Redis et continuer à servir les pages pendant que le cache reste vide, par exemple si la connexion échoue silencieusement en charge. Confirmez que cela fonctionne avant de lui faire confiance :

• Parcourez quelques pages du front-office (accueil, catégorie, produit) afin de générer des écritures dans le cache.
• Sur le serveur, lancez redis-cli, puis DBSIZE sur le numéro de base de données choisi. Considérez cela comme un contrôle rapide, pas comme une preuve : sur une boutique qui fonctionne, le compteur doit quitter 0 et augmenter pendant votre navigation, mais le chiffre exact n’est pas un signal fiable, les préfixes de cache, la base sélectionnée, les TTL et le comportement de vidage, l’implémentation de l’adaptateur et le simple fait d’avoir un petit catalogue peuvent tous rendre un DBSIZE brut trompeur.
• Pour une vraie confirmation, utilisez redis-cli INFO (surveillez keyspace_hits/keyspace_misses en progression) et redis-cli MONITOR pendant quelques secondes pendant que vous rechargez une page (puis Ctrl-C, ne laissez jamais MONITOR tourner sur une boutique chargée, c’est lui-même un frein aux performances). Vous devriez voir défiler des commandes GET et SET contenant les préfixes de clés de votre backend de cache ; vérifier ces préfixes propres à l’adaptateur confirme que c’est bien votre boutique qui parle à cette instance. Le silence signifie que PrestaShop ne communique pas avec cette instance Redis.

Et alors ? Cette vérification de trente secondes fait toute la différence entre « j’ai activé Redis » et « Redis met ma boutique en cache ». Beaucoup de boutiques tournent pendant des mois avec un cache configuré mais inactif, simplement parce que personne n’a vérifié que le nombre de clés quittait réellement zéro.

La version shell de cette vérification est assez courte pour rester dans vos notes de déploiement :

redis-cli -h 127.0.0.1 -p 6379 PING
redis-cli -h 127.0.0.1 -p 6379 DBSIZE
redis-cli -h 127.0.0.1 -p 6379 INFO stats | egrep 'keyspace_hits|keyspace_misses'

Étape 3, Déplacer les sessions vers Redis (facultatif, au niveau PHP)

Pour les sessions PHP, cela se règle dans la configuration PHP, pas dans un champ du back-office PrestaShop. Un gestionnaire de sessions Redis typique ressemble à ceci :

session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?database=1&prefix=pssess:"

Le stockage des sessions est une décision séparée et se configure dans un fichier séparé. Par défaut, PrestaShop écrit un fichier de session par visiteur sur le disque ; avec une vraie concurrence d’accès, ce brassage du système de fichiers devient un goulot d’étranglement précisément sur les hébergements où vous avez le plus besoin d’aide. Le déplacement des sessions vers Redis se configure dans PHP, dans votre php.ini ou, mieux, dans le pool PHP-FPM de ce site :

session.save_handler = redis

session.save_path = "tcp://127.0.0.1:6379?database=1"

Notez le numéro de base volontairement différent (1) de celui du cache objet (0). Les séparer signifie que vous pouvez vider le cache objet, une opération courante après des changements de templates ou de modules, sans déconnecter tous les clients en plein tunnel d’achat. Les mélanger dans une même base transforme un simple vidage de cache en vague de paniers abandonnés. Redémarrez PHP-FPM après la modification, puis confirmez avec redis-cli -n 1 DBSIZE que le nombre augmente à mesure que les visiteurs arrivent.

Une remarque de durabilité propre aux sessions : Redis fonctionne en mémoire, donc un redémarrage de Redis peut supprimer les sessions enregistrées depuis son dernier instantané disque et déconnecter les clients actifs. Si vous stockez les sessions dans Redis sur une boutique en production, activez la persistance AOF (append-only-file) afin qu’un redémarrage fasse perdre quelques secondes de données de session plutôt que plusieurs minutes, les instantanés RDB seuls conviennent à un cache objet jetable, mais ils sont trop grossiers pour des paniers actifs.

Étape 4, Définir une limite mémoire et une politique d’éviction

Un cache objet autorisé à grossir sans limite finira par consommer la RAM dont vos workers PHP et votre base de données ont besoin, et le remède (un serveur lent qui swappe) sera pire que le mal. Donnez un budget à Redis dans sa configuration (redis.conf) :

• maxmemory, une limite stricte. Le bon chiffre dépend de la taille du catalogue et du trafic ; beaucoup de boutiques uniques tiennent confortablement dans quelques centaines de Mo pour le cache objet, davantage si vous y stockez aussi les sessions. Surveillez l’usage réel (section suivante) plutôt que de deviner trop haut.
• maxmemory-policy allkeys-lru, lorsque la limite est atteinte, évincer les clés les moins récemment utilisées. Pour un cache pur, c’est le choix sûr par défaut : les entrées obsolètes ou rarement consultées sont supprimées en premier, et PrestaShop les reconstruit simplement à la requête suivante. (Si la même instance Redis contient aussi des sessions, préférez une politique volatile-lru avec des TTL afin que l’éviction ne puisse pas supprimer silencieusement une session connectée, ou, plus proprement, gardez les sessions sur une instance Redis séparée.)

Étape 5, Mesurer le gain honnêtement

La raison de tout cela, c’est la vitesse ; mesurez donc la vitesse, mais mesurez-la correctement, car Redis améliore le temps de réponse du serveur, pas les parties de la page qui dépendent des images et des ressources front-end. L’indicateur qui bouge est le Time To First Byte (TTFB) : le temps nécessaire au serveur pour commencer à envoyer la page. Le cache objet réduit les lectures disque répétées qui gonflent le TTFB ; c’est donc là que vous verrez le gain.

• Avant de changer quoi que ce soit, relevez une base de référence. Chargez plusieurs fois une page produit et une page catégorie représentatives (pour mesurer un cache chaud, pas un cache froid) et notez le temps de réponse serveur, l’onglet Réseau des DevTools du navigateur affiche le TTFB de chaque requête, et des outils comme PageSpeed Insights ou WebPageTest le signalent aussi. Pour un chiffre serveur comparable, le plus propre est une requête déconnectée avec le cache du navigateur désactivé.
• Activez Redis, vérifiez-le (étape 2), réchauffez le cache en naviguant, puis mesurez de nouveau les mêmes pages de la même façon.
• Comparez le TTFB, pas le grand chiffre de « chargement complet de la page ». Une image hero non optimisée de 5 Mo dominera le temps de chargement complet et masquera une vraie amélioration backend, ce qui peut vous amener à conclure à tort que Redis « n’a rien changé ».

À quel point est-ce plus rapide ? Honnêtement, cela dépend entièrement de votre point de départ. Une boutique sur un hébergement mutualisé lent avec de fortes E/S disque peut voir une forte baisse du TTFB, car c’est précisément le goulot d’étranglement que Redis supprime ; une boutique déjà sur un VPS NVMe rapide avec une charge légère peut constater un gain plus modeste, parce que les lectures disque ne la pénalisaient pas beaucoup au départ. Quiconque vous donne un pourcentage universel unique est en train de deviner. Le seul chiffre qui compte est celui que vous mesurez sur votre propre boutique, avant et après, sur les mêmes pages. Pour une méthode structurée afin de diagnostiquer d’abord où part réellement votre temps, consultez votre boutique est-elle lente ? comment le vérifier et quoi faire ensuite.

Surveiller Redis une fois en production

Après la configuration, quelques valeurs de redis-cli INFO vous indiquent si le cache est sain ou s’il échoue discrètement :

Dépanner les problèmes de configuration que vous rencontrerez vraiment

Le backend Redis n’apparaît pas dans la liste déroulante

Deux causes possibles : soit le module/backend personnalisé qui ajoute Redis comme système de cache n’est pas installé (PrestaShop natif ne l’affichera pas), soit l’extension PHP redis n’est pas chargée dans l’environnement PHP de votre boutique. Confirmez que le module fournisseur est actif, revérifiez l’extension via la page Informations de la boutique ou phpinfo() (pas la CLI), et vérifiez que vous avez redémarré PHP-FPM après l’installation de l’extension.

Le cache est configuré, mais DBSIZE reste à 0

PrestaShop peut être dans l’impossibilité de joindre Redis, mais une base de données vide ne prouve pas à elle seule un échec de connexion. Les suspects habituels : Redis est lié uniquement à 127.0.0.1 alors que PrestaShop se connecte depuis un autre hôte/conteneur (fréquent avec Docker, indiquez le nom du service dans le champ Serveur, pas localhost) ; un pare-feu bloque le port 6379 ; ou Redis ne tourne tout simplement pas.

Données obsolètes après modification d’un produit ou d’une catégorie

Si les modifications n’apparaissent qu’après vidage du cache, le cache objet n’est pas invalidé comme prévu. Vider le cache PrestaShop depuis Paramètres avancés → Performances (le bouton Vider le cache) est la correction propre ; redis-cli -n 0 FLUSHDB efface uniquement la base du cache objet sans toucher aux sessions de la base 1. Si le problème revient, le coupable le plus probable est un module qui se comporte mal et ne vide pas son propre cache à l’enregistrement.

Clients déconnectés après un déploiement ou un redémarrage

Sessions dans Redis sans persistance AOF, ou sessions partageant une base avec le cache objet et supprimées lors d’un vidage. Séparez les bases de données (étape 3) et activez AOF.

Redis est une couche, faites les choses dans le bon ordre

Redis est le plus rentable lorsque les couches situées en dessous sont déjà saines, et il ne peut pas compenser un problème qu’il ne traite pas. Avant Redis ou en parallèle :

• OPcache met en cache le bytecode PHP compilé afin que le moteur cesse de réanalyser vos fichiers à chaque requête. C’est presque gratuit et complémentaire, OPcache accélère le code, Redis accélère les données. Utilisez les deux.
• Une base de données gonflée ou mal indexée produit toujours des requêtes lentes à la première demande, que Redis ne fait que masquer jusqu’à l’expiration du cache. Les vraies corrections, optimisation des requêtes et nettoyage, sont couvertes dans optimiser les performances de votre boutique PrestaShop et nettoyage de base de données : pourquoi votre boutique PrestaShop ralentit avec le temps.
• Les vraies causes profondes d’une boutique lente, trop de modules, des hooks lourds, un hébergement faible, sont diagnostiquées dans ce qui rend vraiment PrestaShop lent. Mettez en cache le résultat d’une mauvaise requête et la première requête non mise en cache restera lente ; corrigez la requête et le cache rendra instantané quelque chose de déjà rapide.

Pour un exemple concret de toutes ces couches empilées sur une vraie boutique fortement étendue, voyez ce que cela donne sur un scorecard dans PageSpeed 99/100 sur une vraie boutique PrestaShop avec 130 modules.

Questions de configuration qui arrivent après la liste déroulante

Dois-je conserver les fichiers CacheFs après être passé à Redis ? Non. Une fois que le backend de cache objet est Redis et que vous l’avez vérifié (étape 2), l’ancien cache système de fichiers sous var/cache/ n’est plus que de la donnée périmée. Le vider depuis Paramètres avancés → Performances est sans risque et plus propre. Ne supprimez toutefois pas var/cache/ à la main sur une boutique PrestaShop 9 : le conteneur Symfony de l’admin s’y trouve, et une suppression brute peut mettre le back-office en erreur 500. Utilisez le bouton Vider le cache du back-office.

Le cache objet et les sessions doivent-ils partager une même instance Redis ? Ils le peuvent, mais gardez-les dans des bases de données différentes, le cache objet en 0, les sessions en 1 (étape 3). C’est cette séparation qui vous permet de vider le cache objet après un changement de template ou de module sans déconnecter chaque client en plein tunnel d’achat. Si vous pouvez lancer une deuxième instance, placer les sessions sur leur propre Redis avec persistance AOF est encore plus propre, car les sessions ont besoin d’une durabilité qu’un cache jetable n’exige pas.

Est-il sûr d’exécuter FLUSHALL pour vider le cache ? Non, FLUSHALL efface toutes les bases de l’instance, y compris les sessions et toute autre boutique qui la partagerait, ce qui supprime des paniers actifs. Videz le cache objet depuis le back-office, ou utilisez redis-cli -n 0 FLUSHDB pour effacer uniquement la base du cache objet tout en laissant intactes les sessions de la base 1. N’utilisez jamais FLUSHALL sur une instance de production.

Pourquoi mon taux de réussite a-t-il chuté après la mise en production ? Généralement pour l’une de ces trois raisons : maxmemory est trop bas et Redis évince des clés (surveillez evicted_keys. Il doit rester proche de zéro pour un cache pur), un calendrier de purge trop agressif régénère le cache en permanence, ou un module mal conçu vide le cache à chaque enregistrement. Augmentez d’abord maxmemory, puis auditez ce qui déclenche les vidages. Un cache chaud en bonne santé se maintient confortablement au-dessus de 90 % de hits.

Redis remplace-t-il OPcache ? Non, ils mettent en cache des choses différentes et vous devez utiliser les deux. OPcache met en cache le bytecode PHP compilé afin que le moteur cesse de réanalyser vos fichiers à chaque requête ; Redis met en cache les données que PrestaShop reconstruit. Sur PHP 8, le JIT fait partie d’OPcache et constitue le gain serveur gratuit le plus important. Activez OPcache, que vous adoptiez Redis ou non.

Si vous préférez ne pas toucher au serveur

Tout ce qui précède est réalisable depuis un back-office et un shell, mais cela suppose que vous puissiez modifier un pool PHP-FPM, définir une politique maxmemory et lire redis-cli INFO, un terrain confortable pour une agence, beaucoup moins pour un marchand qui veut simplement gagner en vitesse sans faire de l’administration système. C’est précisément le vide que notre module mprinstantredis est conçu pour combler : il connecte le cache objet de PrestaShop à Redis, maintient les bases de données des sessions et du cache séparées afin qu’un vidage de cache ne supprime jamais les paniers actifs, et affiche le taux de réussite ainsi que les chiffres mémoire dans le back-office plutôt que dans un terminal. Qu’est-ce que cela vous apporte concrètement ? La même configuration correctement séparée et surveillée que celle décrite ici, mais configurée depuis l’administration plutôt que depuis les fichiers serveur, utile lorsque vous voulez le résultat sans gérer toute la plomberie serveur. La voie manuelle de ce guide reste parfaitement valable ; le module supprime simplement les étapes qui poussent la plupart des marchands à chercher un développeur.

Le schéma à retenir : Redis sur PrestaShop couvre trois tâches distinctes, cache objet (back-office), sessions (PHP) et backend facultatif pour le cache pleine page (un module). Activez volontairement celles dont vous avez besoin, vérifiez que chacune est réellement active au lieu de le supposer, gardez les sessions et le cache dans des bases différentes, et jugez le résultat au TTFB mesuré sur votre propre boutique. Faites cela, et Redis cesse d’être une case à cocher dont vous espérez un effet : il devient une couche dont vous pouvez prouver le fonctionnement.