PrestaShop : optimiser performance via cache Smarty, CCC et CDN

Quand on parle de « PrestaShop : optimiser performance via cache Smarty, CCC et CDN », on parle en réalité de trois couches très différentes : cache de rendu (Smarty), optimisation et cache des assets (CCC), et cache + distribution réseau (CDN). Les confondre mène à des faux gains (ou à des pages cassées), surtout dès que vous avez des modules qui injectent du JS inline, des pages personnalisées, ou un front surchargé.

Un repère utile pour éviter les “optimisations au hasard” est de relier chaque couche à une métrique :

Smarty / PHP influence surtout le TTFB (temps jusqu’au premier octet — inclut le temps de traitement serveur et la latence réseau).
CCC (CSS/JS) influence surtout FCP/LCP et parfois INP (si la minification/ordre de scripts change le comportement).
CDN influence surtout LCP (image hero — image principale, CSS/JS) et la stabilité sous charge (décharge de l’origin).

Enfin, l’intérêt d’un CDN dépend aussi de votre géographie réelle : si votre origin est en France (ex. Paris/Strasbourg) et que 95% de votre trafic est en France métropolitaine, le gain “latence pure” peut être modeste… mais l’intérêt reste fort pour absorber les pics, mieux gérer les images, et améliorer les performances pour les visiteurs hors métropole (DOM-TOM, Belgique/Suisse, Maghreb, Canada, etc.).

Table des matières :

PrestaShop (8.1.x et 9.x) s’appuie encore majoritairement sur Smarty côté front (même si PrestaShop 9 modernise beaucoup le back-office via Symfony). Le « cache Smarty » ne cache pas la base de données : il cache principalement le résultat de compilation des templates (et éventuellement du rendu HTML selon la configuration), ce qui réduit la charge CPU PHP et les I/O associées à la lecture/compilation de templates. Si votre TTFB est dominé par des requêtes SQL ou des hooks lourds, le cache Smarty ne suffira pas ; il faut profiler et corriger la cause (voir l’approche dans Optimisation de code PrestaShop : diagnostiquer lenteurs et requêtes SQL).

Le CCC (Combine, Compress, Cache) agit sur CSS/JS : minification et parfois concaténation. En 2026, avec HTTP/2 et HTTP/3 largement disponibles, concaténer « par principe » est souvent un anti-pattern (moins de granularité de cache, invalidations plus fréquentes). Le CCC du core reste utile pour des thèmes legacy et pour réduire le coût de parsing de gros bundles non optimisés, mais il ne remplace pas un pipeline de build propre (Webpack/Vite) et peut casser des scripts de modules.

Enfin, le CDN n’est pas un bouton magique : dans PrestaShop, la configuration « Serveurs de médias » ne fait que réécrire des URLs statiques. Le core ne gère ni la purge edge, ni les headers Cache-Control, ni la segmentation par cookies. Pour une vraie stratégie CDN (images, CSS/JS, éventuellement edge caching HTML), vous devez piloter la config côté CDN + serveur web.

« HTTP caches are typically used to reduce network bandwidth requirements, reduce latency, and reduce server load. » — RFC 9111 (2022), https://www.rfc-editor.org/rfc/rfc9111.html

Pour éviter les malentendus, gardez une vue “couches” :

Couche	Ce qui est caché/optimisé	Où ça vit	Gains typiques	Risques typiques
Smarty	templates compilés (+ parfois fragments)	disque (`var/cache/...`)	TTFB plus stable, CPU PHP ↓	invalidation brutale, FS lent, multi-nœuds incohérents
CCC	minification (et parfois concat) CSS/JS	fichiers générés + navigateur	poids ↓, requêtes ↓ (parfois)	ordre JS modifié, modules cassés, bundles “trop gros”
CDN	cache + proximité réseau des statiques	edge PoP	LCP ↓, origin soulagé	mauvaise cache key, purge non maîtrisée, cookies/cors

Point important : le core PrestaShop ne fait pas (nativement) de cache HTML full-page “intelligent” (avec variation par cookies, device, devises, etc.). Si vous allez vers Varnish/edge caching HTML, vous sortez du périmètre “toggle” et vous entrez dans une logique d’architecture (bypass cookies, purge événementielle, TTL différenciés).

