Performance Revolution : installation et aide

Téléversez le ZIP dans Modules > "Module Manager", installez-le et cliquez sur "Configure". Le menu du back-office est Performances, avec Tableau de bord, "Cache", Ressources, Requêtes, Sauvegarde, Paramètres et Vérification système.

Avant d'activer d'autres couches, relevez le comportement de l'accueil, des catégories, produits, panier, compte et commande. Testez dans un navigateur client et un navigateur employé. Sélectionnez la boutique voulue et sauvegardez la configuration avant de modifier le cache du cœur ou les règles CDN.

Commencez dans Paramètres > Backend de cache. Le processus PHP doit pouvoir écrire dans les répertoires du cache PrestaShop et des ressources générées. L'installation du cache d'objets Redis de PrestaShop nécessite aussi l'accès à la classe de cache du cœur et aux fichiers de configuration concernés. Les actions Cloudflare nécessitent un jeton autorisé pour la zone sélectionnée et les opérations demandées.

Enregistrez et vérifiez l'adaptateur sélectionné sur Tableau de bord. Si Redis ne se connecte pas, vérifiez l'hôte, le port, l'authentification, la base et la prise en charge Redis par PHP. Le choix du backend du module n'active pas nécessairement le cache d'objets du cœur.

Ouvrez "Cache" > Aperçu pour les interrupteurs Cache global, Front-Office, Administration et "Webservice". Ils sont activés par défaut dans le module. L'interrupteur global contrôle l'utilisation du cache du module et ceux des périmètres limitent les contextes de requête correspondants.

Utilisez "Cache" > Couches pour gérer les couches, Navigateur pour examiner les entrées, "Pages" pour les données du cache de pages et Préréglages pour consulter les préréglages disponibles. Lisez un préréglage avant de l'appliquer, car il modifie plusieurs paramètres ensemble.

Ouvrez Paramètres > Mise en cache de fragments.

Un développeur peut mettre en cache un fragment de catégorie en incluant l'identité de celle-ci :

{mpr_cache id="category_products" ttl=3600 tags=["product","category"] vary=["category" => $category.id]}
  {foreach from=$products item=product}
    {include file='catalog/_partials/miniatures/product.tpl' product=$product}
  {/foreach}
{/mpr_cache}

La clé de cache inclut la langue, la boutique, la devise et le groupe client par défaut, sauf si l'inclusion du contexte est désactivée. Ajoutez à vary toute autre valeur influençant le fragment. Ne placez pas de balisage propre à un client dans un fragment partagé sans variation adaptée ou remplacement dynamique.

Utilisez des espaces réservés dynamiques pour les valeurs prises en charge de la requête courante :

<span class="cart-count">{mpr_dynamic name="cart_count"}</span>
<span class="cart-total">{mpr_dynamic name="cart_total"}</span>
<span class="customer-name">{mpr_dynamic name="customer_name" default=""}</span>
<span class="csrf-token">{mpr_dynamic name="csrf_token"}</span>

Les noms pris en charge couvrent aussi les valeurs du client, de la langue, de la devise et de la boutique. Un fournisseur personnalisé peut utiliser actionMPRDynamicContent :

public function hookActionMPRDynamicContent($params)
{
    if (($params['name'] ?? '') === 'loyalty_points') {
        return (string) $this->getCurrentCustomerPoints();
    }
    return $params['default'] ?? '';
}

Ouvrez Paramètres > Cache de requêtes.

Utilisez Requêtes pour examiner les requêtes collectées. Activez le profilage pendant un diagnostic, puis évaluez son surcoût avant de le conserver.

Ouvrez Paramètres > Optimisation des ressources. Activez et testez une modification à la fois sur votre thème.

Activer le CSS généré ne lance pas de navigateur pendant une requête de la boutique. Construisez-le avec les workers distincts. État du CSS initial généré indique sa disponibilité. Le worker "Critical CSS" nécessite Node 22.12 ou ultérieur et son environnement de navigateur configuré. Suivez ses instructions fournies pour la génération et le déploiement.

