Serveur et cache PrestaShop : régler l’hébergement pour tenir la charge

Quatre réglages de cache sont à distinguer sur une boutique PrestaShop : le code PHP compilé, la mémoire de la base, les modèles de pages Smarty et le cache applicatif. L’hébergeur règle les deux premiers, la boutique le troisième, et le quatrième se règle des deux côtés. Le choix et le dimensionnement de la machine se lisent dans hébergement et infogérance ; cette page règle ce qui tourne dessus.

• Quatre réglages de cache PrestaShop à distinguer : deux chez l’hébergeur, un à la boutique, un aux deux
• Le cache de code PHP s’aligne sur des valeurs d’exemple de la documentation PrestaShop
• Les directives de cache de requêtes de la documentation visent MySQL avant la 8.0
• Le bloc de performances du back-office règle Smarty et le cache applicatif
• Le CCC et les serveurs de médias allègent les fichiers, avec leurs propres risques
• Un test de charge chiffre la tenue de la boutique avant les soldes
• La mission de réglage du serveur et du cache se livre avec une mesure sous charge
• Sources consultées
• Foire aux questions

Quatre réglages de cache PrestaShop à distinguer : deux chez l’hébergeur, un à la boutique, un aux deux

• OPcache, côté serveur : garde en mémoire partagée le code PHP déjà compilé. Il se règle dans la configuration de PHP, que tient l’hébergeur.
• La mémoire de la base, côté serveur : garde les données lues souvent. Elle se règle dans la configuration de MySQL ou de MariaDB, chez l’hébergeur aussi.
• Smarty, côté boutique : garde les modèles de pages compilés. Son réglage se trouve dans Paramètres avancés > Performances (« Advanced Parameters > Performance » dans la documentation).
• Le cache applicatif, à cheval : la boutique l’active au même endroit, mais l’extension PHP qu’il exige s’installe sur le serveur.

Le cache de code PHP s’aligne sur des valeurs d’exemple de la documentation PrestaShop

Deux lignes demandent de la lecture.

La directive « fast_shutdown » n’existe plus depuis PHP 7.2.0, et PrestaShop 8 accepte PHP 7.2 à 8.1 : la recopier ne change rien.

Avec « validate_timestamps » à 0, PHP ne regarde plus si un fichier a changé. Après l’installation ou la mise à jour d’un module, le serveur sert l’ancien code, jusqu’à une remise à zéro d’OPcache ou un redémarrage du serveur web. La même page prescrit une carte de classes figée, par la commande composer dump-autoload (Composer, gestionnaire de dépendances) et son option « classmap-authoritative ». Elle demande de la relancer après l’installation d’un module en production. Faites écrire qui relance quoi, et quand.

Les directives de cache de requêtes de la documentation visent MySQL avant la 8.0

MySQL 8.0 a retiré le cache de requêtes. Les variables « query_cache_limit », « query_cache_size » et « query_cache_type », que la même page liste dans son bloc MySQL, n’existent plus dans cette version. MariaDB, de son côté, déconseille d’activer son cache de requêtes sur du matériel actuel.

La même page conseille de laisser le cache applicatif éteint quand MySQL (avant la version 8) ou MariaDB tourne sur la même machine, car le cache de requêtes y est plus efficace. Les deux documentations divergent sur MariaDB : la mesure sur votre serveur tranche, version de base à l’appui.

Le bloc de performances du back-office règle Smarty et le cache applicatif

D’après le code de PrestaShop, le bloc Smarty compte cinq réglages en 1.7.8 et quatre de la 8.0 à la 9.2 ; le cache applicatif propose trois moteurs. Les valeurs de départ viennent du code d’installation de PrestaShop (1.7.8 à 9.2), recoupé avec les spécifications du back-office 1.7. Une seule diverge, la compilation : la spécification marque « Ne jamais recompiler les fichiers de templates » (« Never recompile template files »). Le code pose « Recompiler les fichiers de templates s’ils ont été mis à jour » (« Recompile templates if the files have been updated »). Lisez la valeur sur votre écran : « Ne jamais recompiler » sert la page compilée même si le thème a changé. « Forcer la compilation à chaque appel » se réserve à l’édition d’un thème. L’option « Cache » est activée au départ et ne se coupe que pour déboguer.

Le type de mise en cache ne se règle à l’écran qu’en 1.7 : gardez le stockage par fichiers (« File System » dans la page d’optimisation), qui écarte « MySQL ». La « Synchronisation multi-serveurs » (« Multi-front optimizations ») reste à « Non » avec un seul serveur frontal (celui qui répond aux visiteurs) ; elle évite de stocker le cache Smarty sur un partage réseau.

Le dernier bloc de la page (« Caching » dans la documentation de la version 8) propose Memcached, APC ou Xcache, à condition que l’extension PHP correspondante (PECL, dépôt d’extensions PHP) existe sur le serveur. Xcache fonctionne avec le serveur Lighttpd seulement. Pour un serveur frontal unique, la page d’optimisation conseille APC, au-delà un serveur Memcached central. La page PECL du paquet APC le dit non maintenu (dernière version en 2012) et remplacé par APCu ; le code de PrestaShop accepte les deux.

Décrire mon besoin →

Le CCC et les serveurs de médias allègent les fichiers, avec leurs propres risques

