Combien de plugins WordPress, est-ce trop ?

« T’as trop de plugins » : la phrase la plus paresseuse du web

À chaque site lent, la même sentence tombe : « c’est parce que t’as trop de plugins ». C’est faux, et je le pense sérieusement. Marcin Dudek, créateur de WP Multitool, a installé 55 202 plugins un par un pour tester leur impact réel sur la vitesse. Sa conclusion démonte frontalement le mythe : le nombre brut de plugins n’est pas la variable qui compte (étude relayée par WPMarmite).

Le site WordPress moyen tourne avec 12 à 15 plugins, et il n’existe aucune limite universelle à ne pas dépasser (NineGravity). Un seul plugin mal codé peut ralentir un site plus que vingt extensions légères. Le vrai sujet, ce n’est pas combien, c’est quoi et comment.

Ce qui ralentit vraiment un site (et ce n’est pas le compteur)

Un plugin coûte cher quand il fait trois choses mal :

• Il charge son JS et son CSS partout, même sur les pages où il ne sert à rien. Un plugin de formulaire de contact qui exécute des requêtes sur chaque page alors qu’il n’apparaît que sur /contact : c’est le cas d’école cité par AIS Technolabs.
• Il empile les requêtes en base de données et laisse traîner logs, tables et options en autoload.
• Il bloque le rendu en chargeant son JavaScript sans defer ni async.

Les chiffres confirment le problème réel : seuls 36 % des sites WordPress mobiles passent les Core Web Vitals de Google, avec un LCP médian de 3,2 s contre 1,8 s pour des stacks modernes (UnfoldCMS). Mais le coupable, c’est rarement le nombre : c’est un thème qui charge 8 à 15 feuilles de style séparées, une base non optimisée, un page builder obèse. Si tu veux creuser, mon diagnostic complet du site lent déroule la méthode.

La seule chose qui remplace le comptage : mesurer l’impact

Arrête de compter, commence à mesurer. L’outil qui change tout s’appelle Query Monitor. Il te montre, plugin par plugin, combien de requêtes SQL, de requêtes HTTP et de temps CPU chacun consomme. C’est ça, auditer par impact plutôt que par nombre.

Ma règle de tri, celle qu’on applique chez Peechy sur chaque audit :

1. Désinstaller ≠ désactiver. Un plugin désactivé peut laisser ses tables. On supprime pour de vrai, on nettoie la base — le nettoyage avec WP-Optimize fait le job.
2. Un plugin = une valeur claire. Si tu ne sais pas ce qu’il t’apporte, il dégage.
3. Chasse les doublons. Deux plugins qui gèrent le SEO, deux qui gèrent le cache : c’est de la surcharge pure (DebugBear insiste sur les chevauchements de fonctions).
4. Un budget de performance. On fixe un plafond : poids de page, nombre de requêtes, temps de chargement. Tout nouveau plugin est testé contre ce budget avant installation. En dessous, on garde ; au-dessus, on cherche mieux.

Pour le cache, un seul plugin bien réglé suffit — ma config LiteSpeed Cache 2026 le montre. Pas besoin d’en superposer trois.

Remplacer les gros plugins par du code léger

Le « snippet mindset » monte depuis 2025. L’idée, portée par Rodolfo Melogli (BusinessBloomer) : arrêter d’installer une extension entière pour une micro-fonction, et écrire du PHP ciblé à la place (Rocket.net).

Une redirection 301, un custom post type, un shortcode maison, l’ajout d’un script dans le header : tout ça se fait en dix lignes. Le site « You Might Not Need That WordPress Plugin » recense ces snippets, filtrables par besoin (Hongkiat).

Attention : je ne prône pas le tout-code. Pour un WooCommerce complexe, un plugin modulaire bien structuré vaut mieux qu’un functions.php de 2 000 lignes ingérable. Le snippet, c’est pour les micro-besoins. Le plugin, pour les fonctions lourdes et maintenues.

L’objection : « je n’y connais rien, je préfère un plugin »

Légitime. Un plugin, c’est de la maintenance déléguée : mises à jour de sécurité, compatibilité assurée. Un snippet PHP mal placé peut casser ton site — et un écran blanc après une mise à jour fait perdre plus de temps qu’il n’en économise.

Ma nuance : si tu es autonome, garde des plugins bien codés et à jour, et audite-les deux fois par an. Si tu ne l’es pas, ne bricole pas de PHP en production. Teste en staging, valide, puis migre proprement. C’est exactement ce type d’arbitrage que couvre la maintenance par abonnement : quelqu’un décide quel plugin mérite sa place, et quand le remplacer par du code.

Le takeaway : ouvre Query Monitor, classe tes plugins par impact réel, supprime les doublons et les inutiles. Un site rapide n’a pas peu de plugins — il a les bons.