Comprendre les couches de cache : rendu, assets, réseau (et ce que le core ne fait pas)

Cache Smarty : compilation, cache, invalidation et implications filesystem

Sur PrestaShop 8.1/9 (PHP 8.1–8.3 selon votre stack), Smarty génère des fichiers compilés sur disque (en général sous var/cache/{env}/smarty/compile et var/cache/{env}/smarty/cache). La latence de ce cache est donc directement liée au stockage (NVMe vs SATA, FS réseau, limites d’inodes). Sur un mutualisé ou un disque lent, le « compile » peut devenir un goulet ; et sur un cluster multi-nœuds sans filesystem partagé, vous risquez des recompilations et des incohérences entre nœuds (un nœud sert un template compilé obsolète, l’autre non).

Quelques situations fréquentes (et très concrètes) où Smarty devient “visible” en prod :

Thème lourd + beaucoup de surcharges : la compilation initiale produit de nombreux fichiers ; si vous purgez souvent, vous payez ce coût trop souvent.
FS réseau (NFS/EFS) : temps de métadonnées (stat/open) qui explose sous charge ⇒ TTFB instable.
Auto-scaling/Kubernetes : des pods qui redémarrent et reconstruisent le cache “à froid” si le cache n’est pas persistant.

En production, votre objectif est simple : minimiser la recompilation. Concrètement, dans Paramètres avancés → Performances : désactivez Force compilation, gardez Compilation des templates sur un mode qui évite de recompiler à chaque hit, et activez le cache Smarty uniquement si vous maîtrisez l’invalidation (pages personnalisées, hooks conditionnels, contenu par groupe client, etc.). Si vous déployez via CI/CD, préférez une stratégie de build qui préchauffe le cache et une purge contrôlée à chaque release (et pas un vidage aléatoire en pleine journée).

Une manière pragmatique de cadrer les réglages (sans prétendre qu’il existe un “one-size-fits-all”) :

Contexte	Force compilation	Recompile si modifié	Cache Smarty
Développement	Oui / selon besoin	Oui	Non (ou très ponctuel)
Préprod	Non	Oui	Optionnel (pour valider le comportement)
Production	Non	Oui (ou “jamais recompiler” si votre process de déploiement est strict)	Seulement si vous maîtrisez variation/invalidation

Le piège le plus courant est l’invalidation “à la hache” : purger var/cache trop souvent (cron, scripts de maintenance, “fix” d’urgence) revient à transformer la production en environnement de dev : pics CPU, Wait I/O, contention sur le disque. Avant de toucher à ce dossier, posez un prérequis minimal : un environnement de préprod, un plan de rollback, et des métriques de charge (CPU steal, I/O wait, TTFB).

Checklist “anti-purge destructrice” (utile en boutique à trafic) :

Purger seulement ce qui est nécessaire : si le problème est un asset, évitez de purger tout var/cache.
Éviter les purges en heure de pointe : une purge Smarty + trafic élevé = thundering herd (beaucoup de recompilations simultanées).
Limiter la concurrence : si vous avez plusieurs frontaux, coordonnez l’opération (ou utilisez une stratégie blue/green).

Pour cadrer la partie PHP, gardez aussi en tête que Smarty n’est qu’une couche au-dessus de l’opcode cache : PHP OPcache : paramètres recommandés pour optimiser les performances reste un prérequis non négociable. Un OPcache sous-dimensionné (ou qui “reset” trop souvent) peut annuler une partie des bénéfices attendus de Smarty.

CCC (Combine, Compress, Cache) : utile, mais fragile en présence de modules

Le CCC de PrestaShop opère au niveau des assets déclarés (CSS/JS) et génère des versions “cache” (minifiées/concaténées) afin de réduire la taille transférée et le nombre de requêtes. L’optimisation est réelle quand votre thème est ancien, que vous servez encore beaucoup de petits fichiers, ou que votre serveur est CPU-bound sur la compression. Mais ne vous attendez pas à des gains massifs sur LCP si votre plus gros problème est l’image héros, des polices non optimisées, ou du JS bloquant.

