Audit des modules PrestaShop : vérifier ce que chaque module charge sur chaque page

Pourquoi la surcharge de modules est le tueur silencieux des performances PrestaShop

Chaque boutique PrestaShop démarre rapidement. Puis vous installez cinq modules, dix modules, trente modules, et soudain votre page d'accueil met quatre secondes à se charger. Le coupable est rarement un seul module massif. Ce sont plutôt des dizaines de petits modules qui ajoutent chacun leur propre fichier CSS, leur propre fichier JavaScript et leurs propres requêtes de base de données à chaque chargement de page. Ce poids cumulé est ce que nous appelons la surcharge de modules, et c'est la raison numéro un pour laquelle les boutiques PrestaShop deviennent lentes avec le temps.

Le problème est que la plupart des propriétaires de boutiques n'auditent jamais ce que leurs modules chargent réellement. Ils installent un module pour les étiquettes de produits, un autre pour les boutons de partage social, un autre pour un popup de newsletter, un autre pour les statistiques, et chacun s'enregistre silencieusement sur des hooks comme displayHeader et actionFrontControllerSetMedia. Même si un module n'affiche du contenu que sur les pages produits, il peut quand même charger ses fichiers CSS et JavaScript sur la page d'accueil, les pages catégories, la page panier et le tunnel de commande. Cela signifie que vos clients téléchargent des ressources qu'ils n'utiliseront jamais sur cette page particulière.

Un audit de modules approprié révèle exactement ce que chaque module contribue au poids de votre page. Il vous indique quels modules sont les plus gros contrevenants, lesquels chargent des ressources inutilement et lesquels vous pouvez optimiser ou supprimer entièrement. Cet article vous guide à travers le processus complet d'audit de vos modules PrestaShop pour la performance, en utilisant les DevTools du navigateur, le mode debug de PrestaShop et une analyse systématique.

Étape 1 : Activer le mode debug et le profilage des performances de PrestaShop

Avant d'ouvrir les outils de votre navigateur, vous devez activer les capacités de profilage intégrées de PrestaShop. PrestaShop dispose d'un mode debug qui révèle des informations détaillées sur l'exécution des hooks, les temps de chargement des modules et les requêtes de base de données. Pour l'activer, vous devez modifier deux paramètres.

Tout d'abord, allez dans Paramètres avancés, puis Performance dans votre back office. Réglez le Mode debug sur Oui. Cela active le reporting d'erreurs et la journalisation supplémentaire qui aide à identifier les modules problématiques. Cependant, la véritable puissance vient de la fonctionnalité de profilage.

Pour activer le profilage complet, vous devez modifier le fichier defines.inc.php situé dans le répertoire config de votre PrestaShop. Trouvez la ligne qui définit _PS_DEBUG_PROFILING_ et réglez-la sur true. Dans PrestaShop 1.7 et 8.x, cette constante contrôle l'affichage de la barre de profilage en bas de chaque page du front office. Une fois activée, rechargez n'importe quelle page de votre boutique et vous verrez un panneau de profilage détaillé montrant les temps d'exécution de chaque hook, chaque module et chaque requête SQL.

Le panneau de profilage est divisé en plusieurs sections. La section des hooks vous montre chaque hook exécuté sur la page courante, quels modules sont attachés à chaque hook et combien de temps chaque module a mis à s'exécuter. La section SQL montre chaque requête de base de données, son temps d'exécution et quel module ou fonction du coeur l'a déclenchée. La section des modules vous donne un résumé du temps d'exécution total par module sur tous les hooks.

Portez une attention particulière à la colonne du temps d'exécution total. Un module bien optimisé devrait contribuer à moins de 10 millisecondes au chargement d'une page. Si vous voyez un module prendre 50, 100, voire 500 millisecondes, c'est un problème de performance sérieux qui nécessite une investigation.

Étape 2 : Utiliser les DevTools du navigateur pour cartographier les ressources des modules

Le profilage intégré de PrestaShop vous renseigne sur les performances côté serveur, mais il ne vous montre pas l'image complète de ce qui se passe dans le navigateur. Pour cela, vous avez besoin des outils de développement de votre navigateur. Ouvrez Chrome ou Firefox, appuyez sur F12 et accédez à l'onglet Réseau (Network).

Rechargez votre page d'accueil avec l'onglet Réseau ouvert. Vous verrez chaque requête effectuée par le navigateur : HTML, fichiers CSS, fichiers JavaScript, images, polices et appels AJAX. L'objectif est d'identifier lesquelles de ces requêtes proviennent de modules.

