La lenteur du back-office peut avoir une cause différente de celle de la boutique publique. Un cache HTML destiné aux visiteurs anonymes ne met pas en cache les écrans d’administration : ce serait dangereux pour les données et les actions de gestion.
Mesurer le bon écran et le bon moment
Notez les actions lentes : connexion, liste des commandes, édition d’un produit, recherche ou ouverture d’un module. Comparez les périodes calmes et chargées. Sur une copie de test, contrôlez les journaux PHP, la durée des requêtes SQL, les tâches cron et les modules qui chargent des données ou des scripts dans le back-office.
Corriger sans casser la boutique
Vérifiez la mémoire, le processeur et la version de PHP prise en charge, puis examinez OPcache et les requêtes coûteuses. Mettez les modules à jour de façon contrôlée ; ne les désactivez pas en production pour deviner la cause. Sauvegardez et mesurez après chaque correction. Si seules les pages publiques sont lentes, traitez plutôt le front-office et son cache.
Lire aussi le guide pour accélérer les pages publiques
Source : PrestaShop Help Center.
Un cache public ne suffit pas pour un back-office lent
L’administration utilise des données privées et dynamiques qui ne doivent pas être diffusées comme des pages publiques. Repérez l’écran lent, mesurez le temps de réponse et vérifiez les modules, appels externes et requêtes concernés avant de modifier Smarty, PHP ou la base. Une optimisation du catalogue ne prouve pas un gain sur l’écran des commandes.