Dans la pratique, CCC est surtout un outil de compatibilité (pour thèmes/modules historiques) et un amortisseur (quand vous n’avez pas de pipeline front moderne). Là où il devient fragile, c’est quand le front ressemble à un “assemblage” :

modules qui ajoutent des scripts avec dépendances implicites (ex. s’attendent à trouver jQuery dans un ordre précis),
scripts inline qui supposent un chargement synchrone (ou qui lisent des variables globales),
assets avec des contraintes d’exécution (paiement, anti-fraude, tag manager, chat, A/B test).

Sur HTTP/2/3, concaténer peut même empirer le cache : un changement minime (un module ajoute un fichier) invalide un gros bundle partagé. Et côté SEO/UX, la règle est simple : un LCP “bon” vise ≤ 2,5 s (seuil recommandé dans la documentation Web Vitals). Référence : https://web.dev/articles/lcp

Mini-scénario (très classique) :
Vous activez la concaténation JS pour “gagner des requêtes”. Sur la page checkout, un module de paiement injecte un script qui doit s’exécuter après un autre fichier (anti-bot / token). La concaténation modifie l’ordre, tout “marche” en navigation simple… mais casse sur certains navigateurs / sur un cache froid. Résultat : panier abandonné en hausse, et parfois aucun log serveur ne vous alerte (erreur uniquement dans la console du navigateur).

La pratique efficace : activer CCC de manière incrémentale et tester page par page (home, catégorie, produit, panier, checkout). Gardez une procédure de diagnostic :

comparer le DOM + l’ordre des scripts (avant/après) ;
surveiller console et network (erreurs 404, MIME, CORS) ;
mesurer via WebPageTest/Lighthouse (TTFB, LCP, INP, poids JS).

Deux réglages “safe” que beaucoup d’équipes retiennent (à valider selon thème/modules) :

Minification : souvent oui, car elle réduit le poids sans changer le graphe de dépendances (mais peut compliquer le debug).
Concaténation : plutôt non sur HTTP/2/3, sauf thèmes legacy (et après test checkout).

Pour les boutiques où le front est déjà construit via Webpack/Vite, considérez CCC comme un filet de sécurité, pas comme un outil de build. Si vous voulez un cadrage “performance globale PrestaShop”, alignez-vous avec la méthodologie de PrestaShop performance : optimiser gros catalogues et Core Web Vitals, qui remet les priorités dans le bon ordre (requêtes, hooks, payload, CWV).

CDN : configuration PrestaShop, headers cache, et limites du champ « serveurs de médias »

Dans PrestaShop, le paramètre Serveurs de médias (utiliser le CDN) permet de définir media1, media2, media3 (ou un domaine unique) pour servir les ressources statiques (images, CSS, JS). Techniquement, PrestaShop réécrit les URLs de certains assets, point. Il ne configure ni les DNS, ni le TLS, ni les règles de cache edge, ni la purge. En clair : si vous mettez un domaine CDN sans config côté fournisseur, vous risquez un downgrade (latence supplémentaire, cache inefficace, erreurs SSL).

Deux points techniques sont souvent sous-estimés au moment d’activer un CDN sur une boutique PrestaShop :

1) Domaine “cookieless” (autant que possible)
Idéalement, servez les statiques depuis un sous-domaine qui ne reçoit pas de cookies applicatifs (ex. static.example.com). Sinon, vous augmentez les headers envoyés sur chaque image/CSS/JS, et vous réduisez le cache hit ratio (selon la cache key et les variations de headers). Dans la vraie vie, tout dépend de votre configuration de cookies (domain, path), mais l’objectif reste : ne pas faire voyager des cookies inutiles sur les statiques.

2) CORS et polices
Si vos polices (ou certains assets) sont servis depuis un autre domaine, un mauvais header CORS peut provoquer des erreurs (fonts bloquées). Testez explicitement le chargement sur la home + page produit.