Ces commandes CLI examinent ou initialisent son travail ; elles ne réalisent pas elles-mêmes toute la génération par navigateur :

php modules/mprperformancerevolution/cli/critical-css.php --targets
php modules/mprperformancerevolution/cli/critical-css.php --seed
php modules/mprperformancerevolution/cli/critical-css.php --status
php modules/mprperformancerevolution/cli/page-type-css.php --status

Reconstruisez les données CSS hors ligne après des modifications pertinentes des feuilles de style, templates, scripts ou contenus. Si les données générées sont absentes ou invalides, le module revient aux feuilles complètes.

Ouvrez Paramètres > Navigation instantanée.

La politique intégrée exclut panier, commande, compte, connexion, liens avec paramètres de requête, fichiers, liens nofollow et outils du module. Le serveur valide également les requêtes spéculatives.

Ouvrez Paramètres > "Images".

L'encodage AVIF à l'exécution peut utiliser GD imageavif ou Imagick avec prise en charge AVIF. GD AVIF nécessite généralement PHP 8.1 ou ultérieur. La génération par lots peut aussi utiliser le backend Python fourni si Python, Pillow, pillow_avif et l'exécution de processus sont disponibles. WebP utilise les fonctions GD prises en charge.

Des valeurs internes supplémentaires s’appliquent aux images des listes : le filtre de types d'images est désactivé par défaut, et la liste est default_sm,default_md,default_lg,home_default,product_main,product_main_2x. Ce ne sont pas des champs visibles distincts dans le formulaire standard "Images". De même, le taux d'échantillonnage RUM interne est 0.1.

Pour un lot contrôlé, exécutez depuis la boutique installée :

php modules/mprperformancerevolution/scripts/generate-images-cli.php --quality=50 --webp-quality=80 --webp --limit=100

Utilisez --path=PATH, répétable, pour limiter le travail à l'intérieur de la racine de la boutique. --force régénère les variantes existantes. Examinez les nombres de conversions, d'éléments ignorés et d'erreurs avant un lot plus important.

Ouvrez Paramètres > Cache de pages d'origine.

Il s'agit d'un véritable cache de page complète à l'origine utilisant le gestionnaire du module. Il est distinct du cache HTML CDN et des fragments Smarty. Panier, compte, commande, administration, AJAX, cookies de session non sûrs et requêtes inconnues le contournent selon la politique d'exécution.

Activez-le après avoir vérifié une page anonyme sans état particulier et les cas de contournement requis. Demandez deux fois la même URL anonyme et examinez X-MPR-PageCache. Testez ensuite connexion, création de panier, changements de devise/langue et pages privées dans des sessions de navigateur distinctes.

Ouvrez Paramètres > Cache de page CDN. Commencez avec la politique de cookies par défaut "Strict".

Après l'enregistrement, utilisez les "Actions" CDN pour appliquer et vérifier les règles, puis examinez le résultat. Un changement de politique de cookies réapplique les règles et purge la zone. Une transition de règles échouée ou en attente n'est pas une configuration achevée.

Testez séparément le cache anonyme et le contournement privé. Connexions, paniers, commande, comptes, AJAX, routes protégées des modules, personnalisation et états de requête non sûrs ne doivent pas partager du HTML anonyme. Préservez la durée de conservation des ressources générées tant que du HTML durable référence d'anciennes ressources.

Le module envoie les en-têtes de cache et effectue les opérations Cloudflare prises en charge. La mise en cache réelle en périphérie dépend toujours de vos règles de zone, des permissions du jeton API et du fait qu'une réponse puisse être mise en cache. Certaines méthodes de purge Cloudflare ne sont pas disponibles sur toutes les offres.

Ouvrez Paramètres > Préchauffage du cache.

Copiez le jeton réellement généré dans le planificateur du serveur. Commande typique de l'exécuteur :

* * * * * php /var/www/html/modules/mprperformancerevolution/cron.php --token=YOUR_TOKEN --max-tasks=20 --max-seconds=55 --context=cron

