Cache PrestaShop : les modules de cache pleine page expliqués, avantages, limites et fonctionnement réel

Nous développons Performance Revolution, nous avons donc un intérêt direct dans le sujet, mais nous allons tout de même vous parler franchement. Un module de cache pleine page peut transformer en un après-midi un PrestaShop qui répond en 3 secondes en une boutique qui répond en 200 ms. Pour la plupart des boutiques que nous auditons, c’est la bonne décision dès le premier jour. Que ce soit encore la bonne au bout de quatre-vingt-dix jours dépend de la cause réelle de la lenteur, et de votre intention de la corriger un jour.

Revu pour PrestaShop 1.7, 8.x et 9.x. Les compromis liés à l’hydratation et à l’invalidation sont les mêmes sur les trois versions ; PS8/9 ajoutent une couche de cache Symfony qu’un cache objet comme Redis peut aider à accélérer, comme expliqué plus bas.

Qu’est-ce que le cache pleine page ?

Par défaut, chaque requête de page PrestaShop démarre PHP, charge le framework, exécute entre 40 et 400 requêtes SQL, compile les templates Smarty, puis renvoie enfin du HTML. Sur les boutiques de développement que nous exploitons, cela représente 200 à 400 ms. Sur le PrestaShop moyen en hébergement mutualisé qu’on nous appelle à sauver, on est plutôt entre 2 et 5 secondes.

Un module de cache pleine page (FPC) court-circuite tout cela. Le premier visiteur d’une page la rend normalement ; le module récupère le HTML final et le stocke. Tous les visiteurs suivants reçoivent cette copie stockée, pas de démarrage PHP, pas de base de données, pas de Smarty. Juste des octets servis depuis le disque, Redis ou Varnish.

Le TTFB passe de plusieurs secondes à quelques dizaines de millisecondes. Il n’existe pas de moyen plus rapide de donner une sensation de vitesse à un PrestaShop lent sans réécrire les parties lentes.

Comment fonctionnent les modules FPC pour PrestaShop

Le principe est le même dans tous les modules FPC que nous avons examinés, le nôtre compris :

1. Première visite. La page est rendue normalement par PrestaShop, le module capture le HTML à la sortie et l’écrit dans un stockage (fichier, Redis, Memcached ou nœud CDN).
2. Visites suivantes, le module intercepte la requête avant le démarrage de PrestaShop, vérifie s’il existe une copie en cache, la sert, puis s’arrête. PrestaShop n’est jamais chargé.
3. HTML sans session. La page mise en cache ne peut pas contenir « Bon retour, Jean » ou « 3 articles dans le panier », parce qu’elle a été capturée sans session. Elle est générique par définition.
4. Hydratation JavaScript, une fois le HTML statique chargé, des appels AJAX récupèrent les éléments propres à chaque utilisateur : nombre d’articles dans le panier, état de connexion, devise, produits récemment consultés. Le navigateur les insère ensuite dans la page.

Cette dernière étape résume tout le compromis. Le serveur devient rapide ; le navigateur fait davantage de travail ensuite.

Elle impose aussi la règle la plus importante du cache pleine page dans PrestaShop, celle que les configurations maison cassent en premier : mettre en cache la boutique pour les visiteurs anonymes, mais ne jamais mettre en cache le panier, le tunnel de commande ni les pages de connexion ou de compte connecté. Ces routes sont différentes pour chaque visiteur et chaque session, servez-en une version en cache et vous pouvez montrer à un client le panier, l’adresse ou la commande inachevée de quelqu’un d’autre. Tout module FPC sérieux exclut ces routes par défaut et réinjecte les éléments vivants (nombre d’articles, état de connexion) dans une coque mise en cache. Si vous mettez en place votre propre cache au niveau nginx ou Varnish, la liste d’exclusion des URL panier/commande/connexion n’est pas facultative ; c’est ce qui sépare un gain de vitesse d’un incident.

Les avantages, et ils sont bien réels

Un Time to First Byte quasi instantané

1 à 5 secondes tombent à 20–100 ms. Rien d’autre que vous puissiez installer sur un PrestaShop ne fera bouger l’aiguille aussi fort. Les Core Web Vitals de Google y sont directement sensibles, tout comme votre taux de rebond. Si votre hébergement, votre base de données ou votre pile de modules est le goulot d’étranglement, le FPC contourne le problème au lieu de le résoudre, et pour beaucoup de boutiques, le contourner suffit très bien.

Un vrai filet de sécurité pour les boutiques en difficulté

Nous avons repris des boutiques avec 47 modules actifs, une base de données de 14 Go et aucun développeur sous contrat. Le propriétaire avait besoin d’un site rapide avant le Black Friday. Un week-end de profilage et de refactorisation n’était pas envisageable. Le FPC est mis en production, et la boutique redevient compétitive le lundi. Ce n’est pas un compromis, c’est la bonne décision pour cette boutique, dans ce délai.

Ce que fait vraiment le FPC, c’est masquer ce qui est lent en dessous. Si vous n’avez pas les moyens de corriger la cause profonde tout de suite, la masquer est exactement l’outil qu’il vous faut.

Réduction de la charge serveur

Sur un hébergement mutualisé où vous disposez de 2 processus PHP et d’un quota CPU, chaque requête servie directement depuis le cache est une requête qui ne touche pas PHP. Nous avons vu la même boutique passer d’un effondrement à 30 utilisateurs simultanés à 300 utilisateurs servis sans forcer après activation du FPC, sur le même matériel.

Meilleur classement Google, mais lisez la section suivante

La vitesse de page est un facteur de classement confirmé, et une boutique à 200 ms dépassera une boutique à 4 secondes. Le FPC apporte ce résultat avec un effort minimal. Gardez simplement en tête que « TTFB plus rapide » et « meilleurs Core Web Vitals » ne sont pas la même chose, poursuivez la lecture.

Les limites. Ce qu’il faut savoir

Le problème de l’hydratation de session

C’est le prix visible de tous les modules FPC du marché.

La page mise en cache est rendue sans session. L’icône du panier affiche 0. L’en-tête indique « Se connecter » même lorsque vous êtes connecté. Les produits récemment consultés sont vides. La devise est celle par défaut de la boutique, pas le choix du visiteur. Un battement plus tard, la requête AJAX arrive et le JS corrige la page : le nombre d’articles apparaît, le nom se remplace, la devise change.

Sur une connexion rapide avec un appareil rapide, ce battement est à peine perceptible. Sur un Android milieu de gamme en 4G, ce qui représente une grande partie de votre trafic réel, c’est un scintillement visible. Nous avons observé des enregistrements de sessions dans Microsoft Clarity où des utilisateurs cliquent sur l’icône du panier alors qu’elle affiche encore 0, arrivent sur la page panier vide, puis quittent le site. Les pages mises en cache peuvent provoquer cela.

CLS (Cumulative Layout Shift)

Ces corrections d’hydratation déplacent des éléments. Un lien « Se connecter » est plus étroit que « Bonjour, Jonathan Stevens ». Un compteur panier à 0 représente un caractère ; une valeur hydratée à 3 peut en prendre trois avec un badge. Chaque remplacement décale les éléments voisins.

Vous pouvez gagner sur le LCP grâce au FPC et perdre sur le CLS dans la même proportion. Nous avons vu des boutiques Performance Revolution obtenir des scores Lighthouse dans les 90 pour le LCP et dans les 60 pour le CLS uniquement à cause de décalages d’hydratation. Réservez de l’espace pour les éléments dynamiques dans le HTML mis en cache (badges panier à largeur fixe, emplacements squelettes pour le nom du client), sinon vous verrez vos gains s’évaporer dans le rapport Vitals.

Risque de contenu obsolète

Une page mise en cache est une photographie figée. Modifiez un prix, changez un statut de stock, activez une vente flash, mettez à jour la description d’une catégorie, la copie en cache continue d’afficher la réalité d’hier jusqu’à l’invalidation du cache.

C’est ici que les modules FPC diffèrent vraiment les uns des autres, et il vaut la peine de comprendre les options :

• Invalidation par hooks (ce que fait Performance Revolution, et ce que font la plupart des modules sérieux), écoute actionProductUpdate, actionObjectCartRuleUpdateAfter, actionUpdateQuantity et une douzaine d’autres événements, puis purge uniquement les pages concernées. Rapide, chirurgical et juste dans la plupart des cas.
• Invalidation par TTL uniquement, chaque entrée de cache expire après N minutes. Simple, basique, prévisible. Faux pendant jusqu’à N minutes après toute modification. Acceptable pour des boutiques de contenu, dangereux pour le stock.
• Purge manuelle, l’administrateur clique sur « vider le cache » après les changements. Ne livrez pas cela ; les marchands oublient.

Même l’invalidation par hooks a des angles morts. Les imports ERP qui écrivent directement dans la base de données contournent tous les hooks déclenchés par PrestaShop. Le cache ne sait jamais que le stock a changé. Les règles panier avec conditions complexes touchent des produits auxquels vous ne vous attendiez pas. Les modules tiers qui gèrent leur propre état cassent les hypothèses. Nous traitons ce sujet assez souvent dans les tickets de support pour nous méfier de toute promesse d’« invalidation parfaite ».

Le débogage devient plus étrange

La première question sur toute boutique mise en cache devient « est-ce le cache ? ». Vous vous surprendrez à purger le cache par réflexe au début de chaque investigation de bug, et vous apprendrez à vos dépens que les points de terminaison AJAX ne se comportent pas comme des pages HTML mises en cache, et que les outils de « prévisualisation déconnectée » mentent dès que l’hydratation entre en jeu. Cela vaut le coup, mais il vaut mieux le savoir avant.

Là où chaque backend de stockage peut vous piéger

Retour honnête après avoir exploité les trois en conditions réelles :

• Cache fichier, le plus simple, aucune infrastructure, correct sur une boutique mono-serveur. S’effondre lors d’écritures concurrentes. Pendant une mise à jour produit chargée lors d’un import, vous pouvez vous retrouver en interblocage.
• Redis, notre choix par défaut dans Performance Revolution. Rapide, sans verrouillage de fichiers, fonctionne avec plusieurs processus PHP. Il vous faut une instance Redis (nous faisons tourner un ps-redis partagé sur plus de 20 boutiques, sans souci). Limite mémoire stricte ; réglez votre maxmemory-policy.
• Varnish / FPC par proxy inverse, le plus rapide de tous, car la requête n’atteint jamais PHP. Aussi le plus difficile à invalider proprement (ESI pour les parties dynamiques est une courbe d’apprentissage à part entière), et tous les hébergeurs ne l’autorisent pas. Si votre hébergeur l’a déjà configuré, utilisez-le. Sinon, les modules FPC au niveau PHP vous apporteront 90 % du gain avec 10 % de la douleur opérationnelle.

Une anecdote de terrain mérite d’être racontée, parce que c’est le mode de défaillance dont personne ne vous avertit : le mécanisme de cache lui-même peut devenir la partie lente. Sur mypresta.rocks, nous avons un jour traqué des rendus d’environ 2,2 secondes qui n’avaient rien à voir avec la base de données, notre propre pipeline de ressources calculait une empreinte sha1 de 670 bundles CSS/JS combinés à chaque page, simplement pour décider lequel servir. Le code de « performance » était le point chaud. Nous l’avons corrigé, associé du CSS critique inline à un préchauffeur de cache sur nos 6 625 URL de boutique, et c’est ainsi que le site atteint aujourd’hui PSI 93 sur mobile. La leçon pour le FPC en particulier : lorsque vous mesurez après avoir activé un cache et que la page reste lente, profilez la couche de cache avant d’accuser ce qui se trouve en aval, un cache qui calcule des empreintes, verrouille ou sérialise trop de choses sur le chemin critique rend exactement ce qu’il était censé économiser.

