PrestaShop : cache Smarty vs OPcache vs cache navigateur

Comprendre les trois couches de cache dans PrestaShop

PrestaShop utilise plusieurs mécanismes de mise en cache pour délivrer les pages rapidement. Chaque couche opère à un niveau différent de la pile technique, et comprendre ce que chacune fait, quand elle intervient et quand vous devez la vider est essentiel tant pour l'optimisation des performances que pour le dépannage. Les trois couches de cache les plus importantes sont le cache de templates Smarty, le PHP OPcache et le cache navigateur. Elles travaillent ensemble, mais résolvent des problèmes différents et nécessitent des approches de gestion différentes.

Lorsqu'un client visite votre boutique, la requête traverse les trois couches dans l'ordre inverse. Le navigateur vérifie d'abord son cache local. S'il a une copie récente de la ressource, il ne contacte pas du tout votre serveur. Si le navigateur envoie une requête, PHP la traite. OPcache garantit que les fichiers PHP sont compilés une seule fois et réutilisés depuis la mémoire plutôt que d'être re-parsés à chaque requête. Enfin, le cache Smarty garantit que le rendu des templates, qui implique l'analyse de la syntaxe des templates et l'exécution de la logique des templates, n'a lieu que lorsque c'est nécessaire plutôt qu'à chaque chargement de page.

Les problèmes surviennent lorsque ces couches servent du contenu obsolète. Vous modifiez un fichier template, mais la page reste identique. Vous mettez à jour un fichier PHP, mais l'ancien comportement persiste. Vous modifiez le CSS, mais le navigateur affiche toujours les anciens styles. Chacun de ces symptômes pointe vers une couche de cache différente, et vider la mauvaise fait perdre du temps sans résoudre le problème.

Cache de templates Smarty : fonctionnement

Smarty est le moteur de templates que PrestaShop utilise pour générer le HTML. Chaque fichier .tpl de votre thème et de vos modules passe par Smarty avant de devenir le HTML envoyé au navigateur. Le cache Smarty opère en deux phases distinctes : la compilation et le cache de sortie.

Compilation des templates

Lorsque Smarty rencontre un fichier .tpl pour la première fois, il le compile en fichier PHP. Ce fichier compilé est stocké dans le répertoire /var/cache/prod/smarty/compile/ (ou /var/cache/dev/smarty/compile/ en mode debug). Le fichier compilé contient la logique du template traduite en PHP pur, qui s'exécute beaucoup plus rapidement que l'analyse de la syntaxe Smarty à chaque requête.

Smarty vérifie si la version compilée est à jour en comparant les horodatages. Si le fichier source .tpl est plus récent que la version compilée, Smarty le recompile automatiquement. Ceci est contrôlé par le paramètre compile_check. En production, vous pouvez désactiver la vérification de compilation pour des performances maximales, ce qui signifie que Smarty suppose que les templates compilés sont toujours à jour et ne vérifie jamais les fichiers sources.

Cache de sortie des templates

Au-delà de la compilation, Smarty peut également mettre en cache la sortie rendue des templates. Lorsque le cache de sortie est activé, Smarty stocke la sortie HTML finale d'un template et la sert directement aux requêtes suivantes sans exécuter aucune logique de template. C'est plus agressif que le cache de compilation car il saute non seulement l'étape d'analyse mais aussi le traitement des données et l'exécution de la logique au sein du template.

Le cache de sortie dans PrestaShop est géré par hook de module. Chaque module peut déclarer si sa sortie de hook est cacheable, et PrestaShop attribue des clés de cache basées sur des facteurs comme la langue courante, la boutique, la devise et le groupe client. Cela signifie qu'un client français et un client anglais obtiennent des versions en cache séparées.

Paramètres du cache Smarty dans PrestaShop

Vous configurez le cache Smarty dans le back-office sous Paramètres avancés > Performances. Les paramètres pertinents sont :

Compilation des templates : Ceci contrôle comment Smarty gère la compilation des templates. Les options sont typiquement "Ne jamais recompiler" (le plus rapide, utilise toujours la version compilée), "Recompiler si modifié" (vérifie les horodatages de fichiers, bon compromis) et "Forcer la compilation" (recompile à chaque requête, pour le développement uniquement). En production, utilisez "Recompiler si modifié" sauf si vous êtes certain que vos templates ne changent jamais entre les déploiements, auquel cas "Ne jamais recompiler" offre un petit gain de performance supplémentaire.

Cache : Ceci active/désactive le cache de sortie Smarty. Lorsqu'il est activé, Smarty stocke la sortie HTML rendue et la sert sans réexécuter la logique de template. Cela offre des avantages de performance significatifs pour les boutiques avec des templates complexes ou de nombreux hooks de modules. Le type de cache peut être défini sur système de fichiers (défaut) ou un gestionnaire de cache personnalisé.

Optimisations multi-front : Ceci active le cache sur plusieurs serveurs front-end. Uniquement pertinent pour les configurations en cluster.

Vider le cache : Les options incluent "Ne jamais vider les fichiers cache", "Vider le cache à chaque modification" et des stratégies de vidage spécifiques. Pour la plupart des boutiques, vider à la modification est le bon choix car il garantit que les mises à jour sont visibles immédiatement tout en bénéficiant du cache entre les modifications.

Vider le cache Smarty

Pour vider manuellement le cache Smarty, vous pouvez utiliser le bouton "Vider le cache" dans la page Performances du back-office. Ceci supprime les templates compilés et les sorties en cache du répertoire /var/cache/. Vous pouvez également le vider en supprimant directement les fichiers du serveur :

Supprimer les templates compilés : supprimez le contenu de var/cache/prod/smarty/compile/

Supprimer la sortie en cache : supprimez le contenu de var/cache/prod/smarty/cache/

Vous devez vider le cache Smarty lorsque vous modifiez des fichiers .tpl (si la vérification de compilation est désactivée), lorsque vous installez ou mettez à jour un module qui modifie les templates, lorsque vous changez de thème, ou lorsque vous modifiez la configuration liée aux templates. Si vous modifiez un fichier .tpl et que le changement n'apparaît pas en front-end, le cache de compilation Smarty est presque toujours la cause.

PHP OPcache : fonctionnement

