Le cache PrestaShop ne se résume pas à un interrupteur

Quand j'analyse la lenteur d'une boutique PrestaShop, je commence par déterminer ce qui fait attendre le client. Une page de catégorie qui tarde à répondre ne se traite pas comme des photos produit trop lourdes à télécharger. De même, une page d'accueil rapide ne garantit pas un tunnel de commande fluide. Le cache permet de réutiliser un résultat déjà calculé. Encore faut-il savoir ce qu'il conserve, à qui il peut le servir et comment il détecte que ce résultat n'est plus valable.

Dans PrestaShop, plusieurs niveaux peuvent coexister : cache des templates, cache de données, cache PHP, cache du navigateur et, éventuellement, cache de pages complètes. Chacun intervient à un endroit différent. Les réglages disponibles et leurs intitulés varient aussi selon les versions et les traductions du back-office. Ce guide couvre donc les possibilités actuelles, mais aussi les technologies que l'on rencontre encore sur d'anciennes boutiques. La présence d'une option dans le back-office ne signifie pas que votre hébergement permet réellement de l'utiliser.

Smarty : compilation des templates et cache de leur rendu

Je commence généralement dans Paramètres avancés → Performances. Smarty transforme les templates du thème en code exécutable par PHP. Forcer la compilation à chaque chargement est utile pendant le développement ou un diagnostic, mais ajoute du travail inutile en production. Recompiler les templates uniquement lorsqu'un fichier a changé constitue souvent un bon point de départ. Ne plus vérifier les modifications suppose, en revanche, de renouveler systématiquement le cache lors des déploiements. Il faut distinguer cette compilation du cache des rendus, exploité par certaines parties de la boutique et par les modules qui le prennent correctement en charge. Activer le cache Smarty ne crée pas automatiquement une copie statique de chaque page complète, utilisable sans risque pour tous les clients. Tout dépend de la façon dont les modules gèrent le contexte. Après une modification, je vérifie notamment les prix, la disponibilité, la langue et l'affichage pour les clients connectés. Les principales options figurent dans la documentation des réglages de performances de PrestaShop.

Fichiers, base de données et nettoyage automatique

Lorsque la version de PrestaShop propose plusieurs supports pour le cache Smarty, il faut distinguer le système de fichiers du stockage dans MySQL. Pour une boutique classique sur un seul serveur, je privilégie d'abord un cache de fichiers sur un disque local rapide. Le déplacer vers MySQL risque simplement d'ajouter des requêtes à une base déjà sollicitée par le catalogue et les commandes. À l'inverse, un stockage réseau lent ou une accumulation de petits fichiers mérite une analyse spécifique. Les règles de nettoyage après une modification de produit ou de thème sont tout aussi importantes. Un nettoyage trop fréquent réduit le bénéfice du cache ; une invalidation insuffisante laisse apparaître d'anciens contenus. Avec plusieurs serveurs applicatifs, la synchronisation doit être prévue. Les fichiers locaux d'un serveur ne sont pas automatiquement accessibles aux autres. Le guide d'optimisation destiné aux développeurs aborde le cache de fichiers et l'analyse des performances des modules.

CCC : le cache intelligent pour les feuilles de style

CCC signifie Combine, Compress and Cache. Pour les styles, il s'agit de préparer les fichiers CSS et de conserver le résultat afin de ne pas recommencer le traitement à chaque requête. Selon la version et le thème, cela peut réduire le volume transféré et le nombre de fichiers. Je vérifie toujours le résultat dans la boutique, en particulier le menu mobile, la galerie produit, les filtres et le tunnel de commande. Un CSS mal écrit ou des chemins d'images incorrects peuvent poser problème après traitement alors qu'ils semblaient fonctionner auparavant. Il n'est pas non plus judicieux d'envoyer une immense feuille de style contenant les règles de dizaines de fonctions inutilisées. Avec HTTP/2 et HTTP/3, la seule réduction du nombre de requêtes ne suffit plus à justifier de tout regrouper. Je m'intéresse au poids des fichiers, à leur utilisation réelle et à leur effet sur le premier affichage.

CCC : JavaScript et réglages du serveur web