La valeur ajoutée d’un CDN en e-commerce tient surtout à deux choses : proximité réseau et décharge serveur. La proximité réduit RTT et améliore le “start render”, surtout hors France ; la décharge limite les pics sur votre origin lors d’opérations commerciales. Pour choisir un fournisseur et comprendre les options (cache key, PoP, purge API, HTTP/3, tiered cache), vous avez un comparatif à jour : CDN en 2026 : comparatif Bunny.net, Cloudflare, Akamai, CloudFront, Fastly.

La partie qui ne se fait pas “dans PrestaShop” : les headers. Sans Cache-Control cohérent, votre CDN ne fera pas de miracles. Un cadre réaliste (à adapter) :

Ressource	Exemple	Stratégie cache recommandée
CSS/JS versionnés	`/themes/.../app.css?v=123` ou hash	TTL long (30j–1an) + `immutable`
Images produits	`/img/p/...jpg`	TTL long (7j–1an selon vos mises à jour)
HTML (pages)	`/categorie`, `/produit`	plutôt cache navigateur court, pas edge sans stratégie cookies
Panier/compte/checkout	`/panier`, `/commande`	no-store / bypass CDN

Exemple minimal côté origin (Nginx) pour des assets versionnés (à adapter à votre arborescence et à vos contraintes) :

location ~* \.(css|js|png|jpg|jpeg|gif|svg|webp|woff2)$ {
  add_header Cache-Control "public, max-age=31536000, immutable";
}

À l’inverse, évitez de mettre en cache edge des pages HTML personnalisées sans stratégie “vary”/cookies (panier, compte, prix par groupe, langue/devise). Si vous voulez aller vers du caching HTML (Varnish/edge), faites-le de manière encadrée (bypass sur cookies, purge sur events catalogue). Le sujet est traité dans un contexte “trafic élevé” via PrestaShop soldes : optimiser caches, CDN et Varnish pour trafic élevé.

Rendre Smarty + CCC + CDN cohérents : versioning, purge et déploiements sans surprise

Le point qui coûte le plus cher en prod n’est pas “activer le cache”, c’est rendre l’invalidation déterministe. Sur PrestaShop, le cœur ne fournit pas une API universelle de purge CDN alignée sur chaque évènement (maj produit, prix, stock, règles panier, etc.). Résultat : soit vous purgez trop (vous perdez l’intérêt du CDN), soit pas assez (vous servez des images/prix obsolètes). La solution réaliste est d’implémenter un compromis : purge ciblée (images produit, fichiers compilés) + TTL raisonnables + versioning.

Côté assets, privilégiez une stratégie de cache busting robuste : fichiers hashés via pipeline front (recommandé) ou au minimum paramètres ?v= stables. Le CCC peut régénérer des fichiers à la moindre variation ; si votre CDN cache par défaut les query strings, vous pouvez servir une version obsolète. Vérifiez explicitement la “cache key” côté CDN et ne laissez pas ce point au hasard. Sur le serveur origin, assurez-vous que gzip/brotli et les types MIME sont corrects, sinon le CDN se contentera de distribuer un payload déjà mauvais.

Un cadre opérationnel simple (qui évite beaucoup d’incidents) est de décider à l’avance quoi purger et quand :

Release technique (thème / JS / CSS) : purge CDN sur /themes/… et fichiers CCC, purge Smarty (idéalement sur la nouvelle version uniquement en blue/green).
Changement d’images produit : purge CDN ciblée sur les URLs d’images (ou dossier d’images concerné si votre CDN le permet).
Changement de prix/stock : éviter le cache HTML edge ; privilégier TTL courts côté navigateur si besoin, et laisser l’origin servir l’info à jour.

Côté déploiement, évitez le “je vide var/cache après mise en prod”. Sur un PrestaShop à trafic, c’est un pic CPU quasi assuré, et parfois un effet domino sur la base (plus de requêtes car plus de pages reconstruites simultanément). La stratégie propre : un déploiement blue/green (ou au moins une préprod et une fenêtre) et une purge contrôlée (Smarty, CCC, éventuellement CDN). Pour cadrer les manipulations à risque, appuyez-vous sur Mise à jour PrestaShop : checklist sauvegarde, pré-production et tests et sur la logique de migration sans coupure si votre infra le permet.