PHP OPcache est un cache de bytecode intégré à PHP. Lorsque PHP exécute un fichier, il passe par trois étapes : le lexing (découpage du code source en tokens), le parsing (construction d'un arbre syntaxique abstrait) et la compilation (génération du bytecode que le moteur PHP exécute). OPcache stocke le bytecode compilé en mémoire partagée pour que les requêtes suivantes pour le même fichier sautent entièrement les étapes de lexing, parsing et compilation.

C'est différent du cache Smarty. Smarty met en cache la sortie du rendu de template (HTML). OPcache met en cache la sortie de compilation PHP (bytecode). Ils opèrent à des niveaux complètement différents. Un template Smarty qui a été compilé en fichier PHP par Smarty bénéficie quand même d'OPcache car ce fichier PHP compilé lui-même est mis en cache en bytecode par OPcache.

Configuration OPcache pour PrestaShop

OPcache est configuré dans votre fichier php.ini. Les paramètres les plus importants pour PrestaShop sont :

opcache.enable=1 active OPcache. Ceci devrait toujours être activé en production. La différence de performance est dramatique : l'exécution PHP devient 2 à 5 fois plus rapide avec OPcache activé.

opcache.memory_consumption=256 définit la quantité de mémoire partagée (en mégaoctets) disponible pour stocker le bytecode compilé. PrestaShop avec plusieurs modules peut facilement consommer 128 Mo ou plus. Si cette valeur est trop basse, OPcache évince les anciennes entrées pour faire de la place aux nouvelles, ce qui annule son utilité. Définissez-la à 256 Mo ou plus pour les boutiques avec de nombreux modules. Vous pouvez vérifier l'utilisation avec opcache_get_status() pour voir la mémoire réellement consommée.

opcache.max_accelerated_files=20000 définit le nombre maximum de fichiers PHP pouvant être mis en cache. Le cœur de PrestaShop plus les modules peuvent facilement avoir 10 000 fichiers PHP ou plus. La valeur réelle utilisée par OPcache est arrondie au nombre premier supérieur d'un ensemble prédéfini, donc définir 20000 résulte en une limite réelle de 20479. Vérifiez opcache_get_status() pour vous assurer que vous n'atteignez pas cette limite.

opcache.validate_timestamps=1 indique à OPcache de vérifier si les fichiers sources ont changé. Lorsqu'activé, OPcache vérifie l'heure de modification du fichier à des intervalles définis par revalidate_freq. En production, vous pouvez le mettre à 0 (désactivé) pour des performances maximales, mais vous devez alors redémarrer PHP-FPM ou appeler opcache_reset() chaque fois que vous déployez du nouveau code.

opcache.revalidate_freq=60 définit la fréquence (en secondes) à laquelle OPcache vérifie les changements de fichiers quand validate_timestamps est activé. Une valeur de 60 signifie qu'OPcache vérifie chaque fichier au maximum une fois par minute. Des valeurs plus élevées signifient de meilleures performances mais des délais plus longs avant que les changements de code ne prennent effet. Pour le développement actif, définissez-le à 0 ou 2. Pour la production, 60 est un bon compromis.

opcache.interned_strings_buffer=16 alloue de la mémoire pour les chaînes internées, que PHP utilise pour dédupliquer les chaînes identiques entre différents fichiers. PrestaShop en bénéficie car de nombreux modules partagent les mêmes noms de classes, noms de fonctions et littéraux de chaînes. Définissez-le à 16 Mo ou plus.

opcache.save_comments=1 doit être activé pour PrestaShop. PrestaShop et certaines de ses dépendances utilisent des annotations PHP DocBlock qui sont lues au moment de l'exécution. Si vous désactivez ceci, certaines fonctionnalités ne fonctionnent plus.

OPcache et la séparation CLI vs Web

Un détail important concernant OPcache est que les environnements CLI (ligne de commande) et web (PHP-FPM ou mod_php) maintiennent des pools OPcache séparés. Vider OPcache depuis la ligne de commande (par exemple, exécuter un fichier PHP qui appelle opcache_reset() via CLI) ne vide pas l'OPcache web. Pour vider l'OPcache web, vous devez soit redémarrer le service PHP-FPM, soit exécuter opcache_reset() via une requête web.

Cette distinction est importante dans les workflows de déploiement. Si vous déployez du nouveau code et videz OPcache via une commande CLI, votre site web continue de servir l'ancien bytecode jusqu'à ce que l'OPcache web soit également vidé. De nombreux outils de déploiement gèrent cela en appelant un point de terminaison URL spécial qui déclenche opcache_reset(), ou en redémarrant PHP-FPM dans le cadre du processus de déploiement.

Quand vider OPcache

Vous devez vider OPcache chaque fois que vous modifiez, téléchargez ou remplacez des fichiers PHP sur votre serveur. Cela inclut le déploiement d'une nouvelle version de PrestaShop, l'installation ou la mise à jour de modules, la modification directe de fichiers PHP sur le serveur et la mise à jour des dépendances Composer. Si vous modifiez un fichier PHP et que l'ancien comportement persiste malgré le fichier clairement modifié sur le disque, OPcache sert l'ancien bytecode. Redémarrer PHP-FPM est le moyen le plus fiable de le vider.

Cache navigateur : fonctionnement

Le cache navigateur est la dernière couche, et il opère entièrement côté client. Lorsqu'un navigateur télécharge une ressource (fichier CSS, fichier JavaScript, image, police ou même une page HTML), il peut stocker une copie locale et la réutiliser pour les requêtes suivantes. Cela élimine complètement les allers-retours réseau pour les ressources en cache, ce qui est la plus grande amélioration de performance possible car aucune optimisation côté serveur ne peut battre une latence réseau nulle.

Le cache navigateur est contrôlé par les en-têtes de réponse HTTP que votre serveur envoie avec chaque ressource. Les en-têtes les plus importants sont Cache-Control, Expires, ETag et Last-Modified.

En-tête Cache-Control

L'en-tête Cache-Control est le mécanisme principal pour contrôler le cache navigateur. Il supporte plusieurs directives :

max-age=31536000 indique au navigateur de mettre en cache la ressource jusqu'à 31 536 000 secondes (un an). Pendant cette période, le navigateur utilise sa copie locale sans contacter le serveur. C'est idéal pour les ressources statiques comme CSS, JavaScript et les images qui incluent un identifiant de version dans leur URL (comme un hash ou une chaîne de requête).

no-cache ne signifie pas "ne pas mettre en cache". Cela signifie que le navigateur peut mettre en cache la ressource mais doit la valider auprès du serveur avant d'utiliser la copie en cache. Le serveur répond avec soit un statut 304 (Non Modifié), signifiant que la version en cache est toujours bonne, soit un 200 avec le nouveau contenu.

no-store empêche réellement la mise en cache. Le navigateur doit télécharger la ressource fraîchement à chaque fois. Utilisez ceci pour le contenu sensible qui ne devrait jamais être stocké localement.

public indique que la réponse peut être mise en cache par n'importe quel cache, y compris les CDN et les serveurs proxy. Utilisez ceci pour les ressources statiques.

private indique que la réponse est spécifique à un seul utilisateur et ne devrait pas être mise en cache par les caches partagés comme les CDN. Utilisez ceci pour les pages contenant du contenu spécifique à l'utilisateur, comme la page de compte ou le panier d'un client.

En-tête ETag

Un ETag (Entity Tag) est un identifiant unique pour une version spécifique d'une ressource. Le serveur le génère (typiquement un hash du contenu du fichier) et l'envoie avec la réponse. Lorsque le navigateur doit valider sa copie en cache, il renvoie l'ETag au serveur dans un en-tête If-None-Match. Le serveur compare les ETags et retourne soit 304 (utilisez votre version en cache) soit 200 (voici la nouvelle version).

Les ETags sont utiles lorsque vous voulez un cache navigateur avec validation. Le navigateur fait toujours une requête au serveur, mais si le contenu n'a pas changé, le serveur renvoie une minuscule réponse 304 au lieu de la ressource complète. Cela économise la bande passante tout en assurant la fraîcheur.

Last-Modified et If-Modified-Since

Ces en-têtes fonctionnent de manière similaire aux ETags mais utilisent des horodatages au lieu de hashes de contenu. Le serveur envoie l'horodatage Last-Modified avec la ressource, et le navigateur le renvoie en tant que If-Modified-Since lors de la validation. Le serveur vérifie si le fichier a été modifié depuis ce moment et retourne 304 ou 200 en conséquence.

Les ETags sont généralement préférés au Last-Modified car ils sont basés sur le contenu plutôt que le temps, ce qui évite les problèmes de synchronisation d'horloge et est plus précis. Cependant, la plupart des serveurs envoient les deux, et les navigateurs utilisent ce qui est disponible.

Configuration du cache navigateur pour PrestaShop

Les ressources statiques de PrestaShop (CSS, JavaScript, images) devraient être mises en cache de manière agressive par les navigateurs. L'approche standard est de configurer votre serveur web pour ajouter des en-têtes Cache-Control appropriés aux réponses de fichiers statiques.

Pour Apache, vous utilisez les modules mod_expires et mod_headers dans votre fichier .htaccess. Le .htaccess par défaut de PrestaShop inclut quelques règles de cache, mais vous pouvez vouloir les étendre. Une configuration typique définit max-age=31536000 pour les images, polices, CSS et fichiers JavaScript, tandis que les réponses HTML reçoivent no-cache pour assurer un contenu frais.

Pour Nginx, vous ajoutez des directives expires dans vos blocs location pour les fichiers statiques. Par exemple : location ~* \.(css|js|jpg|png|gif|ico|woff2)$ { expires 1y; add_header Cache-Control "public, immutable"; } met en cache les ressources statiques pour un an et les marque comme immuables (indiquant au navigateur de ne même pas les valider).

Cache busting dans PrestaShop

Si vous définissez de longues durées de cache pour les fichiers CSS et JavaScript, comment les navigateurs obtiennent-ils les versions mises à jour lorsque vous déployez des changements ? C'est là qu'intervient le cache busting. PrestaShop gère cela différemment selon que CCC (Combine, Compress, Cache) est activé ou non.

Avec CCC activé, PrestaShop combine les fichiers CSS et JavaScript en bundles et génère des noms de fichiers incluant un hash du contenu. Lorsque le contenu change, le nom de fichier change, et les navigateurs téléchargent le nouveau fichier car ils n'ont jamais vu cette URL. C'est l'approche de cache busting la plus fiable.

Sans CCC, PrestaShop sert les fichiers CSS et JavaScript individuels à leurs URLs originales. Certains thèmes et modules ajoutent une chaîne de requête de version (comme ?v=1.2.3) à ces URLs, qui change lors de la mise à jour du module. Les navigateurs traitent l'URL avec une chaîne de requête différente comme une ressource différente et la téléchargent fraîchement.

Les images sont plus délicates car leurs URLs ne changent typiquement pas sauf si l'image elle-même est remplacée. Si vous remplacez une image par une nouvelle à la même URL, les navigateurs ayant l'ancienne version en cache continueront à l'afficher jusqu'à l'expiration du cache. Dans ce cas, vous devez soit changer le nom du fichier image, soit vider les caches navigateur (ce que vous ne pouvez pas faire pour vos visiteurs). La solution pratique est d'utiliser des URLs d'images versionnées ou d'attendre que le cache expire naturellement.

Comment les trois couches interagissent

Comprendre l'interaction de ces trois couches de cache est crucial pour un dépannage efficace. Voici le cycle de vie d'une requête typique :

Un client visite une page produit. Le navigateur vérifie son cache pour le HTML de cette page. Comme le HTML est typiquement servi avec no-cache, le navigateur envoie une requête au serveur (possiblement avec un en-tête If-Modified-Since ou If-None-Match pour validation).

Le serveur web reçoit la requête et la passe à PHP. L'OPcache de PHP-FPM a le bytecode pour l'index.php de PrestaShop, le dispatcher, les contrôleurs et tous les fichiers de modules mis en cache en mémoire partagée. PHP exécute le bytecode sans recompiler aucun fichier source.

Le contrôleur de PrestaShop appelle Smarty pour rendre le template. Smarty vérifie son cache pour une version compilée du template. Si le cache de sortie est activé et qu'une sortie en cache valide existe pour cette combinaison de langue, groupe client et autres clés de cache, Smarty retourne le HTML en cache directement. Sinon, Smarty exécute le template compilé (qu'OPcache a également mis en cache en bytecode puisque les templates Smarty compilés sont des fichiers PHP), génère le HTML, le stocke dans le cache de sortie et le retourne.

PHP envoie la réponse HTML au navigateur, accompagnée des en-têtes HTTP qui contrôlent le cache navigateur. Le navigateur rend le HTML et demande tous les fichiers CSS, JavaScript et images référencés dedans. Pour chacune de ces ressources, le navigateur vérifie son cache local. S'il a une copie récente (basée sur Cache-Control max-age), il utilise la copie locale sans contacter le serveur. Si la copie en cache nécessite une validation, il envoie une requête conditionnelle avec des en-têtes ETag ou If-Modified-Since.

Dépannage du contenu obsolète

Lorsque les modifications que vous apportez n'apparaissent pas en front-end, vous devez identifier quelle couche de cache est responsable. Voici une approche systématique :

Étape 1 : Vérifier le navigateur

Ouvrez la page dans une fenêtre de navigation privée ou incognito, ou faites un rafraîchissement forcé (Ctrl+Maj+R sur la plupart des navigateurs). Si le changement apparaît en incognito mais pas dans une fenêtre normale, le cache navigateur est la cause. Videz le cache du navigateur ou attendez son expiration.

Pour les changements CSS et JavaScript spécifiquement, vérifiez l'onglet réseau dans les DevTools du navigateur. Regardez les en-têtes de réponse pour le fichier que vous avez modifié. Si la réponse montre un 304 (Non Modifié) et que le contenu est ancien, le fichier côté serveur n'a peut-être pas réellement changé (vérifiez OPcache). Si le navigateur ne fait même pas de requête pour le fichier (il affiche "from disk cache" ou "from memory cache"), le max-age de Cache-Control n'a pas expiré.