Dans PrestaShop, les ressources des modules suivent un schéma d'URL prévisible. Les fichiers CSS des modules sont généralement servis depuis des chemins comme /modules/nomdumodule/views/css/nomdefichier.css ou /modules/nomdumodule/css/nomdefichier.css. Les fichiers JavaScript suivent le même schéma avec js au lieu de css. Utilisez la barre de filtre dans l'onglet Réseau pour filtrer par « modules/ » et vous verrez instantanément chaque ressource chargée depuis vos modules installés.

Pour chaque ressource de module que vous trouvez, notez les informations suivantes : le nom du fichier, sa taille (à la fois transférée et non compressée), et s'il se charge sur le type de page actuel. Vous voulez construire un tableur ou une simple liste qui associe chaque module à ses ressources. Un audit typique pourrait révéler quelque chose comme ceci : le module A charge deux fichiers CSS totalisant 45 Ko et un fichier JavaScript de 120 Ko sur chaque page, mais il n'affiche du contenu que sur les pages produits. Cela signifie que les pages catégories, la page d'accueil et le panier chargent tous 165 Ko de ressources inutiles.

L'onglet Réseau vous montre également la vue en cascade (waterfall), qui révèle quand chaque ressource commence à se charger et combien de temps cela prend. Les ressources qui bloquent le rendu (CSS bloquant le rendu et JavaScript synchrone) sont particulièrement nuisibles car elles empêchent le navigateur d'afficher tout contenu jusqu'à ce qu'elles aient fini de se charger. Recherchez les fichiers JavaScript de modules qui se chargent dans le head sans attributs async ou defer, car ce sont les pires contrevenants en termes de temps de chargement perçu.

Étape 3 : Analyser la cascade réseau par module

La vue en cascade dans les DevTools mérite sa propre section car elle révèle des problèmes de performance que les tailles brutes de fichiers ne montrent pas. Lorsque vous examinez la cascade, vous voulez identifier trois types de problèmes.

Premièrement, recherchez les ressources bloquant le rendu provenant de modules. Elles apparaissent comme des barres qui démarrent tôt dans la cascade et retardent l'événement de premier affichage (la ligne verticale verte ou bleue). Dans PrestaShop, les fichiers CSS ajoutés via le hook displayHeader ou via addCSS dans setMedia bloquent généralement le rendu. Si un module ajoute un gros fichier CSS qui n'est nécessaire que sur des pages spécifiques, il bloque le rendu sur toutes les pages sans raison.

Deuxièmement, recherchez les chaînes de chargement séquentielles. Certains modules chargent un fichier JavaScript qui déclenche ensuite le chargement de ressources supplémentaires : d'autres fichiers JavaScript, des fichiers CSS, des polices web ou des appels à des API externes. Chaque maillon de cette chaîne ajoute de la latence. Un module qui charge jQuery UI, puis un thème CSS jQuery UI, puis un widget personnalisé, puis le CSS du widget crée une chaîne de quatre requêtes séquentielles qui peuvent prendre 200 à 400 millisecondes même sur une connexion rapide.

Troisièmement, recherchez les requêtes externes. Certains modules effectuent des appels vers des serveurs externes pour des statistiques, du suivi, le chargement de polices, des widgets de réseaux sociaux ou des données d'API. Ces requêtes sont particulièrement dangereuses car vous n'avez aucun contrôle sur le temps de réponse du serveur externe. Un module de partage social qui appelle les API de Facebook, Twitter et Pinterest à chaque chargement de page peut ajouter 500 millisecondes ou plus de latence, et si l'un de ces serveurs est lent ou inaccessible, il peut bloquer le chargement complet de votre page.

Pour quantifier l'impact par module, utilisez la fonctionnalité de blocage des DevTools de Chrome. Faites un clic droit sur une requête d'un module spécifique et choisissez « Bloquer le domaine de la requête » ou « Bloquer l'URL de la requête ». Puis rechargez la page et comparez le temps de chargement. Cela vous donne une mesure directe de la contribution des ressources de ce module au temps total de chargement de votre page. Répétez l'opération pour chaque module afin de construire un classement du plus lourd au plus léger.

Étape 4 : Analyse de l'exécution des hooks

Comprendre quels hooks chaque module utilise est essentiel pour identifier les chargements inutiles. Le système de hooks de PrestaShop est le mécanisme par lequel les modules injectent leur contenu, leurs ressources et leur logique dans les pages. Les hooks les plus pertinents en termes de performance pour les pages du front office sont displayHeader, actionFrontControllerSetMedia, displayTop, displayHome, displayFooter, displayProductAdditionalInfo et displayProductListFunctionalButtons.

