Le WordPress d'aujourd'hui, décodé pour les développeurs

Extensions

« Une extension ralentit forcément un site » : ce que montre un profilage

Le nombre d'extensions actives compte moins que la qualité de leur code, requêtes et hooks compris. Des mesures concrètes plutôt qu'une opinion tranchée.

Par WordPress Développement • 29 avril 2022 • 4 min de lecture • Aucun commentaire
« Une extension ralentit forcément un site » : ce que montre un profilage

47 requêtes SQL supplémentaires par chargement de page, générées par une seule extension de recommandations produits mal optimisée, contre 3 requêtes cumulées pour l’ensemble des neuf autres extensions actives sur le même site : ce chiffre, relevé lors d’un audit de performance, illustre à lui seul pourquoi compter les extensions actives ne dit rien de leur impact réel.

Ce qu’on voit

« Vous avez trop d’extensions installées, c’est pour ça que votre site est lent » : ce diagnostic revient régulièrement, prononcé sans avoir mesuré quoi que ce soit. Il repose sur une intuition simple — plus de code chargé, forcément plus de temps d’exécution — mais cette intuition ignore un facteur bien plus déterminant : la qualité du code exécuté à chaque requête, indépendamment de son nombre.

L'essentiel à retenir : Deux extensions au code médiocre pèsent plus lourd qu'une dizaine bien écrites ; Le nombre de requêtes SQL ajoutées est un indicateur plus fiable que le nombre d'extensions ; Un profilage ciblé révèle le coupable réel plutôt qu'une suspicion générale

Pourquoi c’est un problème

Une extension bien écrite peut ajouter un hook, effectuer une vérification en quelques microsecondes, et ne rien exécuter de plus si la condition n’est pas remplie. Une extension mal écrite peut, à l’inverse, charger une bibliothèque entière sur chaque page, exécuter une requête non mise en cache à chaque affichage, ou boucler sur une liste de contenus sans limite de pagination. Le nombre d’extensions actives ne renseigne en rien sur laquelle de ces deux situations se présente réellement.

Traiter « moins d’extensions » comme un objectif en soi conduit à des décisions contre-productives : désactiver une extension légère et bien écrite au profit d’un code personnalisé souvent moins testé, ou refuser d’installer une extension utile par principe, alors que le vrai risque de performance se trouve ailleurs, non identifié.

Comment mesurer plutôt que supposer

Un profilage ciblé, plutôt qu’une suspicion générale, permet d’identifier précisément où se situe le coût réel. La commande WP-CLI suivante affiche le nombre de requêtes SQL exécutées pendant le chargement d’une page :

wp eval 'echo get_num_queries();'

Pour isoler l’impact d’une extension précise, la comparaison la plus fiable consiste à désactiver temporairement chaque extension une par une, sur un environnement de test, et à mesurer le nombre de requêtes et le temps de génération de page avant et après :

wp plugin deactivate mon-extension-suspecte
wp eval 'echo get_num_queries();'
wp plugin activate mon-extension-suspecte
wp eval 'echo get_num_queries();'

Un outil de profilage plus poussé, capable de tracer précisément chaque requête SQL et son origine (fonction, fichier, ligne), permet d’aller plus loin en identifiant non seulement quelle extension ajoute des requêtes, mais laquelle de ses fonctions en est responsable.

Quoi faire une fois le coupable identifié

  • Vérifier si l’extension propose un mécanisme de cache natif, souvent désactivé par défaut.
  • Contrôler si les requêtes ajoutées sont exécutées sur toutes les pages, ou seulement sur celles qui en ont réellement besoin (condition is_page(), is_singular() mal placée ou absente).
  • Contacter l’auteur de l’extension avec des chiffres précis, plutôt qu’une plainte générale sur la lenteur.
  • Envisager une alternative uniquement après avoir confirmé, par la mesure, que le problème vient réellement de cette extension et non d’ailleurs.

Un contre-exemple révélateur

Sur ce même site audité, désactiver les neuf autres extensions actives n’a fait gagner que 0,04 seconde de temps de génération cumulé, contre 0,31 seconde gagnée en désactivant la seule extension de recommandations mal optimisée. Le nombre d’extensions désactivées ne corrélait donc absolument pas avec le gain de performance observé.

Compter les extensions actives donne une impression de contrôle ; mesurer les requêtes SQL et le temps d’exécution donne des réponses.

En résumé

Le nombre d’extensions actives sur un site n’est pas, en soi, un indicateur fiable de performance. Une poignée d’extensions mal écrites peut peser bien plus lourd qu’une longue liste d’extensions légères et bien pensées. Le profilage ciblé, appuyé sur des chiffres mesurés plutôt que sur une intuition, reste la seule méthode fiable pour identifier où se situe réellement un problème de performance.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi