Le cache garde une copie du travail déjà fait pour la ressortir instantanément au visiteur suivant. Sur une boutique, c'est l'un des leviers les plus efficaces pour accélérer les pages et tenir un pic de trafic. Mais le cache PrestaShop n'est pas un bouton unique : plusieurs caches travaillent à des étages différents, chacun avec ses forces et ses limites.
Une image aide à comprendre. Un restaurant qui cuisinerait chaque plat de zéro à chaque commande serait vite débordé un samedi soir. Il prépare donc à l'avance ce qui est le plus demandé. Le cache fait la même chose pour votre boutique : il prépare à l'avance ce que les visiteurs demandent le plus souvent.
En bref :
- Le cache évite au serveur de refaire un travail qu'il a déjà fait : la page s'affiche plus vite et le serveur tient plus de visiteurs.
- Il existe plusieurs caches (navigateur, CDN, cache HTTP comme Varnish, cache applicatif, cache SQL) qui se complètent sans se remplacer.
- Tout ne se met pas en cache : un panier ou un compte client est propre à chaque visiteur.
- Un cache se mesure : un cache activé n'est pas une preuve de performance.
Pourquoi une boutique en ligne doit-elle fabriquer ses pages ?
Une fiche produit n'est pas un fichier tout prêt qui attend d'être envoyé. À chaque visite, PrestaShop la fabrique :
- il récupère le produit, son prix et son stock ;
- il interroge la base de données, où sont rangées toutes les informations de la boutique ;
- il applique vos règles de vente : promotions, prix par groupe de clients, transporteurs ;
- il fait travailler les modules installés (avis, recommandations, paiement…) ;
- il assemble le tout en une page lisible par le navigateur.
Avec peu de visiteurs, ce travail passe inaperçu. Quand des centaines de personnes arrivent en même temps, le serveur doit le répéter des centaines de fois : les demandes s'accumulent, la base de données sature et les pages ralentissent.
Le cache pose une question simple : faut-il vraiment refaire tout ce travail pour chaque visiteur ?
Comment fonctionne un cache ?
Prenons une fiche produit consultée par plusieurs centaines de visiteurs. Sans cache, le serveur la fabrique autant de fois qu'elle est demandée. Avec un cache, il la fabrique une fois, en garde une copie, puis sert cette copie aux visiteurs suivants, tant qu'elle est valable et identique pour tout le monde.
Deux situations se présentent :
- Cache hit : la copie existe, elle est servie immédiatement.
- Cache miss : la copie n'existe pas, a expiré ou ne peut pas être réutilisée. Le serveur fait le travail complet, puis garde éventuellement une copie pour la suite.
Activer un cache ne veut donc pas dire que toutes les pages viendront du cache. Certaines pages ne s'y prêtent pas, d'autres sont personnalisées, et une copie peut avoir été effacée parce que le produit a changé.
Un cache vide doit aussi être rempli avant d'être utile. C'est le préchauffage (warm-up) : on fait visiter les pages importantes avant l'arrivée du public, pour que les premiers visiteurs d'un pic tombent sur des copies déjà prêtes.
Les différents types de cache PrestaShop
Les caches ne travaillent pas au même étage. Chacun évite un travail différent :
| Type de cache | Ce qu'il garde en copie | Ce qu'on n'a plus à refaire |
|---|---|---|
| Cache navigateur | Les images, styles et scripts, sur l'appareil du visiteur | Le visiteur ne les retélécharge pas à chaque page |
| CDN | Les fichiers du site, parfois des pages, sur des serveurs proches du visiteur | Les demandes n'ont plus à aller jusqu'au serveur de la boutique |
| Cache HTTP (Varnish) | Des pages entières, identiques pour tous les visiteurs | PrestaShop n'a pas à fabriquer la page à nouveau |
| Cache applicatif | Des résultats de calcul utilisés par plusieurs pages | PrestaShop ne refait pas les mêmes calculs |
| Cache SQL | Les réponses de la base de données aux questions fréquentes | La base ne répond pas deux fois à la même question |
Le cache navigateur : ne pas retélécharger ce qu'on a déjà
Le navigateur du visiteur garde sur son appareil les images, les styles et les scripts de la boutique. À la page suivante, ou à sa prochaine visite, il les réutilise au lieu de les télécharger à nouveau.
Pour le visiteur, la navigation est plus fluide. En revanche, ce cache ne fait rien pour une page que le serveur met longtemps à fabriquer.
Le cache applicatif : ne pas refaire les mêmes calculs
PrestaShop peut garder en mémoire certains résultats de calcul utilisés par plusieurs pages, au lieu de les recalculer à chaque visite.
Le gain dépend de ce qui est gardé et du nombre de fois où c'est réutilisé. Un cache mal tenu à jour peut même servir une information périmée.
Le cache SQL : ne pas reposer la même question à la base
Pour fabriquer une page, PrestaShop pose de nombreuses questions à la base de données : quel est ce produit, dans quelle catégorie, à quel prix… Beaucoup reviennent sans cesse, alors que la réponse ne change pas d'une minute à l'autre.
Le cache SQL mémorise les réponses de la base de données aux questions qu'on lui pose sans cesse. La base est moins sollicitée, et elle tient mieux quand le trafic monte. C'est le rôle du module Scalizy Database Cache, le cache SQL pour PrestaShop.
Il ne faut pas le confondre avec un cache HTTP. Le cache SQL évite des questions à la base, mais PrestaShop fabrique toujours la page. Le cache HTTP, lui, évite de fabriquer la page entière. Le cache SQL est donc précieux surtout pour les pages qui ne peuvent pas être servies en copie : le panier, la commande, le compte client.
Il ne remplace pas non plus la correction d'une requête mal écrite ou d'une base mal organisée : il rend une question fréquente moins coûteuse, il ne rend pas une question lente rapide.
Enfin, la base de données ne garde pas toute seule ses réponses en cache. Son ancien cache intégré, le Query Cache, a été supprimé dans MySQL 8.0 ; MariaDB le propose encore, mais il est désactivé par défaut dans ses versions récentes. Il faut donc savoir quel cache est réellement en place et comment il est réglé.
Le cache HTTP et Varnish : servir une page déjà prête
Le cache HTTP garde une copie de la page entière. Varnish, un logiciel de cache HTTP très répandu, s'en charge : placé devant PrestaShop, il renvoie la page déjà prête sans que PrestaShop ait à la fabriquer.
C'est le levier le plus puissant pour les pages publiques, celles qui sont identiques pour tous les visiteurs : catégories, fiches produit, pages de contenu. Le module Scalizy HTTP Cache met en place ce cache de pages sur PrestaShop.
Le panier, lui, est propre à chaque visiteur : il ne peut pas être servi en copie comme une page publique. Le taux de réussite du cache (le taux de « hit ») se lit donc toujours sur les pages qui peuvent être mises en cache, pas sur l'ensemble du site.
Le CDN : rapprocher les fichiers du visiteur
Un CDN (Content Delivery Network) est un réseau de serveurs relais répartis dans le monde. Il sert les images, les styles et les scripts depuis un serveur proche du visiteur, sans passer par le serveur de la boutique.
Selon son réglage, un CDN peut aussi garder des pages entières. Il fait alors en partie le même travail que Varnish, mais les deux ne sont pas interchangeables sans réglage. Et un CDN ne rend pas plus rapide une page que PrestaShop doit fabriquer à chaque visite.
Cache HTTP ou cache SQL : lequel choisir ?
Le bon choix part du travail que l'on veut éviter. Imaginons une fiche produit demandée plusieurs fois par seconde :
- avec un cache SQL, une partie des questions à la base est évitée, mais PrestaShop fabrique toujours la page ;
- avec un cache HTTP, la page déjà prête est renvoyée telle quelle : ni PrestaShop ni la base ne travaillent.
Les deux se complètent. Le cache HTTP sert les pages identiques pour tous, le cache SQL allège les pages qui doivent être fabriquées pour chaque visiteur, et l'optimisation du code traite ce qu'aucun cache ne peut éviter.
Le but n'est pas d'empiler les caches, mais d'éviter le travail le plus coûteux, sans jamais afficher un prix, un stock ou un panier faux.
Le cas de la belle-iloise : un pic de trafic ×50 sans erreur
Le 22 octobre 2026, après son passage au journal de 20 h de France 2, la boutique PrestaShop de la belle-iloise est passée d'environ 130 à 6 168 requêtes par minute, soit un trafic multiplié par 50. Résultat : aucune erreur serveur, et pour 95 % des pages fabriquées par PrestaShop, un temps de réponse resté sous 0,38 seconde au plus fort du pic.
Ce résultat ne tient pas à un seul cache. Varnish a servi 75 % des pages pouvant être mises en cache au plus fort du pic, en 1 milliseconde environ, contre 0,16 à 0,24 seconde pour une page fabriquée par PrestaShop. Le cache SQL, préchauffé avant la diffusion, a allégé la base pour les pages que PrestaShop devait encore fabriquer. Le serveur a enfin été dimensionné pour fabriquer en parallèle beaucoup plus de pages (480 au lieu de 60), pour les requêtes que le cache ne peut pas servir.
Chiffres, préparation et rôle de chaque équipe : lisez le récit complet dans comment la belle-iloise a absorbé un pic de trafic ×50 sur PrestaShop.
Pourquoi le cache ne règle-t-il pas tout ?
Un cache bien réglé allège énormément le serveur. Il ne rend pas pour autant tout rapide.
Toutes les pages ne se partagent pas
Un panier, un compte client ou une liste d'envies sont propres à chaque visiteur. Servir à quelqu'un la page d'un autre serait une erreur grave. Ces pages suivent donc des règles à part, et le cache HTTP ne peut pas les servir en copie.
Une copie peut devenir périmée
Un prix, un stock ou une promotion changent. Si la copie n'est pas effacée ou renouvelée au bon moment, la boutique affiche une information dépassée. La durée de vie d'une copie doit donc suivre le rythme de mise à jour de vos données.
Un cache peut cacher une lenteur
Une page peut sembler rapide uniquement parce qu'elle sort souvent du cache. Le jour où le cache est vidé, après une mise à jour, un redémarrage ou un changement de réglage, la lenteur revient d'un coup, parfois au pire moment.
Les pages hors cache comptent aussi
Même avec un excellent taux de cache sur les pages publiques, le panier, la commande et les appels à des services extérieurs continuent de solliciter le serveur. La performance se juge sur tout le parcours d'achat, pas seulement sur le taux de cache.
Comment savoir si le cache améliore vraiment votre boutique ?
Un cache activé n'est pas une preuve de performance. Il faut mesurer son effet sur la rapidité des pages et sur la charge du serveur. Voici les indicateurs à suivre :
| Indicateur | Ce qu'il vous dit |
|---|---|
| Taux de cache hit | La part des pages éligibles servies depuis le cache |
| TTFB (Time to First Byte) | Le temps d'attente avant que la page commence à arriver |
| Temps de génération | Le temps que met PrestaShop à fabriquer une page |
| Requêtes SQL | Le nombre et la durée des questions posées à la base |
| Processeur et mémoire du serveur | La marge restante pour accueillir plus de visiteurs |
| Temps de réponse au 95e percentile | Le temps sous lequel restent 95 % des pages : il montre les lenteurs qu'une moyenne cache |
Le TTFB, c'est le temps d'attente avant que la page commence à s'afficher. S'il est bon, ce n'est pas une preuve que tout va bien derrière : une page servie par le cache peut avoir un excellent TTFB alors que sa fabrication par PrestaShop reste lente.
De même, une moyenne correcte peut masquer quelques pages très lentes. C'est l'intérêt du 95e percentile : si 95 % des pages répondent en moins de 0,4 seconde, vous savez que presque tous vos visiteurs ont une page rapide.
Une méthode en quatre étapes
- Repérer les pages lentes. Séparez les fiches produit, les catégories, le panier, le compte client et les autres parcours : ils n'ont pas les mêmes contraintes.
- Vérifier le cache. Mesurez les hits et les misses sur les pages éligibles, et cherchez ce qui empêche une page d'être mise en cache (un cookie, un paramètre dans l'adresse, une règle trop stricte).
- Regarder le travail qui reste au serveur. Pour les pages que PrestaShop fabrique, regardez le temps de génération, les modules qui travaillent, les requêtes SQL lentes et les appels à des services extérieurs.
- Comparer avant et après. Mesurez les mêmes indicateurs sur des périodes comparables. Un meilleur taux de cache ne vaut que s'il rend vraiment le site plus rapide et plus stable.
Comment Scalizy aide à choisir le bon levier
Sur une boutique PrestaShop, la lenteur que voit le visiteur ne dit pas d'où elle vient. Une page lente peut venir d'une requête SQL, d'un module, d'un appel à un service extérieur ou d'un serveur trop juste. Ajouter un cache sans connaître la cause peut accélérer certaines pages et laisser les autres aussi lentes qu'avant.
Scalizy analyse les performances de votre boutique PrestaShop page par page : temps de fabrication, modules, requêtes SQL et opérations coûteuses. Vous savez alors dans quel cas vous êtes :
- une page publique qui pourrait être servie par un cache HTTP ;
- des questions répétées à la base qu'un cache SQL peut alléger ;
- une requête ou un module qui reste lent même avec un cache ;
- un serveur trop juste pour les pages qui doivent être fabriquées à chaque visite.
Vous corrigez d'abord ce qui pèse vraiment, au lieu d'appliquer la même recette à toutes les boutiques. Un pic se prépare ainsi : à l'approche du Black Friday sur PrestaShop, cette mesure vous dit où agir en premier.
Vous voulez savoir ce qui ralentit votre boutique PrestaShop ? Analysez ses performances avec Scalizy pour repérer les pages, les modules et les requêtes en cause, et choisir le cache qui vous fera vraiment gagner du temps.
Conclusion
Le cache est l'un des leviers les plus efficaces pour accélérer une boutique, mais il n'est pas une solution unique. Chaque cache évite un travail différent, et c'est leur combinaison, avec un serveur bien dimensionné et une mesure régulière, qui fait tenir une boutique les jours de forte affluence.
La bonne démarche tient en trois temps : mesurer, comprendre le travail que fait vraiment le serveur, puis choisir le cache qui l'évite sans jamais afficher une information fausse à vos clients.
Questions fréquentes sur le cache PrestaShop
Qu'est-ce que le cache d'un site web ?
Le cache garde une copie de données, de calculs ou de pages déjà produits pour les réutiliser. Le serveur évite de refaire le même travail : les pages s'affichent plus vite et le site accueille plus de visiteurs en même temps.
Quelle est la différence entre cache HTTP et cache SQL ?
Le cache HTTP renvoie une page entière déjà prête, quand elle est identique pour tous les visiteurs : PrestaShop n'a pas à la fabriquer. Le cache SQL garde les réponses de la base de données aux questions fréquentes : PrestaShop fabrique toujours la page, mais plus vite.
Varnish est-il utile sur PrestaShop ?
Oui, pour les pages publiques identiques pour tous les visiteurs : catégories, fiches produit, pages de contenu. Son efficacité dépend de ses réglages et de la part des pages qui peuvent être mises en cache. Le panier et le compte client demandent un traitement à part.
Faut-il mettre toutes les pages d'une boutique en cache ?
Non. Un panier, un compte client ou une commande sont propres à chaque visiteur : les servir en copie montrerait à un client les informations d'un autre. Les règles de cache doivent protéger la confidentialité et l'exactitude des prix et des stocks.
Un cache peut-il masquer un problème de performance ?
Oui. Une page souvent servie depuis le cache peut sembler rapide alors que sa fabrication par PrestaShop est lente. Le jour où le cache est vidé, la lenteur revient. Il faut donc aussi mesurer les pages que PrestaShop fabrique réellement.
Comment mesurer l'efficacité du cache ?
Suivez le taux de cache hit sur les pages éligibles, le temps de réponse au 95e percentile, le TTFB, le temps de fabrication des pages, les requêtes SQL et la charge du serveur. Comparez sur des périodes et des niveaux de trafic comparables.
Faut-il vider le cache régulièrement ?
Non, pas par habitude. On vide le cache pour une raison précise : un prix ou un contenu qui change, un nouveau réglage. Le vider trop souvent supprime ses bénéfices et fait remonter la charge du serveur le temps qu'il se remplisse à nouveau.
Comment choisir le bon cache pour une boutique PrestaShop ?
Partez de la cause de la lenteur. Une page publique fabriquée inutilement à chaque visite relève du cache HTTP. Des questions répétées à la base relèvent du cache SQL. Un module ou un traitement lent doit être corrigé : aucun cache ne le rendra rapide.