Cache Pro — Full Page Cache with Brotli, Warm-Up & AJAX

Cache Pro est un module de cache de pages complètes pour PrestaShop. Il enregistre une copie prête à servir de chaque page de votre boutique et l’envoie à vos visiteurs avant que PrestaShop ait à reconstruire la page. Les pages enregistrées sont servies bien plus vite, votre serveur travaille beaucoup moins et votre boutique garde sa vitesse quand le trafic augmente.

Le cache est conçu pour de vraies boutiques : les clients connectés et les visiteurs avec un panier reçoivent toujours des pages normales et exactes, les prix suivent la devise et la langue du visiteur, et quand vous modifiez un produit, un prix, une promotion ou un stock, seules les pages concernées sont supprimées.

Points forts :

• Pages enregistrées envoyées avant que PrestaShop construise la page, sans aucune requête SQL du module
• Purge précise : une modification de produit, de prix, de promotion, de stock, d’image, de marque ou de fournisseur ne supprime que les pages concernées
• Pré-chargement de l’accueil, des catégories, des produits et des pages CMS dans toutes les langues, depuis le back-office ou une tâche planifiée
• Tester mon cache en un clic et un tableau de bord : taux de succès, gain de vitesse, pages par type, raisons des pages non servies depuis le cache, dernières purges, vérifications
• Exclusions par URL, plage d’adresses IP, cookie, produit, catégorie ou page CMS ; les pages 2, 3… et les tris ont leur propre copie
• Multilingue, multidevise et multiboutique
• Pré-compression Gzip (et Brotli si votre serveur a l’extension PHP) et minification HTML facultative
• Adresse protégée par un jeton secret pour les tâches cron, l’ERP, le PIM et les scripts de déploiement
• Un seul téléchargement pour PrestaShop 1.7.8, 8.0+ et 9.1+ (PHP 7.4 minimum)

Voir le module et les offres

---

Présentation

Chaque fois qu’un visiteur ouvre une page, PrestaShop démarre, exécute ses modules, interroge la base de données, compile des templates et construit enfin le HTML. Sur une boutique avec beaucoup de produits, de règles de prix et de modules, cela prend des centaines de millisecondes, parfois des secondes, et recommence pour chaque visiteur alors que la plupart des pages sont identiques pour tout le monde.

Avec Cache Pro, la première visite construit la page comme d’habitude et le module en garde une copie. Les visiteurs suivants reçoivent immédiatement cette copie :

1. Le visiteur demande une page.
2. Le module cherche une copie enregistrée pour cette boutique, cette adresse, cette langue, cette devise et cet appareil (ordinateur ou mobile).
3. Si une copie valide existe, elle est envoyée aussitôt (déjà compressée) et PrestaShop s’arrête là.
4. Sinon la page est construite normalement, envoyée au visiteur, puis enregistrée pour les suivants.

Résultat : un temps de réponse serveur (TTFB) nettement plus bas sur les pages qui comptent le plus pour vos visiteurs et pour Google, et un serveur qui supporte davantage de visiteurs. Une page enregistrée demande une fraction des requêtes SQL d’une page générée.

Qui reçoit des pages enregistrées

Les pages enregistrées sont pour les visiteurs qui voient la même page que tout le monde. Quiconque a une page personnelle est servi directement par PrestaShop : rien n’est jamais montré à la mauvaise personne.

Visiteur ou requête	Ce qui se passe
Visiteur anonyme sur une page de votre catalogue	Page enregistrée
Client connecté	Page normale
Visiteur avec des produits dans son panier	Page normale (en option : page enregistrée avec bloc panier rafraîchi, voir Visiteurs avec un panier)
Adresse IP, cookie, URL, produit, catégorie ou page CMS exclus	Page normale
Envoi de formulaire, requête Ajax	Page normale
Mode maintenance ou géolocalisation activés	Page normale

Pages enregistrées : la page d’accueil, les fiches produit, les pages catégorie (avec les pages 2, 3… et les tris), les pages CMS, meilleures ventes, nouveaux produits, promotions, marques, fournisseurs et le plan du site. Le panier, la commande, le compte client, les résultats de recherche, le formulaire de contact et les pages des autres modules (blog…) ne sont jamais enregistrés.

Tableau de bord : pages enregistrées, taux de succès, gain de vitesse et raisons des visites sans cache

