Un plugin WordPress coûte cher quand il s’exécute sur la page que le visiteur demande, pas quand il apparaît dans la liste des extensions. Le tri utile oppose les plugins confinés à l’administration à ceux qui ajoutent des requêtes SQL, des fichiers CSS ou JavaScript, ou un appel réseau, sur chaque URL publique.
Ce qui se charge vraiment sur la page
Sur une page publique, WordPress charge le cœur, le thème, puis chaque plugin actif. Un plugin peut rester invisible à l’écran et quand même :
- interroger la base à chaque hit (
init,wp_head,the_content) ; - enregistrer un script ou une feuille sur tout le site alors que le bloc n’est présent que sur une page ;
- appeler une API externe avant d’envoyer le HTML ;
- gonfler les options chargées automatiquement depuis
wp_options.
Depuis WordPress 6.6, la colonne autoload vaut notamment on, off, auto, auto-on et auto-off. Une requête qui ne regarde que l’ancienne valeur yes rate une partie du volume. Ce volume est lu à chaque requête, avant même le contenu de la page.
Les plugins qui ne s’accrochent qu’aux écrans wp-admin (sauf s’ils appellent admin-ajax.php depuis le front) ne sont pas la première piste.
Mesurer avant de désactiver
- Travaillez sur une copie, avec le même thème et les mêmes extensions.
- Installez Query Monitor le temps du diagnostic. Notez, sur l’accueil et sur un modèle interne (article, fiche produit), le nombre de requêtes et le temps PHP.
- Refaites la mesure une fois le cache de page vidé, puis une fois le cache chaud. La première chiffre le coût PHP. La seconde montre ce qui fuit encore : fichiers statiques, scripts tiers, pages exclues du cache.
- Dans l’onglet des requêtes, repérez les composants (plugin ou thème) qui reviennent sur les deux modèles.
- Dans les outils de développement du navigateur, onglet Réseau, listez les scripts dont l’URL contient
wp-content/plugins/.
Ne comparez pas deux tests dont l’un est en cache et l’autre non. Vous concluriez qu’un plugin « ne change rien » alors que le HTML venait du cache.
L’ordre de traitement
| Priorité | Situation | Action |
|---|---|---|
| 1 | Appel externe ou dizaines de requêtes sur chaque page | Retirer, ou limiter au modèle qui en a besoin |
| 2 | CSS et JS du plugin sur toutes les URL | Désinscrire hors des pages utiles |
| 3 | Grosse masse d’options en autoload | Nettoyer les transients expirés, remplacer le plugin |
| 4 | Doublon (deux SEO, deux caches, deux statistiques) | N’en garder qu’un |
| 5 | Outil présent seulement dans l’admin | Le laisser, sauf s’il ralentit les rédacteurs |
Query Monitor, un profiler ou une extension de migration n’ont rien à faire sur la production une fois le constat noté : retirez-les.
Corrections qui tiennent
- Constructeurs de page et sliders : ils envoient souvent leurs fichiers partout. Réglez l’option « charger seulement si le widget est présent », ou remplacez le slider de l’accueil par une image.
- Sauvegardes : une archive déclenchée pendant la visite bloque PHP. Planifiez-la en cron CLI, hors de la requête visiteur. La copie elle-même relève de la règle 3-2-1.
- Partages sociaux, cartes et chats : ce sont des scripts tiers. Le tri se fait dans scripts tiers et performance, pas en ajoutant un plugin de cache supplémentaire.
- Cache : un seul plugin de cache de page. Deux couches qui réécrivent les mêmes URL se contredisent.
- Base : un plugin « articles similaires » qui fait un
LIKEsur le contenu à chaque vue ne se corrige pas avec un thème plus léger. Voyez la base WordPress.
Après chaque retrait, remesurez la même URL, cache vidé puis cache chaud. Si le temps PHP ne bouge pas, le coût est ailleurs : hébergement, thème, ou ressource externe.
Les Core Web Vitals, eux, se lisent sur le terrain (utilisateurs réels) et en laboratoire. Un plugin peut dégrader le LCP sans que le nombre de requêtes SQL paraisse énorme, dès qu’il retarde l’image principale. Le cadre de lecture est dans Core Web Vitals et monitoring.
Erreurs qui font perdre la journée
- Désactiver vingt plugins d’un coup : vous ne savez plus lequel comptait, et le formulaire de contact est mort.
- Juger sur le seul score Lighthouse mobile, sans regarder la cascade réseau.
- Ajouter un plugin « d’optimisation » qui concatène des fichiers déjà bien mis en cache, et qui casse
admin-ajax.php. - Laisser un cache d’objet (Redis) masquer, en apparence, un plugin qui contacte un serveur externe : l’objet en cache n’évite pas cet aller-retour.
Le bon réflexe est une liste courte : plugins actifs sur le front, coût mesuré sur deux modèles, un changement à la fois, puis retrait des outils de diagnostic.