Le hook displayHeader est le hook le plus couramment abusé dans l'écosystème PrestaShop. Les modules s'enregistrent sur ce hook pour ajouter leur CSS et JavaScript dans le head de la page. Le problème est que displayHeader se déclenche sur absolument chaque page du front office. Si un module s'enregistre sur displayHeader sans vérifier quelle page le client est en train de consulter, il charge ses ressources partout.

Pour voir quels modules sont enregistrés sur chaque hook, allez dans Apparence, puis Positions dans votre back office. Cette page montre chaque hook et chaque module qui y est attaché. Regardez spécifiquement displayHeader et actionFrontControllerSetMedia. Comptez combien de modules y sont enregistrés. Dans une boutique typique avec 30 modules ou plus installés, vous pourriez trouver 15 à 20 modules rien que sur displayHeader. Chacun ajoute au moins un fichier CSS ou JavaScript à chaque page.

Maintenant, croisez ces informations avec vos résultats DevTools. Pour chaque module sur displayHeader, vérifiez si ce module a réellement besoin de se charger sur la page courante. Un module d'avis produits n'a besoin de ses ressources que sur les pages produits. Un module de liste de souhaits n'a besoin de ses ressources que sur les pages produits et les pages de compte. Un module de guide des tailles n'a besoin de ses ressources que sur les pages produits. Pourtant, tous se chargent sur votre page d'accueil, vos pages catégories, vos pages CMS et votre tunnel de commande.

Les données de profilage de l'Étape 1 ajoutent une autre dimension à cette analyse. Certains modules ne se contentent pas de charger des ressources inutiles mais exécutent également du code PHP coûteux à chaque appel de hook. Un module qui exécute des requêtes de base de données dans sa méthode hookDisplayHeader pour vérifier des valeurs de configuration ou récupérer des données gaspille des ressources serveur sur chaque page, même lorsque sa sortie n'est pas nécessaire.

Étape 5 : Identifier les modules les plus lourds

Avec les données du profilage, des DevTools et de l'analyse des hooks, vous pouvez maintenant classer vos modules par leur impact sur les performances. Créez une liste avec les colonnes suivantes : nom du module, nombre de fichiers CSS chargés, taille totale du CSS, nombre de fichiers JavaScript chargés, taille totale du JavaScript, temps d'exécution serveur d'après le profilage, nombre de requêtes de base de données, et pages où le module affiche réellement du contenu.

Les modules qui obtiennent les scores les plus élevés sur ces métriques sont vos plus gros contrevenants. D'après notre expérience d'audit de centaines de boutiques PrestaShop, les catégories de modules suivantes sont systématiquement les moins performantes.

Les modules de construction de pages (page builders) sont souvent les plus lourds. Ils chargent de grands frameworks CSS, de multiples bibliothèques JavaScript pour leur éditeur visuel, et parfois même chargent les ressources de l'éditeur sur le front office. Un page builder qui charge 300 Ko de CSS et 500 Ko de JavaScript sur chaque page n'est pas inhabituel.

Les modules de réseaux sociaux qui intègrent des widgets de Facebook, Instagram ou Twitter chargent des ressources externes qui sont à la fois volumineuses et imprévisibles dans leur temps de chargement. Un seul widget de flux Instagram peut ajouter 1 Mo ou plus de JavaScript à votre page.

Les modules de statistiques et de suivi qui utilisent plusieurs pixels de suivi chargent des ressources depuis des domaines externes. Chaque pixel de suivi ajoute généralement 20 à 50 Ko de JavaScript plus des requêtes réseau supplémentaires pour les images de pixel et les appels API.

Les modules de carrousel et de diaporama chargent de grandes bibliothèques JavaScript comme Slick, Owl Carousel ou Swiper ainsi que leur CSS. Même si le diaporama n'apparaît que sur la page d'accueil, les ressources se chargent souvent sur chaque page.

Les modules de chat en direct chargent des bundles JavaScript conséquents pour l'interface du widget de chat, généralement 100 à 300 Ko, et ils établissent en plus des connexions WebSocket qui consomment des ressources tout au long de la session de navigation.

Étape 6 : Mesurer les performances avant et après

Avant de commencer à désactiver des hooks ou à supprimer des modules, établissez une mesure de référence. Utilisez plusieurs outils pour obtenir une image complète.

Dans les DevTools de Chrome, allez dans l'onglet Lighthouse et lancez un audit de performance. Enregistrez le Score de Performance, le First Contentful Paint (FCP), le Largest Contentful Paint (LCP), le Total Blocking Time (TBT) et le Cumulative Layout Shift (CLS). Lancez l'audit trois fois et faites la moyenne des résultats pour tenir compte de la variabilité.

