Le debugging performance peut-il être limité ?

Oui. Quand vous activez le profiler front-office dans MPR Performance Revolution, vous décidez qui peut le voir : laissez le panneau entièrement désactivé, ou affichez-le en le limitant aux employés connectés afin que les clients ne voient jamais vos timings.

L’un des conseils performance PrestaShop les plus utiles est de profiler la boutique live, pas une copie de test propre, vrai trafic, vrais modules, vraies données. Le profiler ajoute une petite barre qui affiche le nombre de requêtes SQL et le temps de chaque page, et liste les requêtes les plus lentes ainsi que les hooks de modules les plus lents, afin que vous voyiez exactement où une page passe son temps avant de modifier quoi que ce soit.

L’erreur fréquente est de laisser un profiler visible publiquement : il divulgue des détails internes et ajoute de l’overhead à chaque requête. Gardez-le réservé aux employés, désactivez-le une fois le goulot trouvé, et agissez sur ce qu’il montre, souvent un hook de module lourd ou une requête non indexée. Le module gère aussi le cache objet Redis, le report des assets et le warming du cache OPcache/Smarty, donc les corrections vivent au même endroit que le diagnostic.

Les réglages concernés sont deux interrupteurs : profiler_panel_enabled active le panneau front-office, et profiler_employees_only le garde derrière une session employé back-office active. Le réglage employees-only est activé par défaut, tandis que le panneau lui-même est désactivé par défaut. Quand le profiling commence, le module initialise l’instrumentation tôt dans la requête puis injecte le panneau avant </body> seulement si le collecteur est activé et que la porte employé est passée.

Pour une attribution SQL et hooks plus profonde, le module inclut des overrides optionnels qui enregistrent chaque requête base de données et le timing de hook par module, et le query profiler journalise les requêtes lentes au-dessus du seuil configuré, par défaut 0.1 seconde. Installez-les seulement quand vous avez besoin de ce niveau de visibilité, car ils ajoutent volontairement de l’overhead d’instrumentation. Un bon workflow : activer le profiler réservé aux employés, reproduire une URL lente, capturer les totaux requêtes/hooks, le désactiver, puis effectuer la plus petite correction de cache, index ou module qui répond au goulot mesuré.