Cache de page complète dans PrestaShop : quand il est utile et ce qu'il faut exclure

Chaque fois que quelqu'un ouvre une fiche produit, PrestaShop démarre, interroge la base de données des dizaines ou des centaines de fois, assemble le template et renvoie le HTML. Pour le visiteur suivant qui ouvre la même fiche, il refait exactement le même travail. Le cache de page complète enregistre ce HTML la première fois et le sert directement les fois suivantes, sans exécuter PrestaShop.

La différence de temps de réponse du serveur peut être énorme. Mais une boutique n'est pas un blog : elle a un panier, une session, des prix par client et un bandeau cookies. Mettre en cache ce qui ne doit pas l'être est le moyen le plus rapide de montrer à un client le panier d'un autre.

Les caches que PrestaShop possède déjà (et ce qui les distingue)

• Cache des templates Smarty : il conserve les templates compilés. Il accélère l'assemblage, mais PrestaShop continue de s'exécuter à chaque visite.
• Cache d'objets ou de requêtes (Memcached, Redis, APCu) : il conserve les résultats des requêtes. Moins de charge pour la base de données, mais PHP s'exécute toujours.
• OPcache : il conserve le PHP compilé. Indispensable, et sans rapport avec le HTML.
• Cache de page complète : il conserve le résultat final. C'est le seul qui évite d'exécuter PrestaShop.

Ils ne sont pas concurrents : ils s'additionnent. Une boutique bien montée a toujours OPcache, et un cache de requêtes et de page selon son trafic et son catalogue.

Quelles pages peuvent être mises en cache

La règle pratique : on met en cache pour le visiteur anonyme et sans panier. Dès qu'il y a une session client ou des produits dans le panier, la page est générée normalement.

Ce qu'il faut régler avant de l'activer

Des parties dynamiques dans une page cachable

La fiche produit est la même pour tous, mais le compteur du panier dans l'en-tête, non. Pas plus que le « Bonjour, Marta », ni les prix si vous avez des groupes de clients avec des tarifs différents. Il y a deux façons de le résoudre : ne pas mettre en cache pour ceux qui ont une session ou un panier, ou charger ces parties ensuite par AJAX. La première est la plus sûre.

Prix par groupe, pays ou devise

Si un client B2B voit d'autres prix, il ne doit jamais recevoir la version en cache de l'anonyme, ni l'inverse. Même chose pour les devises et les pays qui changent les taxes : soit on conserve une version par combinaison, soit ces visites ne sont pas mises en cache.

Mobile et ordinateur

Si votre thème génère un HTML différent pour le mobile, il vous faut des versions séparées par appareil. S'il s'agit d'un thème purement responsive, une seule version suffit.

Cookies et consentement

C'est le point le plus souvent négligé. Si votre bandeau cookies décide côté serveur quels scripts sont imprimés, la première page mise en cache « fige » la décision de celui qui l'a générée. Un visiteur qui a tout accepté génère la page avec les pixels actifs, et le suivant, qui n'a pas encore décidé, les reçoit quand même.

Les solutions habituelles : que le bandeau applique le blocage dans le navigateur, sur une page identique pour tous, ou que le cache conserve des versions séparées selon l'état du consentement.

Invalider : le vrai problème

Mettre en cache est facile. Le difficile, c'est de savoir quand une page enregistrée n'est plus exacte. Dans une boutique, cela arrive en permanence :

• Vous modifiez un prix ou une description.
• Vous activez une règle panier ou un prix spécifique.
• Un produit se retrouve en rupture après une commande.
• Vous modifiez une catégorie, une marque ou une page CMS.

Si le cache n'en est pas informé, les clients voient l'ancien prix ou un produit « disponible » qui ne l'est plus. Il existe deux stratégies : l'expiration dans le temps (la page est valable une heure puis elle est régénérée) et la purge sur événement (l'enregistrement d'un produit vide ce qui le concerne). Le bon choix consiste à les combiner : purge quand vous modifiez quelque chose et expiration comme filet de sécurité.

Et une chose à savoir : les modifications qui ne passent pas par le back-office —un import en SQL direct, un ERP qui écrit dans la base de données sans passer par l'API— ne déclenchent aucun événement. Si votre stock arrive ainsi, vous devez vider le cache à la fin de chaque synchronisation.

Quand cela ne vaut pas la peine

• Boutiques dont presque tout le trafic est connecté, comme un B2B où tout le monde se connecte : le taux de succès sera faible.
• Catalogues qui changent toutes les quelques minutes par synchronisation avec les fournisseurs : le cache est purgé avant d'avoir servi quoi que ce soit.
• Un serveur lent pour une autre raison : une requête mal indexée ou un module qui appelle une API externe à chaque page. Le cache le masque pour l'anonyme, mais le client qui achète continue de le subir dans le tunnel de commande, là où cela compte.

D'abord, une base à jour

Un cache de page sur PHP 7.x et PrestaShop 1.6 sert toujours rapidement les visiteurs anonymes, mais le panier et le paiement, jamais mis en cache, restent aussi lents. Avec PHP 8 et un OPcache bien configuré, et PrestaShop à jour, la partie qui ne peut pas être mise en cache est déjà beaucoup plus rapide. C'est pourquoi, dans une boutique très en retard, la mise à jour est généralement la première étape de performance et le cache la seconde.

Checklist avant de l'activer

• OPcache actif et avec suffisamment de mémoire.
• Panier, commande, paiement, compte et contrôleurs de modules exclus.
• Pas de cache pour les visiteurs avec session ou panier, ou parties dynamiques par AJAX.
• Test du consentement dans deux fenêtres privées.
• Test de prix : modifiez-en un et vérifiez que la fiche le reflète.
• Test de stock : commandez le dernier exemplaire restant et regardez la fiche.
• Vidage à la fin de chaque synchronisation externe.

Comment le résoudre dans PrestaShop

All In One Cache gère trois caches depuis un seul panneau : page complète sur disque, requêtes SQL dans Redis (PrestaShop 8 ou supérieur, avec les tables des commandes, paniers, sessions et stock bloquées par défaut) et OPcache. Pour le cache de page, vous décidez ce qui est exclu, y compris des URL par expression régulière, vous pouvez séparer les versions par appareil et la purge est reliée à PrestaShop : l'enregistrement d'un produit, d'une catégorie, d'un prix spécifique, d'une règle panier ou d'une page CMS le vide, et la validation d'une commande ou un changement de stock purge le cache lié au stock. Vous pouvez aussi vider une URL précise ou tout le cache depuis le panneau, et vous voyez les succès et les échecs. Si vous préférez que nous le laissions configuré et testé sur votre boutique, il existe le service All In One Cache.