JavaScript demande davantage de précautions. Les scripts d'un module peuvent dépendre d'un ordre de chargement précis ou d'une bibliothèque fournie par le thème. Après avoir activé le cache intelligent, je teste donc les changements de déclinaison, l'ajout au panier, la connexion, les transporteurs et les moyens de paiement. Certains défauts n'apparaissent que sur un appareil donné ou après identification. Si la version installée propose d'autres optimisations du HTML ou du chargement des scripts, je les active une par une et applique les mêmes contrôles. Le traitement effectué par CCC ne doit pas être confondu avec la compression des réponses en gzip ou Brotli, assurée par le serveur web ou le CDN. L'optimisation Apache concerne un environnement Apache adapté ; elle ne remplace pas la configuration de Nginx. Le code source de la classe Media permet de vérifier les détails du traitement.

Cache de données natif : Memcache, Memcached, APC et Xcache

La section distincte consacrée au système de cache sert à choisir le moteur du cache de données. Ce réglage est indépendant du cache Smarty et ne transfère pas automatiquement tout le travail de la base de données en mémoire vive. Son intérêt dépend des parties du cœur et des modules qui l'utilisent, de la fréquence de réutilisation des données et du coût des échanges avec le service. Pour ce niveau, on choisit un moteur : les quatre options ne s'activent pas simultanément. Avant de conserver un changement, je compare les temps de réponse avec et sans cache, puis avec un cache vide et un cache déjà alimenté. La documentation de l'architecture du cache PrestaShop aide à comprendre pourquoi ces différents mécanismes doivent être examinés séparément.

Memcached via PHP::Memcache

Cette première option utilise le service serveur Memcached, auquel PHP accède avec l'extension Memcache, sans « d » final. Installer uniquement le service ne suffit pas : l'extension doit aussi être chargée dans l'environnement PHP qui exécute la boutique. Vérifier PHP en ligne de commande ne renseigne pas nécessairement sur la configuration PHP-FPM utilisée pour les pages web. Selon l'interface disponible, on renseigne l'adresse du serveur, son port et éventuellement une pondération. Le service peut être local ou partagé entre plusieurs serveurs applicatifs. Dans ce dernier cas, les échanges réseau ont un coût : le gain doit donc être mesuré. L'administrateur doit également prévoir assez de mémoire et réserver l'accès au service au réseau approprié. Des entrées peuvent être évincées lorsque la mémoire est pleine. Memcached n'est donc pas un stockage permanent pour les commandes. Les prérequis figurent dans le manuel de l'extension Memcache, et la connexion est détaillée dans l'adaptateur natif de PrestaShop.

Memcached via PHP::Memcached

La seconde option s'appuie sur le même type de service, mais emploie une autre extension PHP : Memcached, avec un « d » final. Fondée sur libmemcached, elle possède sa propre interface et ses propres dépendances. Les extensions Memcache et Memcached ne sont pas interchangeables : le choix du back-office doit correspondre à ce qui est réellement installé. Pour un nouvel environnement, j'étudierais cette variante en fonction de la prise en charge par l'hébergeur, de la version de PHP et des résultats des tests. Elle n'est pas automatiquement plus rapide. Je surveille le taux de succès du cache, la mémoire utilisée, les évictions et les délais de connexion. Je vérifie aussi que les clés des différentes installations sont suffisamment isolées et qu'un nettoyage ne perturbe pas une autre boutique. Un service partagé peut faciliter l'accès aux mêmes données depuis plusieurs serveurs, sans pour autant synchroniser tous les autres caches de l'application. Le manuel Memcached et l'adaptateur CacheMemcached précisent les conditions d'installation et le fonctionnement.

APC et APCu : un cache de données local

L'intitulé APC demande un peu de contexte. À l'origine, APC associait le cache des données applicatives à celui du code PHP compilé. Dans un environnement actuel, c'est APCu qui concerne les données applicatives, tandis qu'OPcache prend généralement en charge le code PHP. Voilà pourquoi le lien affiché près de l'option APC peut mener à l'installation d'APCu. Ce n'est pas un simple changement de nom : il faut vérifier la compatibilité de la version de PrestaShop concernée. Par exemple, l'adaptateur CacheApc de la branche 8.2 gère explicitement APC et APCu. L'intérêt de la mémoire partagée locale est d'éviter une connexion vers un serveur de cache distant. Son périmètre dépend toutefois de l'organisation des processus PHP ; ce n'est pas un cache réseau commun à plusieurs machines. Je contrôle la mémoire allouée et le comportement après un redémarrage de PHP. Attention également au nettoyage en ligne de commande : il ne vide pas forcément la mémoire utilisée par les processus web.

Xcache : une option à replacer dans son époque