---

Fonctionnalités

Cache de pages complètes, dans chaque langue et chaque devise

Une copie distincte est conservée pour chaque boutique, adresse, langue, devise et appareil (ordinateur ou mobile), ainsi que pour les visiteurs qui ont les cookies de votre choix (par exemple le consentement aux cookies). Un visiteur qui navigue en francs suisses ne reçoit jamais la page d’un visiteur en euros, et un changement de devise ou de langue affiche aussitôt les bons prix.

Les paramètres de suivi comme utm_source, gclid ou fbclid sont ignorés : un lien de campagne utilise la même page enregistrée que l’adresse normale. Les pages 2, 3… et les tris d’une catégorie ont leur propre copie. Une adresse avec un paramètre inconnu n’est jamais enregistrée.

Purge précise

Vous ne devriez pas avoir à vider le cache après chaque modification. Cache Pro écoute ce qui se passe dans PrestaShop et ne supprime que les pages concernées :

Ce qui change	Ce qui est supprimé
Un produit (modification, ajout, suppression), une déclinaison, une image, une marque ou un fournisseur	Ses propres pages, les listes qui le montrent (catégories, accueil, meilleures ventes…)
Un prix, un prix spécifique ou une promotion, un stock (y compris une commande)	Les pages qui montrent le produit
Une catégorie ou une page CMS	Toute la boutique (les menus et pieds de page les affichent)
Une devise, une taxe, une langue, une caractéristique, un attribut, un groupe de clients, un pays, une règle de prix catalogue	Toute la boutique
Modules activés, désactivés ou déplacés, changement de thème, langue ou devise par défaut, mode catalogue, coordonnées ou affichage des prix dans les Paramètres de la boutique	Toute la boutique, à la prochaine page du back-office
Les réglages d’un autre module enregistrés (facultatif)	Toute la boutique de ce back-office
Le bouton Vider le cache de PrestaShop	Tout

Une page n’est jamais conservée au-delà du prochain début ou de la prochaine fin d’une promotion programmée : une promotion planifiée apparaît et se termine à l’heure. Vous pouvez aussi tout vider, un type de page, ou une page à partir de son adresse depuis le tableau de bord. Les purges fonctionnent même quand le cache est désactivé : une page ne peut donc jamais revenir périmée.

Purge précise : videz une page depuis son adresse et suivez les dernières purges et leur cause

Pré-chargement

Un cache vide, ce sont des pages lentes pour les premiers visiteurs. Le pré-chargement visite vos pages à l’avance : accueil, catégories, meilleures ventes, nouveaux produits, marques, fournisseurs, produits et pages CMS, dans toutes les langues actives et, si vous le souhaitez, en version mobile. Il utilise votre plan du site XML s’il existe, sinon le catalogue.

Lancez-le depuis le tableau de bord et suivez la barre de progression, ou laissez une tâche planifiée (cron) l’exécuter. Choisissez la vitesse (2, 5, 10 ou 20 pages à la fois) selon votre hébergement. Une boutique protégée par mot de passe (préproduction) est prise en charge avec l’authentification HTTP.

Pré-chargement : visitez vos pages dans toutes les langues avant vos visiteurs, avec une barre de progression

Tester mon cache et tableau de bord

Tester mon cache visite deux fois votre page d’accueil et vous dit en quelques secondes si le cache fonctionne (première visite générée et enregistrée, deuxième visite servie depuis le cache, dossier du cache non téléchargeable depuis le web).

Le tableau de bord montre ce que fait le cache pour votre boutique sur les 7 derniers jours :

• nombre de pages enregistrées, espace disque utilisé et limite
• taux de succès et gain de vitesse (temps de réponse depuis le cache comparé à une page générée)
• pages et taux de succès par type de page
• les raisons pour lesquelles certaines visites n’ont pas utilisé le cache (client, panier, exclusion, paramètre inconnu, maintenance…)
• un graphique par jour
• les dernières purges et leur cause
• des vérifications : dossier du cache, licence, PHP, Gzip et Brotli, cURL, maintenance, géolocalisation, autres modules de cache, devises, thème, espace disque

Tester mon cache : deux visites de votre accueil et leurs temps de réponse, en un clic

Exclusions