Aller plus loin : corriger les causes profondes

Tout ce qui précède correspond à ce que le FPC masque. Si vous avez le budget et le temps, corriger la lenteur sous-jacente vous donne la même vitesse sans les sauts d’hydratation, sans l’inquiétude du contenu obsolète et sans la taxe de débogage.

Il n’est pas nécessaire d’en faire un immense projet. Nous avons vu des boutiques passer d’un TTFB de 4 secondes à 300 ms en six mois de corrections incrémentales, un élément par semaine. Traitez cela comme un backlog, pas comme un sprint.

Un vrai avertissement : ne laissez pas un projet d’optimisation à moitié terminé. Une boutique en production avec un CCC cassé, un MySQL à moitié réglé et une instance Redis qui plante tous les dimanches est pire que la même boutique avec un FPC bien configuré et rien d’autre. Fait vaut mieux que parfait.

1. Identifier les modules lents

C’est la cause numéro un que nous constatons, et de loin. Un seul module qui exécute une requête non indexée dans displayHeader ajoute 500 ms à chaque page. Un module de statistiques qui journalise chaque vue de façon synchrone en base de données ajoute 200 ms. Empilez-en trois et votre boutique atteint 3 secondes avant même tout travail de rendu.

Comment les trouver :

• Activez le profiler de débogage de PrestaShop (_PS_DEBUG_PROFILING_ dans config/defines.inc.php). Il affiche en bas de page le temps passé par hook et par module. Lisez-le.
• Sur PrestaShop 8+, la barre d’outils Symfony vous donne le nombre de requêtes et leurs temps par requête HTTP. Tout ce qui dépasse 100 requêtes SQL sur une page produit est suspect.
• Désactivez les modules un par un, appelez la page avec curl, mesurez le TTFB. L’écart avant/après correspond exactement au coût de chaque module.

Récidivistes fréquents : flux sociaux qui récupèrent des données API en direct, compteurs de vues qui font un INSERT à chaque requête, modules de « produits associés » qui exécutent une similarité cosinus en PHP, modules SEO qui régénèrent les métadonnées à chaque chargement de page au lieu de les mettre en cache.

2. Corriger la compilation des templates Smarty

Smarty compile les fichiers .tpl en PHP. En production, cela devrait se produire une fois par template, puis plus jamais.

• force_compile = off. S’il est activé, chaque template est recompilé à chaque requête, soit 200 à 500 ms de CPU gaspillé par page.
• caching = on.
• Après les déploiements, videz une fois le cache de compilation. Ne laissez pas force_compile activé comme solution « temporaire ».

Le nombre de boutiques que nous avons reprises où quelqu’un avait laissé force_compile activé six mois plus tôt après une session de débogage est déprimant. Vérifiez la vôtre.

3. Configuration MySQL

La configuration MySQL par défaut vise un serveur générique, pas votre PrestaShop. Les réglages qui comptent :

• innodb_buffer_pool_size, celui qui compte réellement. 50 à 70 % de la RAM disponible. Une base de 2 Go avec un buffer pool de 128 Mo tape constamment sur le disque.
• innodb_log_file_size, au moins 256 Mo sur les boutiques à forte écriture.
• slow_query_log = 1 avec long_query_time = 1, activez-le pendant une semaine, lisez le journal, vous trouverez les requêtes à éliminer.
• Nettoyez ps_connections, ps_log, ps_mail. Ces tables atteignent des millions de lignes sur les boutiques anciennes et ralentissent chaque SELECT qui les joint.
• Ajoutez les index manquants sur les tables de vos modules personnalisés. Ils manquent probablement.

4. Utiliser Redis pour le cache et les sessions

Le cache fichier par défaut de PrestaShop utilise en interne le verrouillage du système de fichiers, ce qui sérialise les requêtes concurrentes. Passez à Redis et trois éléments passent en RAM :

