« Combien d’extensions sont installées ? » Cette question, posée en premier lors de nombreux audits de performance, part d’une hypothèse largement répandue mais rarement vérifiée : plus il y a de plugins actifs, plus le site serait lent. Un audit chiffré mené sur deux sites comparables a démonté cette hypothèse de façon nette.
Le premier site, une boutique d’accessoires de sport, comptait quinze extensions actives : un cache, un formulaire de contact léger, un plugin de sécurité, plusieurs modules WooCommerce ciblés. Le second, un site vitrine d’architecte d’intérieur, n’en comptait que trois : un constructeur de pages lourd, une extension de galerie photo mal maintenue, et un plugin de formulaire ancien. Le second site générait ses pages presque deux fois plus lentement que le premier.
Ce que révèle une mesure par extension
Plutôt que de compter les extensions, l’audit a mesuré le temps d’exécution attribuable à chacune, en désactivant successivement chaque extension et en comparant le temps de génération obtenu. Cette méthode, simple à mettre en œuvre avec un outil comme Query Monitor en environnement de test, isole la contribution réelle de chaque module, indépendamment de leur nombre total.
# Méthode de mesure par isolation
wp plugin deactivate constructeur-de-pages-lourd
wp cli profile stage --url=exemple.test --fields=time,cache_ratio
wp plugin activate constructeur-de-pages-lourdSur le site à trois extensions, le constructeur de pages représentait à lui seul plus de 60 % du temps de génération total, en raison d’un grand nombre de requêtes de métadonnées non mises en cache exécutées pour reconstruire chaque section de mise en page à chaque chargement. Sur le site à quinze extensions, aucune extension individuelle ne dépassait 8 % du temps total, chacune restant ciblée et légère dans son périmètre.
Pourquoi le nombre seul est un mauvais indicateur
Une extension de sécurité bien conçue peut se contenter de quelques vérifications rapides sur des hooks précis, sans jamais toucher à la base de données à chaque requête. Une extension de galerie photo mal maintenue peut, à l’inverse, recharger l’intégralité des métadonnées d’images à chaque affichage, sans aucune mise en cache, quel que soit le nombre d’autres extensions présentes sur le site. Le coût réel dépend de ce que fait le code de l’extension à chaque requête, pas de sa simple présence dans la liste des extensions actives.
Une extension légère, bien pensée, qui ne s’exécute que là où elle est nécessaire, coûte objectivement moins cher qu’une extension lourde qui s’exécute sur chaque page, quel que soit le contexte.
Ce qui compte réellement dans le choix d’une extension
- Le nombre de requêtes SQL ajoutées par extension, mesurable directement avec un outil de profilage.
- La présence ou l’absence de mise en cache pour les données récupérées de façon répétée.
- Le périmètre d’exécution : l’extension s’exécute-t-elle uniquement là où elle est utile, ou sur chaque page sans distinction ?
- La fréquence de mise à jour et la réactivité du mainteneur face aux signalements de performance.
Comment présenter ce constat à un client inquiet
Face à un client qui demande de « supprimer des extensions pour accélérer le site », il est plus utile de proposer un audit ciblé qui identifie les extensions réellement coûteuses, plutôt qu’une réduction arbitraire du nombre total. Supprimer une extension légère et utile pour respecter un objectif de quantité, tout en conservant une extension lourde mal codée, n’apporte aucun gain réel et prive le site d’une fonctionnalité utile pour rien.
Notre verdict
Le nombre d’extensions actives ne prédit à peu près rien sur la performance réelle d’un site WordPress. Seule une mesure individuelle, extension par extension, révèle les véritables responsables d’un temps de génération élevé. Réduire ce nombre sans mesure préalable relève davantage du rituel rassurant que de l’optimisation réelle.