Gardez hors du cache les pages qui doivent toujours être générées :

• URL : texte simple (/blog), jokers (/*/promo-*) ou expressions régulières
• Adresses IP et plages (203.0.113.0/24) : votre équipe voit toujours les pages à jour
• Cookies : les visiteurs qui ont l’un des cookies de votre liste (tests A/B, personnalisation)
• Produits, catégories et pages CMS par identifiant
• Types de page : désactivez ceux que vous ne voulez pas enregistrer

Exclusions : gardez certaines URL, produits, catégories, pages CMS, adresses IP et cookies hors du cache

Visiteurs avec un panier

Par défaut, un visiteur qui a des produits dans son panier reçoit des pages normales : le panier, les totaux et les prix sont donc toujours exacts. C’est le choix le plus sûr.

Si vous préférez que ces visiteurs reçoivent aussi les pages enregistrées, l’option avancée Servir les pages enregistrées et rafraîchir le bloc panier envoie la page enregistrée et rafraîchit le bloc panier par une petite requête dès que la page est chargée. Le bouton Détecter le bloc panier de mon thème renseigne le bloc pour les thèmes Classic et Hummingbird ; les autres thèmes demandent le hook et le sélecteur CSS du bloc. La page d’un tel visiteur n’est jamais enregistrée.

Visiteurs avec un panier : servez les pages enregistrées et rafraîchissez le bloc panier après le chargement

Multiboutique

Avec plusieurs boutiques, chaque boutique a ses propres réglages, ses pages enregistrées, ses statistiques et son pré-chargement. Le back-office vous demande de choisir une boutique quand vous ouvrez Cache Pro depuis la vue « toutes les boutiques ».

Tâche planifiée et API

Cache Pro vous donne une adresse protégée par un jeton secret :

• une adresse de tâche planifiée (cron) qui supprime les pages expirées, garde le cache sous sa limite de taille et lance le pré-chargement
• une API pour votre ERP, votre PIM ou vos scripts de déploiement : tout vider, un type de page, un produit, une catégorie, une page CMS, une marque, un fournisseur ou une adresse, lancer le pré-chargement, lire les statistiques

Voir Cron et API pour les paramètres.

Compression et minification HTML

Les pages sont enregistrées pré-compressées en Gzip, et aussi en Brotli quand votre serveur a l’extension PHP Brotli. Le visiteur reçoit le meilleur format accepté par son navigateur, sans aucun travail de compression au moment de la requête. Une minification facultative supprime les commentaires et les espaces entre balises dans la copie enregistrée ; scripts, styles et textes ne sont pas touchés.

Un comportement sûr sous charge

• Une page est écrite entièrement ou pas du tout : un visiteur ne reçoit jamais de page tronquée.
• Quand une page expire, un visiteur la régénère pendant que les autres reçoivent encore la copie précédente (5 minutes au plus) : une page très visitée ne fait jamais faire la queue aux visiteurs. Une purge ne sert jamais d’ancienne copie.
• Les pages enregistrées restent sous une limite de taille (1 Go par défaut) : les plus anciennes sont supprimées en premier.
• Le dossier du cache est protégé et contrôlé par le diagnostic.

---

Prérequis

• PrestaShop 1.7.8, 8.0+ ou 9.1+ (un seul téléchargement pour toutes les versions). PrestaShop 1.7.7 et antérieures, ainsi que 9.0, ne sont pas pris en charge.
• PHP 7.4 ou plus récent
• Extensions PHP : cURL (pré-chargement et test), zlib (Gzip)
• Droit d’écriture sur le dossier modules/wepresta_cache_pro/cache du module
• Une licence WePresta valide
• Un seul module de cache de pages à la fois : désactivez tout autre cache de pages complètes

---

Installation

1. Téléchargez l’archive ZIP du module depuis votre compte client WePresta.
2. Dans le back-office PrestaShop, ouvrez Modules > Gestionnaire de modules et cliquez sur Installer un module.
3. Sélectionnez le fichier ZIP et lancez l’installation.

L’installation crée ses deux petites tables, enregistre ses hooks, crée le dossier du cache et le protège. Le cache reste désactivé tant que vous ne l’activez pas. Avec Apache, le dossier est protégé par un fichier .htaccess ; avec nginx, ajoutez location ~ ^/modules/wepresta_cache_pro/cache/ { deny all; } à la configuration de votre serveur. Le tableau de bord vous indique si le dossier est téléchargeable depuis le web.

Mise à jour depuis la version 1.0.0

Installez la nouvelle archive par-dessus l’ancienne depuis le Gestionnaire de modules. Le module se met à jour tout seul : l’état activé ou désactivé, les durées, vos exclusions (URL, cookies, adresses IP) et la vitesse du pré-chargement sont conservés ; les quatre exclusions d’URL suggérées par la version 1.0.0 (recherche, compte, panier, contact) sont retirées, car ces pages ne sont de toute façon jamais enregistrées ; les fichiers obsolètes sont supprimés et le cache est vidé une fois. Les visiteurs avec un panier reçoivent désormais des pages normales : activez l’option décrite plus haut si vous voulez qu’ils reçoivent des pages enregistrées.

---

Premiers pas

1. Ouvrez Cache Pro dans le menu Modules (menu WePresta sur PrestaShop 9). Les Vérifications en bas du tableau de bord vous disent ce qu’il faut corriger, le cas échéant.
2. Cliquez sur Activer avec les réglages recommandés.
3. Cliquez sur Tester mon cache : la réponse montre les deux visites et leurs temps de réponse.
4. Cliquez sur Lancer le pré-chargement et laissez la page ouverte jusqu’à la fin, ou planifiez la tâche décrite plus bas.
5. Visitez votre boutique dans une fenêtre de navigation privée : rechargez une page et regardez le tableau de bord compter les pages enregistrées et les succès.

Pour suivre une page vous-même, ouvrez les outils de développement de votre navigateur, chargez une page deux fois et lisez l’en-tête de réponse X-WP-Cache : MISS la première fois, HIT la deuxième, BYPASS quand PrestaShop a répondu volontairement (client, panier, exclusion…).

---

Réglages

Général

• Activer le cache : active ou désactive les pages enregistrées. Les clients et les visiteurs avec un panier reçoivent toujours des pages normales.
• Minifier le HTML : les commentaires et les espaces entre balises sont supprimés de la copie enregistrée.
• Servir la page expirée pendant sa régénération : activé par défaut, voir plus haut.
• Vider le cache quand un autre module est configuré : une bannière, un menu ou un bloc modifié dans les réglages d’un autre module apparaît aussitôt.
• En-têtes de diagnostic : ajoute X-WP-Cache-Key, -Type, -TTL, -Age (et -Reason quand une page contourne le cache) aux réponses.
• Cache du navigateur : Vérifier à chaque fois (recommandé), ou 1, 5, 15 minutes, 1 heure.
• Taille maximale : quand la limite est atteinte, les pages les plus anciennes sont supprimées (0 = pas de limite).

Pages à mettre en cache et durées

Pour chaque type de page, choisissez s’il est enregistré et pour combien de temps (minimum 60 secondes). Valeurs par défaut : page d’accueil 30 minutes, fiches produit 2 heures, pages catégorie 1 heure, pages CMS 24 heures, autres listes 1 heure. Une page modifiée dans le back-office est rafraîchie immédiatement, quelle que soit sa durée.

Pages à mettre en cache et durées : choisissez ce qui est enregistré et pour combien de temps

Exclusions

URL exclues, identifiants de produits, de catégories et de pages CMS, adresses IP et plages, cookies. L’enregistrement refuse une expression régulière ou une adresse invalide et vous montre ce que vous avez saisi.

Adresses et variantes

• Paramètres ignorés : paramètres de suivi qui ne changent pas la page (une longue liste est intégrée).
• Paramètres supplémentaires avec leur propre copie : paramètres de votre thème qui choisissent une version de la page (par exemple un tri).
• Mettre en cache les pages filtrées : résultats de la recherche à facettes (?q=…). Désactivé par défaut car ils peuvent être très nombreux.
• Cookies qui changent la page : noms de cookies (consentement…) dont la présence crée une copie distincte.

Pré-chargement et automatisation

Vitesse du pré-chargement, version mobile, authentification HTTP de la boutique, adresse de la tâche planifiée, jeton (que vous pouvez régénérer) et rappel de l’API.

---

Cron et API

Appelez l’adresse cron toutes les 10 minutes : elle supprime les pages expirées, garde la taille sous la limite et lance le pré-chargement. Gardez cette adresse privée : elle contient votre jeton.

L’API se trouve à l’adresse /module/wepresta_cache_pro/api de votre boutique. Envoyez le jeton dans token ou dans l’en-tête X-WPC-Token, et indiquez l’action dans action :

• status (GET) : version, boutique, état du cache, pages et taille, pré-chargement.
• stats (GET) : succès, générations et visites non servies depuis le cache (7 et 30 jours), temps de réponse moyens.
• warmup (GET) : lance ou poursuit le pré-chargement (paramètres facultatifs time, batch, interval et force).
• cleanup (GET) : supprime les pages expirées et applique la limite de taille.
• cron (GET) : nettoyage puis pré-chargement en un seul appel.
• purge (POST) : supprime ce que désigne scope : all ; type (ajoutez type = product, category, cms, home ou other) ; product, category, cms, manufacturer ou supplier (ajoutez id) ; url (ajoutez url = l’adresse de la page).

Exemple, depuis un script après une importation de catalogue :

SHOP=https://votre-boutique.com

curl -X POST \
  -H "X-WPC-Token: VOTRE_JETON" \
  -d action=purge \
  -d scope=category \
  -d id=12 \
  "$SHOP/module/wepresta_cache_pro/api"

---

Compatibilité et autres systèmes

• Autres modules de cache : gardez un seul cache de pages complètes. Le tableau de bord vous avertit si un autre est détecté.
• CDN et proxys : les pages sont envoyées avec Cache-Control: private, donc un CDN ne les conserve pas et interroge toujours votre boutique ; le cache du module fait le travail. Utilisez votre CDN pour les images, scripts et styles.
• nginx : ajoutez la règle location de la section Installation pour bloquer le téléchargement direct du dossier du cache.
• PHP-FPM : avec PHP-FPM, la page est envoyée au visiteur avant d’être enregistrée ; sans lui, le visiteur qui génère une page attend un peu plus longtemps.
• Compression par PHP (zlib.output_compression) : le module envoie alors la copie non compressée et laisse PHP la compresser.
• Statistiques PrestaShop : les pages servies depuis le cache ne sont pas comptées par les statistiques de visites de PrestaShop (Statistiques > Visites). Utilisez Google Analytics ou les journaux de votre serveur pour compter les visites.
• Thèmes : tous les thèmes. Le rafraîchissement du bloc panier a des réglages prêts à l’emploi pour les thèmes Classic et Hummingbird.

---

FAQ

Qu’est-ce qu’un full page cache sur PrestaShop ?

Un full page cache enregistre le HTML final d’une page et envoie cette copie aux visiteurs suivants, au lieu de relancer PrestaShop, ses modules, les requêtes SQL et les templates à chaque demande. Sur une boutique PrestaShop, cela raccourcit le temps de réponse du serveur pour les pages que beaucoup de visiteurs partagent : accueil, catégories, produits et pages CMS.

En quoi ce module peut-il accélérer ma boutique ?

Cache Pro envoie la copie enregistrée d’une page avant que PrestaShop la construise : le module ne fait lui-même aucune requête SQL et la page demande une fraction des requêtes d’une page générée. Les pages enregistrées sont pré-compressées (Gzip, et Brotli si votre serveur a l’extension PHP), le HTML peut être minifié et le pré-chargement remplit le cache avant l’arrivée de vos visiteurs. Le gain dépend de votre hébergement, de votre thème et de vos modules : utilisez « Tester mon cache » pour le constater sur votre propre boutique.

Le panier et les informations client restent-ils exacts ?

Oui. Les clients connectés et les visiteurs qui ont des produits dans leur panier reçoivent toujours des pages normales construites par PrestaShop : rien de personnel n’est enregistré ni montré à quelqu’un d’autre. Si vous préférez que les visiteurs avec un panier reçoivent aussi des pages enregistrées, une option avancée envoie la page enregistrée et rafraîchit le bloc panier avec une petite requête une fois la page chargée, avec des réglages prêts pour les thèmes Classic et Hummingbird.

Le cache se vide-t-il automatiquement quand je modifie mon catalogue ?

Oui. Modifier un produit, une déclinaison, une image, une marque ou un fournisseur supprime ses propres pages et les listes qui l’affichent. Changer un prix, un prix spécifique, une promotion ou un stock (y compris via une commande) supprime les pages qui affichent le produit. Les catégories, pages CMS, devises, taxes, langues, modules et changements de thème rafraîchissent toute la boutique. Une page qui affiche une promotion qui commence ou se termine plus tard n’est jamais gardée au-delà de ce moment. Les purges fonctionnent même quand le cache est désactivé.

À quoi sert le warm-up (pré-chargement) du cache ?

Il visite vos pages importantes avant l’arrivée des visiteurs : accueil, catégories, meilleures ventes, nouveautés, marques, fournisseurs, produits et pages CMS, dans toutes les langues et, si vous le souhaitez, en version mobile. Après une installation, une purge complète ou une grosse mise à jour du catalogue, les premiers visiteurs reçoivent ainsi des pages enregistrées au lieu d’attendre une génération normale. Lancez-le depuis le tableau de bord ou depuis une tâche planifiée.

Le module est-il adapté au multilingue, multidevise et multiboutique ?

Oui. Une copie distincte est conservée pour chaque boutique, adresse, langue, devise et appareil (desktop ou mobile), et pour les visiteurs qui ont les cookies que vous choisissez (le consentement aux cookies, par exemple). Avec plusieurs boutiques, chacune a ses réglages, ses pages enregistrées, ses statistiques et son pré-chargement.

Peut-on régler une durée de cache différente selon le type de page ?

Oui. Chaque type de page (accueil, produits, catégories, pages CMS, autres listes) a son interrupteur et sa durée, avec des valeurs recommandées et un minimum de 60 secondes. Une page modifiée dans le back-office est rafraîchie aussitôt, quelle que soit sa durée.

Est-il compatible avec PrestaShop 1.7.8, 8 et 9 ?

Oui : PrestaShop 1.7.8, 8.0+ et 9.1+, avec PHP 7.4 ou plus récent. PrestaShop 1.7.7 et antérieures, ainsi que 9.0, ne sont pas pris en charge. Une seule archive convient à toutes ces versions. Le module fonctionne avec les thèmes Classic et Hummingbird et avec les thèmes tiers.

Comment vérifier que le cache fonctionne bien ?

Cliquez sur « Tester mon cache » dans le tableau de bord : il visite votre accueil deux fois et vous dit si la première visite a été enregistrée et la seconde servie depuis le cache, avec les deux temps de réponse. Vous pouvez aussi charger une page deux fois avec les outils de développement du navigateur ouverts et lire l’en-tête de réponse X-WP-Cache : MISS la première fois, HIT la seconde, BYPASS quand PrestaShop a répondu volontairement. Le tableau de bord liste aussi les raisons pour lesquelles certaines visites n’ont pas utilisé le cache.

Quelles pages ne sont jamais enregistrées ?

Le panier, la commande, le compte client, les résultats de recherche, le formulaire de contact et les pages des autres modules ne sont jamais enregistrés, pas plus que les envois de formulaires, les requêtes Ajax, le mode maintenance et la géolocalisation, ni les pages que vous excluez par URL, adresse IP, cookie, produit, catégorie ou page CMS. Les clients connectés et les visiteurs avec un panier reçoivent des pages normales (ou des pages enregistrées avec le bloc panier rafraîchi si vous choisissez cette option).

Les premiers visiteurs voient-ils encore des pages lentes ?

La première visite d’une page la construit normalement et l’enregistre ; les visiteurs suivants reçoivent la copie enregistrée. Le pré-chargement supprime cette première attente en visitant vos pages à l’avance, et vous pouvez le lancer depuis une tâche planifiée après chaque purge.

Le module améliore-t-il le SEO ?

Indirectement. Une réponse serveur plus rapide sur les pages que Google et vos visiteurs ouvrent le plus améliore l’expérience et les performances techniques de votre boutique, ce qui peut aider votre visibilité. Les paramètres de suivi sont ignorés et les pages 2, 3… gardent leur propre contenu : moteurs de recherche et visiteurs reçoivent la bonne page.

Est-il compatible avec un CDN ou un autre module de cache ?

Ne gardez qu’un seul cache de pages complètes : le tableau de bord vous avertit si un autre est détecté. Un CDN ou un proxy inverse devant votre boutique convient : les pages sont envoyées avec Cache-Control: private, le CDN ne les conserve donc pas et Cache Pro fait le travail ; utilisez le CDN pour les images, les scripts et les styles.

Peut-on piloter le cache depuis un ERP, un PIM ou un script ?

Oui. Une adresse de tâche planifiée et une API protégées par un jeton secret permettent à vos outils de tout vider, un type de page, un produit, une catégorie, une page CMS, une marque, un fournisseur ou une adresse, de lancer le pré-chargement et de lire les statistiques avec une simple requête HTTP. Le jeton peut être régénéré à tout moment.

Que se passe-t-il quand je mets à jour depuis la version 1.0.0 ?

Installez la nouvelle archive par-dessus l’ancienne. L’état activé ou désactivé, les durées, vos exclusions (URL, cookies, adresses IP) et la vitesse du pré-chargement sont conservés ; les quatre exclusions d’URL suggérées par la version 1.0.0 sont retirées, car ces pages ne sont de toute façon jamais enregistrées ; les fichiers obsolètes sont supprimés et le cache est vidé une fois. Les visiteurs avec un panier reçoivent désormais des pages normales ; activez l’option du bloc panier si vous voulez qu’ils reçoivent des pages enregistrées.

Dois-je modifier la configuration de mon serveur ?

Non avec Apache : le dossier du cache est protégé par un fichier .htaccess. Avec nginx, ajoutez une règle qui interdit le téléchargement direct du dossier du cache ; le tableau de bord vous dit si le dossier peut être téléchargé depuis le web. Rien d’autre n’est nécessaire sur un hébergement mutualisé, un VPS, un serveur dédié ou le cloud.

---

Dépannage

Une page n’est pas enregistrée

Ouvrez le tableau de bord : Pages non servies depuis le cache liste les raisons (client, panier, URL exclue, paramètre inconnu, maintenance, géolocalisation, réponse non enregistrable…). Regardez l’en-tête X-WP-Cache et, avec les en-têtes de diagnostic, X-WP-Cache-Reason.

Le test dit que le module n’est pas atteint

La réponse ne porte pas d’en-tête du cache : un autre cache est placé devant la boutique, le module est désactivé, ou l’adresse est protégée par un mot de passe (renseignez l’authentification HTTP dans les réglages).

Un prix, un stock ou un texte est périmé

Les produits, prix, promotions, stocks, images, catégories et pages CMS vident les bonnes pages tout seuls. Les modifications faites hors de PrestaShop (SQL direct, importations qui n’utilisent pas les objets PrestaShop, fichiers du thème) ne sont pas vues : utilisez Vider tout le cache, le bouton Vider le cache de PrestaShop, ou l’API.

Le pré-chargement signale des erreurs

La liste d’erreurs montre l’adresse et le message. Causes fréquentes : boutique protégée par mot de passe (renseignez l’authentification HTTP), pare-feu qui bloque les requêtes du serveur vers lui-même, certificat SSL invalide sur une préproduction.

Le dossier du cache est téléchargeable

Bloquez le dossier dans la configuration de votre serveur web (voir Installation).

---

Changelog

Version 2.0.0

Nouveautés

• Le module fonctionne sur PrestaShop 1.7.8, 8.0+ et 9.1+, avec PHP 7.4 minimum, dans une seule archive.
• Le menu du back-office affiche Cache Pro, avec son tableau de bord et ses réglages, en français, anglais, espagnol, italien et polonais.
• Tester mon cache visite votre accueil deux fois et vous dit en quelques secondes si le cache fonctionne.
• Le tableau de bord montre le taux de succès, le gain de vitesse, les pages par type, un graphique par jour, les raisons des visites sans cache, les dernières purges et des vérifications.
• Videz une page depuis son adresse, un type de page ou tout le cache, depuis le tableau de bord.
• Le pré-chargement fonctionne sans page ouverte : une adresse de tâche planifiée le lance, avec quatre vitesses, toutes les langues et une version mobile facultative.
• Une API protégée par un jeton supprime tout, un type de page, un produit, une catégorie, une page CMS, une marque, un fournisseur ou une adresse, lance le pré-chargement et renvoie les statistiques.
• Les visiteurs avec un panier peuvent recevoir des pages enregistrées avec le bloc panier rafraîchi après le chargement ; un bouton détecte le bloc des thèmes Classic et Hummingbird.
• Exclusions par cookie, adresse IP ou plage, produit, catégorie, page CMS et type de page, en plus des URL ; une expression régulière ou une adresse invalide est refusée avec une explication.
• Les cookies qui changent la page, comme le consentement aux cookies, ont leur propre copie enregistrée.
• Les pages 2, 3… et les tris d’une catégorie ont leur propre copie enregistrée, tout comme chaque devise.
• Les pages ne sont jamais gardées au-delà du début ou de la fin d’une promotion programmée.
• Le cache reste sous une taille maximale en supprimant les pages les plus anciennes, et la tâche planifiée supprime les fichiers expirés.
• L’en-tête de réponse X-WP-Cache indique HIT, MISS ou BYPASS pour chaque page.
• Avec plusieurs boutiques, chaque boutique a ses réglages, ses pages enregistrées, ses statistiques et son pré-chargement, et une page vous demande de choisir une boutique depuis la vue « toutes les boutiques ».

Améliorations

• Une page enregistrée est envoyée sans aucune requête SQL ni écriture du module.
• Une page est écrite entièrement ou pas du tout : un visiteur ne reçoit jamais une page tronquée.
• Quand une page expire, un visiteur la régénère pendant que les autres reçoivent l’ancienne copie pendant 5 minutes au plus ; une purge ne sert jamais d’ancienne copie.
• Les purges fonctionnent même quand le cache est désactivé : une page ne peut plus revenir périmée.
• Le bouton Vider le cache de PrestaShop, les changements de modules et de thème et les principaux réglages de la boutique rafraîchissent les pages enregistrées.
• L’archive pèse environ 240 Ko au lieu de 27 Mo.

Corrections

• Le texte « Propulsé par Module Starter » et la page publique /module/wepresta_cache_pro/display n’existent plus.
• Les pages 2, 3…, les tris et les listes filtrées n’affichent plus la première page.
• Changer de devise n’affiche plus les prix d’une autre devise.
• La page de maintenance s’affiche quand votre boutique est en mode maintenance.
• Les clients connectés et les visiteurs avec un panier ne reçoivent plus une page enregistrée construite pour quelqu’un d’autre.
• Modifier un produit, un prix, une promotion, un stock, une catégorie ou une page CMS rafraîchit aussitôt les pages enregistrées, au lieu d’attendre la fin de leur durée.
• Les cookies exclus sont pris en compte, et les exclusions d’URL suggérées qui masquaient aussi des pages légitimes, comme les cartes cadeaux, ont disparu.
• Le script qui rafraîchit le bloc panier est maintenant dans l’archive : le bloc ne reste plus vide.
• Les navigateurs ne gardent plus une page enregistrée après qu’un visiteur se connecte ou ajoute un produit au panier.
• Les fichiers et les réglages sont supprimés quand vous désinstallez le module.
• Le taux de succès est exact : les purges ne le remettent plus à zéro.

Après la mise à jour : l’état activé ou désactivé, les durées, vos exclusions (URL, cookies, adresses IP) et la vitesse du pré-chargement sont conservés. Les quatre exclusions d’URL suggérées par la version 1.0.0 sont retirées, car ces pages ne sont de toute façon jamais enregistrées. Les fichiers obsolètes sont supprimés et le cache est vidé une fois. Les visiteurs avec un panier reçoivent désormais des pages normales : activez l’option du bloc panier si vous voulez qu’ils reçoivent des pages enregistrées.

Version 1.0.0

• Version initiale du module
• Mise en place du Full Page Cache
• Gestion des contextes multilingues, multi-devises et multiboutiques
• Invalidation automatique intelligente
• Compression Gzip et Brotli
• Minification HTML
• Dashboard de performance
• Warm-up du cache
• Modules dynamiques en AJAX

---

Support

Pour toute assistance, contactez-nous depuis votre espace client WePresta ou par e-mail à mail@wepresta.shop, selon l’option de support de votre formule.

Avant de contacter le support, merci de fournir :

• la version de PrestaShop et de PHP
• l’adresse de la page concernée et son en-tête X-WP-Cache
• le résultat de Tester mon cache et les vérifications du tableau de bord
• des captures d’écran
• les journaux PrestaShop si disponibles

Voir le module et les offres