Utilisez l'onglet Performance dans les DevTools pour enregistrer une trace de chargement de page. Cela vous donne un diagramme en flammes (flame chart) montrant exactement ce que le navigateur fait à chaque milliseconde. Recherchez les tâches longues (blocs de plus de 50 millisecondes) et identifiez quels modules en sont responsables.

Mesurez également le poids de votre page. Dans l'onglet Réseau, regardez le nombre total de requêtes et la taille totale transférée en bas du panneau. Filtrez par CSS et JS séparément pour obtenir les totaux spécifiques aux modules.

Enregistrez tous ces chiffres avant d'apporter des modifications. Puis, au fur et à mesure que vous optimisez les modules en les décrochant des hooks inutiles ou en les désactivant entièrement, relancez les mêmes mesures. La différence vous indique exactement combien de performance vous avez gagnée avec chaque changement.

Un audit de modules bien exécuté réduit généralement le poids des pages de 30 à 50 pour cent et améliore les temps de chargement d'une à deux secondes. Sur les boutiques avec de nombreux modules mal optimisés, l'amélioration peut être encore plus spectaculaire.

Étape 7 : Désactiver les hooks inutiles

Une fois que vous avez identifié quels modules chargent des ressources sur des pages où elles ne sont pas nécessaires, vous avez plusieurs options d'optimisation. L'approche la plus simple est de décrocher les modules des hooks où ils n'ont pas besoin d'être.

Allez dans Apparence, puis Positions dans votre back office. Trouvez le module sur le hook dont vous voulez le retirer. Cliquez sur l'icône de la poubelle ou le bouton de décrochage pour retirer le module de ce hook spécifique. Cela empêche le module de s'exécuter sur ce hook entièrement.

Cependant, soyez prudent avec cette approche. Certains modules utilisent displayHeader non seulement pour charger du CSS et du JavaScript mais aussi pour effectuer des tâches d'initialisation essentielles. Décrocher un tel module de displayHeader pourrait casser sa fonctionnalité sur les pages où il est réellement nécessaire. Testez toujours dans un environnement de staging ou au minimum testez les pages spécifiques où le module devrait encore fonctionner après le décrochage.

Une meilleure approche à long terme consiste à contacter le développeur du module et à demander un chargement conditionnel des ressources. Un module bien codé devrait vérifier le contrôleur ou le type de page actuel avant de charger ses ressources. Par exemple, un module d'avis produits ne devrait charger son CSS et son JavaScript que lorsque le contrôleur actuel est ProductController. De cette façon, le module reste accroché à displayHeader pour la compatibilité mais ne charge les ressources que lorsqu'elles sont réellement nécessaires.

Si vous êtes à l'aise avec la modification du code des modules, vous pouvez ajouter des vérifications conditionnelles vous-même. Dans la méthode hookDisplayHeader ou hookActionFrontControllerSetMedia du module, ajoutez une vérification du nom du contrôleur actuel. Si le contrôleur n'est pas l'un de ceux où le module affiche du contenu, retournez directement sans ajouter de ressources. C'est l'optimisation la plus ciblée et la plus efficace que vous puissiez faire.

Checklist pratique pour votre audit de modules

Pour résumer l'ensemble du processus d'audit, voici une checklist pratique que vous pouvez suivre. Commencez par activer le profilage debug de PrestaShop. Ouvrez l'onglet Réseau des DevTools et rechargez votre page d'accueil. Filtrez les requêtes par le chemin des modules et listez chaque ressource de module. Notez la taille et le type de chaque ressource. Vérifiez dans Apparence, puis Positions les modules sur displayHeader. Croisez les enregistrements de hooks avec les endroits où les modules affichent réellement du contenu. Utilisez le blocage de requêtes des DevTools pour mesurer l'impact par module. Enregistrez les scores Lighthouse de référence. Décrochez les modules des hooks où ils ne sont pas nécessaires. Ajoutez un chargement conditionnel aux modules qui se chargent globalement. Re-mesurez les scores Lighthouse après chaque changement. Documentez vos résultats et vos changements pour référence future.

Cette approche systématique garantit que vous ne manquez aucune opportunité de performance et vous donne des données concrètes pour justifier chaque changement que vous effectuez. La surcharge de modules n'est pas un mystère. C'est un problème mesurable et résoluble, et chaque boutique PrestaShop bénéficie d'un audit de modules approfondi au moins une fois par an.