Mesurer les gains : protocole de test, métriques CWV, et checklist de mise en production

Sans mesures avant/après, vous optimisez à l’aveugle. Adoptez un protocole reproductible : même URL, même device, même réseau, cache cold vs warm, et capture des timings (TTFB, FCP, LCP, INP, CLS). Une bonne pratique “terrain” est de définir un panel d’URLs représentatives :

1 page home
1 catégorie lourde (beaucoup de produits)
1 page produit “type” (avec déclinaisons)
panier
checkout
1 page CMS (souvent oubliée, mais parfois très chargée via modules)

Et de tester au minimum :

une vue cache froid (nouvelle session, cache navigateur vidé),
une vue cache chaud (rechargement, ou 2e visite),
un point de mesure hors région de l’origin (utile si vous vendez hors France).

Pour instrumenter, combinez : logs serveur (status, bytes, time), outils synthétiques (WebPageTest), et idéalement RUM (New Relic, SpeedCurve, ou équivalent). Pour relier performance et SEO à des données “terrain” (utilisateurs réels), vous pouvez aussi vous appuyer sur Chrome UX Report (CrUX) : https://developer.chrome.com/docs/crux/

Un cas typique observé sur des boutiques PrestaShop “catalogue moyen” (10k–50k produits) :

Cache Smarty correctement configuré : baisse de CPU PHP sur pages chaudes, TTFB plus stable (souvent -50 à -150 ms si compilation excessive avant) ;
CCC : gains variables (0 à -10 % sur poids CSS/JS, parfois -1 à -3 requêtes si concat active), mais risque de régressions fonctionnelles ;
CDN statique (images + assets) : baisse du temps de téléchargement et amélioration LCP surtout hors zone origin (souvent -200 à -600 ms sur LCP si l’image LCP est bien mise en cache et correctement dimensionnée).

Et surveillez les erreurs en parallèle, parce qu’un CCC “agressif” produit souvent des erreurs JS silencieuses qui impactent INP (et donc la conversion). Si vous avez besoin d’un cadre pour centraliser les signaux, utilisez une approche similaire à PrestaShop monitoring d’erreurs : logs PHP, MySQL, JavaScript et alertes e-mail.

Checklist opérationnelle (PrestaShop 8.1.x / 9.x) avant bascule :

Pré-requis : préprod alignée (même thème/modules), sauvegarde, possibilité de rollback ;
Smarty : pas de force compile en prod, purge planifiée, stockage rapide, cohérence multi-nœuds ;
CCC : activation progressive + tests checkout + audit console ;
CDN : DNS/TLS OK, cache key définie (query strings incluses si vous versionnez), règles de bypass cookies si vous touchez au HTML, purge API documentée ;
Headers : Cache-Control cohérent sur statiques, compression, MIME types ;
Mesures : baseline CWV + tests cold/warm + monitoring erreurs.

Si vous devez arbitrer vite : commencez par corriger ce qui dégrade TTFB (requêtes, hooks, OPcache), puis sécurisez les images/asset delivery (CDN + headers), et seulement ensuite ajustez CCC. C’est la séquence la plus robuste pour “PrestaShop : optimiser performance via cache Smarty, CCC et CDN” sans transformer la prod en terrain d’expérimentation.

PrestaShop : optimiser performance via cache Smarty, CCC et CDN

Comprendre les couches de cache : rendu, assets, réseau (et ce que le core ne fait pas)

Cache Smarty : compilation, cache, invalidation et implications filesystem

CCC (Combine, Compress, Cache) : utile, mais fragile en présence de modules

CDN : configuration PrestaShop, headers cache, et limites du champ « serveurs de médias »

Rendre Smarty + CCC + CDN cohérents : versioning, purge et déploiements sans surprise

Mesurer les gains : protocole de test, métriques CWV, et checklist de mise en production

À lire aussi

Optimisation PrestaShop : réduire les requêtes SQL et les hooks

PrestaShop 9 : module reCAPTCHA gratuit et alternatives anti-spam

PrestaShop configuration : éviter l’état panier dans la table ps_configuration