Comment mesurer les temps de chargement de l'admin PrestaShop avant et après une optimisation ?

Un dirigeant qui investit dans l'optimisation du back-office PrestaShop a besoin de preuves chiffrées, pas d'impressions. Sans mesure rigoureuse avant/après, impossible de savoir si une intervention a réellement amélioré les performances ou si l'impression de fluidité vient simplement d'un cache navigateur déjà chaud. Voici une méthode structurée pour objectiver les gains.

Définir les pages de référence à tester

Toutes les pages de l'admin ne se comportent pas de la même façon. Il faut choisir un échantillon représentatif et toujours tester les mêmes URL :

• La page de connexion (baseline, sans données métier)
• Le tableau de bord (souvent chargé de widgets et de requêtes statistiques)
• La liste des commandes avec un volume réaliste (ex : 5 000 lignes)
• La liste des produits si le catalogue dépasse 10 000 références
• Une fiche produit en édition, qui sollicite combinaisons, images et traductions

Noter la date, l'heure, le volume de données (nombre de commandes, produits, clients) à chaque mesure : un gain de 30 % constaté avec 2 000 commandes n'a pas la même valeur qu'avec 50 000.

Utiliser la barre de debug PrestaShop

En mode développeur (_PS_MODE_DEV_ activé dans config/defines.inc.php), PrestaShop affiche une barre de debug en bas de l'admin avec des indicateurs précis :

• Temps de chargement total de la page (en secondes)
• Nombre de requêtes SQL exécutées
• Temps cumulé des requêtes SQL
• Memory peak usage (pic mémoire PHP)

Relever ces quatre valeurs sur chaque page testée, avant intervention, constitue la baseline. Après optimisation (ajout d'index, cache activé, nettoyage de modules), reproduire exactement le même protocole. Un back-office PrestaShop bien optimisé affiche généralement un temps de chargement de page sous 1 à 2 secondes et moins de 50 requêtes SQL par page ; au-delà de 150-200 requêtes ou de 4-5 secondes, il y a matière à optimiser.

Mesurer côté navigateur avec les DevTools

Les outils de développement du navigateur (onglet Réseau) apportent un niveau de détail complémentaire :

• TTFB (Time To First Byte) : temps de réponse du serveur avant le premier octet reçu. Un TTFB supérieur à 800 ms sur l'admin signale souvent un problème serveur ou base de données, indépendant du frontend.
• DOMContentLoaded et Load : temps d'affichage complet de la page
• Nombre de requêtes HTTP (CSS, JS, images) et leur poids total

Pour une mesure fiable, désactiver le cache navigateur (case à cocher dans l'onglet Réseau) et répéter le test 3 à 5 fois pour éliminer les variations ponctuelles liées au réseau ou à la charge serveur du moment. Conserver la moyenne, pas seulement la meilleure valeur.

Tester à froid et à chaud

Deux scénarios doivent être distingués :

• Cache froid : première visite après un vidage de cache (Smarty, OPcache, cache navigateur). Reflète l'expérience après une mise à jour ou un redémarrage serveur.
• Cache chaud : visites suivantes, cache déjà constitué. Reflète l'usage quotidien d'un gestionnaire qui navigue dans l'admin toute la journée.

Un écart important entre les deux (par exemple 6 secondes à froid contre 1,5 seconde à chaud) indique que le cache fonctionne bien mais que la première charge reste pénalisante, ce qui compte lors des pics d'activité après une mise à jour de catalogue.

Documenter et comparer méthodiquement

Pour que la comparaison avant/après soit exploitable, il faut figer un maximum de variables :

• Même environnement serveur (pas de montée en charge hébergeur en parallèle)
• Même volume de données dans la base
• Même navigateur et mêmes conditions réseau
• Même utilisateur admin, avec les mêmes droits et le même nombre de modules actifs

Un tableau simple avec les colonnes « page testée / temps de chargement / nombre de requêtes SQL / memory peak / date » permet de visualiser les gains réels après chaque action : ajout d'un index sur une table, désactivation d'un module inutilisé, passage à PHP 8.1, mise en place d'un cache OPcache ou Redis. Un gain de 40 % sur le temps de chargement d'une liste de commandes après ajout d'un index SQL est un résultat concret et vérifiable.

Points de vigilance

La barre de debug ne doit jamais rester activée en production : elle expose des informations techniques et ralentit légèrement le rendu. Elle sert uniquement en environnement de test ou en préproduction, avec des données représentatives du volume réel. Attention également aux mesures faites juste après un déploiement : OPcache et les caches applicatifs doivent se « réchauffer », ce qui peut fausser les premières mesures.

Si ces mesures révèlent un back-office durablement lent malgré les ajustements standards, Performeer PrestaShop met en relation les dirigeants avec des prestataires spécialisés en performance PrestaShop, de façon neutre et sans engagement, pour un diagnostic approfondi.