WordPress · Plugins · Performance

Plugins qui ralentissent WordPress : les identifier sans liste noire

Repérez les plugins qui ralentissent WordPress avec des mesures : requêtes SQL, appels externes, cron, mémoire et tests sur préproduction.

Lecture : environ 6 minGuide pratiquePar l’équipe technique Au P'tit Serveur
Illustration d’un diagnostic de performance WordPress entre navigateur et serveur
Illustration éditoriale dédiée aux performances et à l’hébergement WordPress.

Le problème à résoudre

Il n’existe pas de liste noire universelle : un plugin peut être correct sur un site et coûteux sur un autre à cause de son réglage, du volume de données ou d’une interaction.

Cherchez une corrélation mesurée entre une action et la charge. Une désactivation aveugle en production peut casser le formulaire, le paiement, le cache ou une tâche planifiée.

Reconnaître les bons signaux

Signal observéInterprétation probablePremier contrôle
Admin lenteExtensions éditoriales ou requêtes AJAXProfiler l’écran concerné
Pics réguliersWP-Cron, sauvegarde ou scanComparer horaires et cron
TTFB après activationNouvelle requête ou appel distantTester avant/après

Les notions à maîtriser

  • Le nombre de plugins n’est pas un indicateur suffisant ; leur comportement compte davantage.
  • Les appels HTTP externes rendent la page dépendante d’un service tiers.
  • Les options autoload volumineuses sont chargées sur de nombreuses requêtes.
  • Une extension inactive ne s’exécute pas, mais son code ancien reste une surface à supprimer.

Méthode de diagnostic

1. Créer une copie de préproduction avec les mêmes données.
2. Mesurer les pages lentes avec traces PHP et requêtes SQL.
3. Comparer cron, appels externes, autoload et erreurs de journal.
4. Désactiver un plugin à la fois et reproduire exactement le test.

Plan d’action recommandé

  1. Remplacer une fonctionnalité lourde par une solution plus ciblée.
  2. Déplacer les tâches longues hors de la requête utilisateur.
  3. Limiter fréquence des scans, imports et sauvegardes.
  4. Nettoyer proprement les données orphelines après sauvegarde.
  5. Conserver une preuve avant/après et surveiller les fonctions métier.

Erreurs fréquentes à éviter

  • Désactiver tous les plugins simultanément sans savoir lequel agit.
  • Installer un second plugin de cache pour compenser le premier.
  • Supprimer une extension sans vérifier ses tables, cron et webhooks.

Indicateurs à suivre

IndicateurRepèrePourquoi le suivre
Temps PHPComparé par actionIsole le coût applicatif
Requêtes SQLNombre et durée maîtrisésRepère les accès lourds
Appels externesTimeouts courts et suivisÉvite les attentes tierces

Checklist avant validation

  • Une mesure de référence est conservée.
  • Le changement est testé hors production lorsque c’est possible.
  • Une sauvegarde ou un retour arrière est disponible.
  • Les dépendances web, e-mail et DNS ont été contrôlées.
  • Les journaux et alertes sont surveillés après intervention.
  • Le résultat est documenté avec date et responsable.

Questions fréquentes

Combien de plugins est-ce trop ?

Il n’existe pas de seuil fixe. Dix plugins lourds peuvent coûter plus que cinquante petits.

Peut-on tester en production ?

Mesurez passivement si nécessaire, mais faites les désactivations sur préproduction.

Un plugin de cache masque-t-il le problème ?

Pour les visiteurs anonymes parfois, mais l’administration et les pages personnalisées restent exposées.

Sources techniques

Pour vérifier les règles et approfondir le sujet :

Besoin d’un diagnostic sur votre environnement ?

Décrivez le symptôme, le contexte et l’impact : vous recevrez une réponse cadrée avant toute intervention.

Échanger sur votre besoin