• Cache Smarty, la sortie des templates passe de lectures disque à des lectures mémoire.
• Cache Symfony (PrestaShop 8+), routes, conteneurs, annotations.
• Sessions PHP, le problème de verrouillage de fichiers qui met les requêtes en file d’attente sous charge disparaît.

Une instance Redis de 256 Mo gère les trois pour la plupart des boutiques. L’amélioration est maximale sous charge concurrente, minimale sur une boutique de développement avec un seul visiteur, mesurez là où cela compte.

5. Réglage de PHP et d’OPcache

• PHP 8.1+, 20 à 40 % plus rapide que 7.4. Si vous êtes encore en 7.4, c’est le gain de performance le moins cher que vous puissiez obtenir.
• OPcache, doit être activé. Définissez opcache.validate_timestamps=0 en production et réinitialisez-le manuellement après les déploiements. Nous nous sommes assez souvent trompés avec la réinitialisation distante façon cPanel pour l’avoir documentée, consultez nos notes sur OPcache pour les pièges.
• Cache realpath, augmentez realpath_cache_size à 4096K. PrestaShop ouvre des centaines de fichiers par requête et paie sinon le coût de stat() sur chacun.

6. Optimisation front-end

• CCC (Concaténation, compression, cache), regroupe CSS et JS, réduit les requêtes HTTP. Intégré à PrestaShop. Activez-le, puis surveillez les modules qui livrent du CSS cassé et brisent le bundle combiné.
• CSS critique, intégrez inline les styles au-dessus de la ligne de flottaison, différez le reste. Élimine le CSS bloquant le rendu. Nous l’automatisons dans Performance Revolution avec Critters, car le faire à la main template par template est un cauchemar.
• Différer JavaScript, outils d’analyse, widgets de chat et intégrations sociales passent derrière defer ou requestIdleCallback. Ils n’ont pas besoin de bloquer votre LCP.
• Optimisation des images, WebP/AVIF (25 à 50 % plus légers que JPEG), srcset responsive, width/height explicites sur chaque <img> pour éviter le CLS.
• CDN, met en cache les ressources statiques en périphérie. Complémentaire au cache côté serveur, pas un remplacement.

L’effet combiné

Ces optimisations s’additionnent. Supprimer les modules lents économise 500 ms à 2 s. Régler MySQL économise 100 à 300 ms. Redis économise 50 à 200 ms. PHP 8 + OPcache économise 100 à 300 ms. Le CSS critique améliore la charge perçue de 500 ms à 1 s. Une boutique à 4 secondes peut passer de façon réaliste sous les 200 ms en rendant chaque requête à neuf, stock à jour, panier à jour, pas d’hydratation, pas de contenu obsolète.

Cela demande du temps et de l’expertise. Si vous n’avez ni l’un ni l’autre pour l’instant, un module FPC correctement configuré est la meilleure réponse.

Conclusion

Les modules de cache pleine page fonctionnent. Ils servent du HTML statique et réinjectent les éléments de session avec JavaScript, ce qui vous coûte des sauts d’hydratation visibles, un peu de CLS et une expérience de débogage légèrement plus complexe. En échange, vous obtenez le plus grand gain de performance individuel disponible dans PrestaShop sans toucher au reste.

Pour les boutiques qui ont besoin de vitesse aujourd’hui et ne peuvent pas financer un projet d’optimisation profond, cet échange est le bon. Pour celles qui ont les ressources nécessaires pour corriger les modules lents, régler la base de données, installer Redis et livrer du CSS critique, le FPC ne fait rien que vous ne puissiez dépasser avec une pile plus saine en dessous.

La trajectoire pragmatique suivie par la plupart de nos clients : installer maintenant un bon module FPC, garder le travail de fond sur la feuille de route, puis traiter les éléments au fil du temps. À terme, vous pourrez retirer le cache, ou le conserver comme deuxième ligne de défense. Dans les deux cas, votre boutique finit rapide, et vous y arrivez sans la casser en chemin.

