Des modules qui ralentissent la boutique

Les trois façons dont un module coûte du temps

Les requêtes à la base. Un module accroché à l’affichage des produits qui interroge la base une fois par produit transforme une page de catégorie en dizaines de requêtes supplémentaires. Cette erreur de conception, appelée requête en boucle, ne se voit pas sur une boutique de démonstration et devient visible dès que le catalogue grossit.

Les ressources chargées dans la page. Chaque module qui ajoute sa feuille de style et son script alourdit toutes les pages, y compris celles où il ne sert à rien. Un module de comparateur qui charge ses ressources sur la page de paiement en est l’exemple typique.

Les appels vers l’extérieur pendant l’affichage. C’est le plus coûteux et le plus sournois : un module qui interroge un service tiers au moment de construire la page fait attendre le visiteur aussi longtemps que ce service met à répondre. Le jour où le service est lent, votre boutique l’est aussi, sans qu’aucun changement n’ait été fait chez vous.

Ce que je fais une fois le module identifié

Rarement une désinstallation pure et simple : le module rend un service, et le retirer déplace le problème vers l’exploitation quotidienne. Trois corrections donnent des résultats mesurables. Limiter le chargement des ressources aux pages où le module sert réellement, ce qui se règle dans son code sans toucher à sa fonction. Mettre en cache le résultat des appels extérieurs, pour que le service tiers soit interrogé périodiquement plutôt qu’à chaque visite. Remplacer une requête en boucle par une requête unique, ce qui est la correction la plus rentable quand le catalogue est important.

Quand aucune de ces trois pistes n’est possible parce que le module est encodé ou verrouillé par sa licence, la question devient un choix : remplacer le module, ou accepter son coût. Je le dis clairement plutôt que de facturer une optimisation qui ne peut pas aboutir.