Étape 2 : Vérifier le cache Smarty

Si le changement n'apparaît pas même en incognito, le problème est côté serveur. Pour les changements de templates, videz le cache Smarty depuis le back-office (Paramètres avancés > Performances > Vider le cache) ou supprimez le contenu de var/cache/prod/smarty/. Rechargez la page et vérifiez si le changement apparaît.

Étape 3 : Vérifier OPcache

Si vider le cache Smarty n'aide pas et que le changement concerne un fichier PHP (pas un template), OPcache sert probablement l'ancien bytecode. Redémarrez PHP-FPM ou appelez opcache_reset() via une requête web. Sur un hébergement mutualisé où vous ne pouvez pas redémarrer PHP-FPM, votre panneau de contrôle d'hébergement peut avoir une option pour vider OPcache, ou vous pouvez créer un petit fichier PHP qui appelle opcache_reset() et y accéder via votre navigateur.

Étape 4 : Vérifier les autres caches

PrestaShop a des mécanismes de cache supplémentaires au-delà de ces trois couches. Le cache Symfony (dans PrestaShop 1.7 et 8.x) stocke les conteneurs de services Symfony compilés, les définitions de routes et d'autres données du framework. Videz-le en supprimant les répertoires var/cache/prod/ et var/cache/dev/. Si vous utilisez un reverse proxy comme Varnish ou un CDN comme Cloudflare, ceux-ci ajoutent encore une autre couche de cache qui doit être vidée séparément.