Questions fréquentes

Un cache pleine page va-t-il casser mon panier ou mon tunnel de commande ?

Pas s’il est correctement conçu, et c’est la ligne qui sépare un vrai module FPC d’un module dangereux. Les pages panier, tunnel de commande, connexion et compte connecté doivent être entièrement exclues du cache et rendues en direct pour chaque visiteur ; seules les pages anonymes de la boutique (accueil, catégorie, produit, CMS) sont mises en cache. Un module correctement configuré le fait par défaut. Le risque se trouve dans les règles nginx/Varnish bricolées à la main qui oublient d’exclure ces routes, c’est ainsi qu’un acheteur se retrouve à voir le panier d’un autre client.

Pourquoi mon panier affiche-t-il 0 pendant une seconde après le chargement de la page ?

C’est l’étape d’hydratation, et elle est inhérente à chaque module FPC, pas le bug de l’un d’eux. Le HTML mis en cache est sans session, il arrive donc avec l’état par défaut de la boutique, panier vide, « Se connecter », puis un appel AJAX de suivi réinjecte le vrai nombre d’articles, le nom et la devise. Sur les appareils rapides, c’est imperceptible ; sur un Android milieu de gamme en 4G, c’est un scintillement visible. Réservez une largeur fixe pour le badge panier et le nom du client dans le balisage mis en cache afin que le remplacement ne vous coûte pas aussi du Cumulative Layout Shift.

J’ai changé un prix mais l’ancien s’affiche encore. Le cache est-il cassé ?

En général, il s’agit d’un retard d’invalidation, pas d’une panne. Les modules basés sur les hooks écoutent des événements comme actionProductUpdate et purgent les pages concernées, mais certaines modifications contournent complètement les hooks, les imports ERP qui écrivent directement dans la base de données, par exemple, ne déclenchent aucun hook, si bien que le cache n’apprend jamais que le prix a changé. Si vous modifiez depuis le back office, la purge devrait se faire ; si vous importez ou écrivez directement du SQL, purgez le cache manuellement ou déclenchez un nouveau préchauffage. Aucune « invalidation parfaite » ne survit à une écriture directe en base.

Dois-je utiliser le cache fichier, Redis ou Varnish ?

Le cache fichier convient à une boutique mono-serveur avec une concurrence légère, mais il bloque lors d’écritures concurrentes pendant les imports. Redis est notre choix par défaut, pas de verrouillage de fichiers, fonctionnement avec plusieurs workers PHP, une instance d’environ 256 Mo suffit, il faut seulement régler maxmemory-policy. Varnish est le plus rapide parce que la requête n’atteint jamais PHP, mais c’est aussi le plus difficile à invalider proprement, et tous les hébergeurs ne l’autorisent pas. Si votre hébergeur exécute déjà Varnish, utilisez-le ; sinon, un module au niveau PHP sur Redis vous apporte l’essentiel du gain avec beaucoup moins de complexité opérationnelle.

Si je corrige la lenteur sous-jacente, puis-je supprimer le cache ?

Oui, c’est l’aboutissement honnête. Une fois les modules lents corrigés, la base de données réglée, Redis chargé des sessions et du cache, et le CSS critique livré, une boutique peut rendre les pages à neuf en quelques centaines de millisecondes, sans sauts d’hydratation et sans risque de contenu obsolète. À ce stade, le FPC devient optionnel ; beaucoup le gardent comme deuxième ligne de défense contre les pics de trafic. Le FPC masque rapidement le problème aujourd’hui ; corriger les causes profondes vous permet d’arrêter de masquer.

À lire aussi

• Performance Revolution, notre approche du FPC pour PrestaShop avec CSS critique, CCC et optimisation des images dans un seul module
• Redis Cache Manager & Monitor, configuration Redis prête à l’emploi pour le cache et les sessions de PrestaShop
• Optimisation des performances des requêtes de base de données PrestaShop. Ce qu’il faut corriger lorsque vous décidez d’aller plus loin que le FPC