Xcache figure à juste titre dans d'anciennes installations de PrestaShop et dans certaines listes de moteurs disponibles. L'extension proposait un cache du code PHP et des variables applicatives, dont l'adaptateur PrestaShop utilisait la partie données. Je ne la choisirais toutefois pas pour une nouvelle boutique sous un PHP récent au seul motif que l'option reste affichée. L'historique des versions du projet concerne principalement la génération PHP 5, très éloignée d'un serveur actuel. Il faudrait d'abord établir la compatibilité avec le PHP installé et la continuité de la maintenance. Pour une ancienne boutique reprise en gestion, je vérifie si Xcache fonctionne réellement et quelles dépendances existent, puis je prépare la modernisation de l'environnement. Revenir à un PHP obsolète pour conserver un mécanisme de cache serait un mauvais compromis. Le dépôt Xcache constitue une référence historique, pas un guide d'installation général pour les boutiques PrestaShop actuelles.

OPcache et caches internes de l'application

PHP OPcache conserve le code PHP précompilé pour éviter au serveur de le compiler à nouveau à chaque requête. C'est un élément important de l'hébergement de PrestaShop, mais pas un moteur supplémentaire dans la liste des caches de données ci-dessus. Je vérifie son activation pour les requêtes web, la mémoire disponible et sa capacité à accueillir le nombre de fichiers nécessaires. Si la détection des modifications est désactivée, le déploiement doit explicitement renouveler le code en cache. PrestaShop utilise aussi ses propres caches applicatifs, avec des mécanismes Symfony dans ses composants modernes. Leur nettoyage peut être nécessaire après une modification des services ou le déploiement d'un module. Le bouton « Vider le cache » n'efface cependant pas automatiquement les copies du navigateur, de chaque module et de Cloudflare. Face à un contenu périmé, je recherche d'abord le niveau qui le conserve.

Cache du navigateur et en-têtes HTTP

Un serveur bien configuré permet au navigateur de réutiliser les images, feuilles de style, scripts et polices au lieu de les télécharger intégralement à chaque visite. Les principaux réglages passent par Cache-Control et, le cas échéant, Expires. ETag et Last-Modified peuvent servir à vérifier si une ressource a changé. Une longue durée de validité convient aux fichiers statiques dont l'URL est modifiée lors d'une mise à jour. Sans ce mécanisme de version, les clients risquent de conserver un ancien CSS même après le nettoyage du cache de la boutique. Le HTML personnalisé nécessite d'autres règles qu'une photo produit. La documentation de configuration Apache fournit des exemples pour les ressources statiques ; Nginx doit recevoir des règles équivalentes. Je contrôle les en-têtes réellement reçus par le navigateur, car un proxy peut modifier le comportement prévu à l'origine.

Les modules de cache sur addons.prestashop.com

La place de marché officielle propose notamment Page Cache Pro et Page Cache Ultimate. Ce sont des exemples à comparer, pas des recommandations valables pour toutes les boutiques. Les modules de cette catégorie peuvent conserver des pages complètes ou de larges portions du rendu. En cas de succès du cache, PHP évite alors de refaire une partie du travail. Les pages publiques du catalogue sont souvent les premières concernées. Avant tout achat, je vérifie néanmoins la prise en charge de la version exacte de PrestaShop, de PHP, du thème et des modules essentiels. J'examine aussi la gestion des blocs dynamiques, l'invalidation automatique après modification d'un produit et le préchargement du cache. Un score mis en avant commercialement ne garantit pas le bon fonctionnement des règles de prix et du tunnel de commande.

La clé de cache est déterminante. Une même URL peut présenter une langue, une devise, une fiscalité, un tarif de groupe client ou une offre propres à une boutique selon le contexte. Le panier, le compte client, la commande, les réponses personnalisées et les retours des prestataires de paiement doivent bénéficier d'exclusions adaptées ou d'un traitement dynamique sûr. Pour un visiteur non connecté, je teste également ce qui se passe dès qu'il commence à remplir son panier. Un module adapté doit permettre de vérifier ces scénarios et d'invalider les pages concernées de manière ciblée. Je travaille sur une copie de la boutique et contrôle autant l'exactitude que la vitesse. Cumuler deux modules de cache de pages complètes complique surtout l'identification de la copie responsable d'un contenu périmé.

Serveurs de médias : déporter les ressources statiques