Configuration optimale pour la production

Pour une boutique PrestaShop en production, la configuration de cache optimale équilibre performance et maintenabilité :

Smarty : Définissez la compilation des templates sur "Recompiler si modifié". Activez le cache de sortie. Définissez le vidage de cache sur "Vider à la modification". Cela donne une forte performance de cache tout en garantissant que les modifications du back-office (comme la modification de pages CMS ou le changement de configuration de modules) prennent effet immédiatement.

OPcache : Activez avec au moins 256 Mo de mémoire, 20000 max accelerated files, validate_timestamps activé avec revalidate_freq de 60 secondes. Cette configuration signifie que les changements de code prennent jusqu'à 60 secondes pour prendre effet, ce qui est acceptable en production. Si vous déployez rarement des changements de code et voulez des performances maximales, désactivez validate_timestamps et redémarrez PHP-FPM après chaque déploiement.

Cache navigateur : Définissez Cache-Control avec de longues valeurs max-age (au moins un mois, idéalement un an) pour les ressources statiques (CSS, JavaScript, images, polices). Utilisez no-cache pour les réponses HTML afin que les pages soient toujours validées. Activez CCC dans PrestaShop pour obtenir des noms de fichiers hashés par contenu pour les fichiers CSS et JavaScript combinés, ce qui fournit un cache busting automatique lorsque les ressources changent.

Avec cette configuration, votre boutique bénéficie des trois couches de cache travaillant ensemble. Les ressources statiques sont servies depuis le cache navigateur sans aucun contact serveur. Les fichiers PHP sont exécutés depuis le bytecode en cache sans recompilation. Et le rendu des templates est mis en cache de sorte que la logique Smarty ne s'exécute que lorsque le contenu change. Le résultat est une boutique qui se charge rapidement pour les visiteurs récurrents et gère efficacement le fort trafic côté serveur.

Quand vider chaque couche de cache

Pour éviter à la fois le contenu obsolète et le vidage de cache inutile, suivez ces directives :

Videz le cache Smarty lorsque vous modifiez des fichiers .tpl, changez les positions ou hooks de modules, installez ou mettez à jour des modules qui modifient les templates, ou changez des paramètres liés au thème. Vous n'avez pas besoin de vider le cache Smarty lorsque vous modifiez des fichiers PHP ou mettez à jour des fichiers CSS ou JavaScript.

Videz OPcache lorsque vous modifiez des fichiers PHP, installez ou mettez à jour des modules, mettez à jour le cœur de PrestaShop, ou exécutez Composer pour mettre à jour les dépendances. Vous n'avez pas besoin de vider OPcache pour des changements de templates ou CSS.

Videz le cache navigateur lorsque vous devez voir immédiatement les changements CSS, JavaScript ou d'images pendant le développement. Pour la production, appuyez-vous sur le cache busting (URLs versionnées, noms de fichiers hashés CCC) au lieu de demander aux utilisateurs de vider leurs caches. Vous ne pouvez pas contrôler les caches navigateur de vos visiteurs, donc votre processus de déploiement doit en tenir compte en utilisant des techniques de cache busting appropriées.

Une séquence complète de vidage de cache après un déploiement majeur serait : vider les répertoires de compilation et cache Smarty, redémarrer PHP-FPM pour vider OPcache, purger le cache de votre CDN ou reverse proxy le cas échéant, et vérifier dans une fenêtre de navigation privée. Pour des changements mineurs (comme la modification d'un seul template), vider uniquement la couche pertinente est suffisant et plus rapide.