Le CCC (concaténation, compression et mise en cache) fusionne les fichiers CSS et JavaScript. Les feuilles de style se combinent sans risque d’après la documentation de la version 8 ; le JavaScript peut poser problème et se teste avant d’être gardé. Selon l’aide affichée à l’écran (code de PrestaShop 8.1), l’option « Optimisation Apache » (« Apache optimization ») ajoute des directives au fichier .htaccess (configuration d’Apache par dossier). Sous nginx (serveur web), la compression et la durée de cache des fichiers statiques s’écrivent dans la configuration du serveur, d’après la page nginx de la documentation de la version 9.

Un serveur de médias déporte les dossiers /img, /themes et /modules vers un autre domaine ou un CDN (réseau de diffusion de contenu). Selon la documentation de la version 8, y saisir le domaine de la boutique n’est pas la bonne méthode ; ces dossiers doivent rester synchronisés.

Un test de charge chiffre la tenue de la boutique avant les soldes

Siege, un logiciel de test de charge, simule des visiteurs simultanés sur une liste d’adresses, le fichier « url.txt » de la page « Front-Office Benchmark ». Un premier passage à un utilisateur chauffe les caches : « siege -b -i -c 1 -t 20S --no-parser -f url.txt ». L’option « c » monte ensuite par paliers le nombre de visiteurs simultanés, jusqu’à la chute des performances.

Six mesures se lisent : transactions, disponibilité (« Availability », liée aux pages en échec), temps de réponse moyen, débit en pages par seconde (« Transaction rate »), concurrence obtenue et transactions échouées, comme les erreurs 404 ou 503. La page « How to benchmark » demande de couper le mode de débogage ; par prudence, jouez le test sur une copie, hors des heures de vente. Une erreur 503 qui apparaît à un palier situe la limite ; chaque réglage se rejoue ensuite.

La mission de réglage du serveur et du cache se livre avec une mesure sous charge

Exigez les fichiers de configuration et la mesure sous la même charge, avant et après. Exigez aussi la règle de purge : qui vide le cache, à quel événement (changement de prix, de stock ou de thème). Demandez enfin la liste de ce qui reste chez l’hébergeur et la marche à suivre pour revenir en arrière.

Le devis varie avec le nombre de serveurs frontaux, les réglages que l’offre d’hébergement laisse à la main et le calendrier de vos temps forts. Faites écrire qui paie la remise en état quand un cache sert un prix périmé.

Sur une boutique en 1.7.8 ou en 8, PHP plafonne à 7.4 ou à 8.1 (fin de vie le 28 novembre 2022 et le 31 décembre 2025, selon php.net) : ces réglages valent sur un PHP sans correctif. Le changement de version est une autre mission, la montée de version de PHP.

Écrivez dans le message du formulaire le type d’hébergement, le réglage de « Cache » et la date du dernier ralentissement.

Décrire mon besoin →

Sources consultées

• PrestaShop, documentation développeur de PrestaShop 9, « Optimize your PrestaShop performance », « Scale » (dont « Nginx »), « How to benchmark your PrestaShop » et « Front-Office Benchmark », consulté le 14 octobre 2026.
• PrestaShop, code source (GitHub), versions 1.7.8.11 à 9.2.0, consulté le 14 octobre 2026.
• PrestaShop, documentation développeur, « System requirements » (versions 1.7 et 8), consulté le 14 octobre 2026.
• PrestaShop, documentation utilisateur de la version 8, « Performance », et spécifications du back-office 1.7, « View performance », consulté le 14 octobre 2026.
• PrestaShop, documentation utilisateur de la version 1.7 en français, « Paramètres de performances », consulté le 14 octobre 2026.
• PHP, « OPcache Runtime Configuration », manuel php.net, et « Unsupported Branches », php.net, consulté le 14 octobre 2026.
• PECL, paquet APC, consulté le 14 octobre 2026.
• Oracle, « MySQL 8.0 Reference Manual », « Features Removed in MySQL 8.0 », consulté le 14 octobre 2026.
• MariaDB, « Query Cache », consulté le 14 octobre 2026.

Foire aux questions

Faut-il vider le cache après chaque modification de la boutique ?

Le réglage de départ vide le cache à chaque modification, l’autre choix étant de ne jamais le vider. Pour une boutique dont les prix changent chaque jour, gardez le départ. Un bouton « Vider le cache » (« Clear cache ») en haut de la page Performances le supprime en un clic après une retouche de thème.

Peut-on activer le cache applicatif sur un hébergement mutualisé ?

Seulement si l’hébergeur a installé l’extension PECL correspondante : Memcached, ou APC ou son remplaçant APCu. La documentation de la version 8 conseille, le plus souvent, de consulter d’abord l’hébergeur.

Un CDN remplace-t-il les caches de la boutique ?

Non : un CDN conserve des fichiers statiques (images, CSS, JavaScript) et décharge le serveur de leur envoi. Le code PHP et la base restent sollicités à chaque page dynamique.

Faut-il passer à Varnish ou à Redis ?

La page « Scale » de l’éditeur les cite parmi les options au-delà d’une pile classique : Varnish comme accélérateur HTTP du front-office, Redis pour les sessions. Elle n’en publie ni la configuration ni un ordre d’application.