Le réglage natif Serveurs de médias permet de servir certaines ressources statiques depuis un autre domaine ou sous-domaine, par exemple via un réseau de diffusion de contenu, ou CDN. Renseigner une adresse ne copie toutefois aucun fichier et ne crée pas cette infrastructure. La destination doit déjà fournir les images, le CSS et le JavaScript attendus. Je contrôle ensuite le certificat HTTPS, les chemins, la disponibilité et, pour les polices, les éventuelles règles CORS. Un sous-domaine dirigé vers le même serveur peut avoir un intérêt d'organisation, mais n'ajoute ni puissance de calcul ni copies géographiquement plus proches. Les anciennes recommandations consistant à répartir les fichiers sur plusieurs domaines pour multiplier les téléchargements parallèles doivent aussi être réévaluées avec HTTP/2 et HTTP/3. Chaque domaine supplémentaire peut demander une nouvelle connexion. J'utilise donc les serveurs de médias pour un objectif précis, généralement avec un véritable CDN, puis j'en mesure l'effet.

Cloudflare : commencer par les fichiers statiques

Cloudflare peut se placer devant la boutique en tant que proxy inverse et CDN. Bien configuré, son réseau distribué sert les ressources statiques éligibles et limite les transferts répétés depuis le serveur d'origine. En revanche, le HTML ordinaire et le JSON ne sont pas mis en cache par défaut. Une simple modification DNS n'évite donc pas à PHP de générer les fiches produit. Une mise en place de base n'impose pas non plus de modifier les serveurs de médias : Cloudflare peut intervenir directement devant le domaine principal. Je vérifie les succès réels du cache dans les en-têtes et les rapports du service, plutôt que de me fier à son activation. La documentation du comportement par défaut de Cloudflare Cache explique les règles et la prise en compte des en-têtes du serveur d'origine.

Mettre du HTML en cache en périphérie du réseau demande des règles adaptées à la boutique. Un « Cache Everything » général peut conserver du contenu propre à un client si les exceptions sont incomplètes. Exclure une seule URL de panier ne suffit pas : il faut considérer les routes, paramètres, cookies, connexions et contextes tarifaires. Les conditions disponibles et les possibilités de personnaliser la clé dépendent aussi du service et de l'offre. Le contournement du cache selon un cookie est un outil, pas une configuration PrestaShop prête à l'emploi. Les changements de produits doivent aussi entraîner l'invalidation des copies concernées. Si un module de cache est associé à Cloudflare, je définis à l'avance qui nettoie chaque niveau et à quel moment.

Pour aller plus loin : proxy inverse, Varnish et Redis

Sur un serveur que l'on maîtrise, on peut également envisager le cache FastCGI de Nginx ou un proxy inverse comme Varnish. Ces solutions conservent des réponses HTTP et nécessitent, elles aussi, des exclusions, une gestion correcte des contextes clients et une invalidation coordonnée. Redis peut servir à certains caches ou aux sessions grâce à un module adapté ou à une intégration spécifique. Il ne se substitue pas automatiquement à l'un des quatre moteurs natifs présentés ici. Pour ce type d'architecture, je veux connaître le rôle de chaque composant et disposer d'une administration serveur fiable. Empiler des technologies parce qu'elles figurent dans des listes d'optimisations ne constitue pas une stratégie. La boutique doit aussi rester prévisible après un redémarrage de service, un import du catalogue ou un nettoyage complet du cache.

Ma méthode pour une boutique concrète

Je commencerais par mesurer l'existant : temps de réponse, requêtes SQL, charge des modules et volume des fichiers transférés. Je corrigerais ensuite les ralentissements évidents et vérifierais le mode production, OPcache et Smarty. Viendraient alors le CSS, le JavaScript, les images et les en-têtes des fichiers statiques. Ce sont les résultats qui guideraient ensuite le choix d'un moteur de données, d'un module de cache ou d'un CDN. Une copie de la page d'accueil ne résout pas une opération SQL lente au moment de valider une commande.

Je compare chaque changement au premier chargement et lors des visites suivantes, sur mobile et dans différents parcours clients. Outre le TTFB, c'est-à-dire le délai jusqu'au premier octet de la réponse, et l'affichage du contenu principal, je contrôle les prix, les mises à jour de stock, les codes de réduction, la livraison et l'intégralité du tunnel de commande. La vitesse juste après un nettoyage compte également : elle révèle la charge réelle de la boutique. Un cache bien conçu accélère l'achat tout en préservant l'exactitude des informations. Mon travail d'optimisation des performances PrestaShop commence donc par l'identification des limites de votre boutique, avant de définir les améliorations pertinentes.