Adaptez les chemins PHP et boutique. L'exécuteur gère aussi les nettoyages déclarés, invalidations/purges en attente, traitements d'images et maintenance CSS selon l'état des tâches. L'activation d'une fonction et la planification de sa tâche se vérifient séparément.

Un passage manuel après déploiement peut utiliser :

php modules/mprperformancerevolution/cli/warm-cache.php --full --both --url-set=all --concurrency=1 --resolve-ip=127.0.0.1 --max-seconds=120

Utilisez --edge pour l'Edge seul, --cron pour le mode cron et --help pour les arguments pris en charge. Lisez le résumé des états désactivés, échoués ou d'écriture externe bloquée. Un passage suspendu ou limité par le budget peut être normal avec les valeurs prudentes par défaut.

Ouvrez Paramètres > Suivi. Activer la collecte des métriques est activé par défaut, Conservation des métriques vaut 30 jours et Métriques des visiteurs réels est activé. Le taux interne d'échantillonnage RUM est de 10 pour cent. Les métriques du tableau de bord incluent état de l'adaptateur, hits, misses, taux de hits, mémoire, requêtes lentes et mesures TTFB, FCP, LCP, CLS et INP disponibles.

Ouvrez Paramètres > Mode dev pour suspendre temporairement les paramètres de cache. Mode dev est initialement inactif, sauvegarde la configuration précédente et la restaure à la désactivation ou à l'expiration. Mode debug employé est initialement désactivé et active les sorties de développement PrestaShop uniquement pour les employés reconnus disposant du cookie de débogage validé du module.

Dans Paramètres > Débogage, Superposition de débogage, Activer le panneau de débogage et Panneau du profileur sont désactivés par défaut. Adresses IP autorisées et ID des employés autorisés sont initialement vides. Profileur : employés uniquement est activé par défaut. Limitez l'accès aux diagnostics pendant les tests et désactivez-les ensuite.

Des fichiers optionnels du profileur existent dans optional-overrides/classes/Hook.php et optional-overrides/classes/db/Db.php. Utilisez le processus sécurisé d'installation des overrides du profileur pour vérifier les overrides existants. Effacez l'état des classes/caches PrestaShop selon ses instructions. N'écrasez pas d'autres overrides par une copie inconditionnelle. Retirez les overrides optionnels du profileur par le même processus lorsqu'ils deviennent inutiles.

Après chaque changement de configuration, vérifiez accueil, liste, produit, panier et commande, puis les en-têtes de cache et raisons de contournement dans des sessions client distinctes. Les hooks du catalogue, stock, prix et contenu invalident les tags de cache pris en charge, mais les modifications de thème, intégration et règles CDN peuvent nécessiter un vidage explicite.

Si l'adaptateur diffère de votre choix, examinez la disponibilité du backend et la résolution du point de connexion Redis. Si une page contourne le cache, lisez sa raison de diagnostic avant d'augmenter les limites ou de modifier la politique de cookies. Pour du HTML périmé, vérifiez séparément l'origine et l'Edge et confirmez la fin de l'invalidation.

Si le regroupement, le report ou une modification CSS casse un composant, désactivez le paramètre concerné, videz ses fichiers générés ou son cache et retestez. Pour le CSS généré, examinez l'état et le journal du worker. Pour les erreurs d'images, vérifiez les encodeurs et droits d'écriture. Pour un préchauffage en attente, examinez exécuteur, interrupteur de fonction, charge et budgets.

Avant de désinstaller, retirez les overrides optionnels du profileur installés et examinez les règles CDN actives. Désactivez ou retirez les règles Edge du module via le processus CDN pour éviter que la zone continue à cacher des routes privées sans la protection d'origine prévue. Sauvegardez la configuration et les données générées nécessaires.

La désinstallation retire tâches planifiées, amorçage du débogage employé, classe de cache Redis installée, menus et tables du module. Vérifiez ensuite la configuration du cache du cœur PrestaShop et toute configuration CDN externe ; ne supposez pas que Module Manager annule toute configuration distante.

Nécessite PrestaShop 1.6.1 ou ultérieur et PHP 7.1 ou ultérieur.