Le coût caché de vos plugins WordPress

Avant même d’ouvrir un thème ou de toucher au design, je pose la même question sur chaque projet WordPress : qu’est-ce que ce site charge réellement ?

La réponse est presque toujours la même — et elle est rarement jolie.

L’autopsie commence

Un site WordPress est un chantier où chaque sous-traitant — les plugins — dépose ses propres matériaux devant le bâtiment, que vous les ayez commandés ou non. Dès qu’un plugin est actif, il peut enregistrer son propre CSS et son propre JavaScript, et WordPress les intègre fidèlement sur chaque page sauf indication contraire.

Voici ce qu’un site WordPress « léger » typique envoie au navigateur lors d’un simple chargement de page :

• Un plugin de slider qui charge 80 Ko de jQuery juste pour afficher une image statique.
• Un page builder qui injecte tout son moteur sur un article de blog qui n’en utilise aucune fonctionnalité.
• Un plugin de formulaire de contact avec sa propre feuille de style et son script sur toutes les pages du site.
• Des analytics, des polices, une bibliothèque de partage, les scripts d’un plugin SEO — chacun ajoutant sa requête, son fichier bloquant.

Rien de tout cela n’est malveillant. Rien n’est « faux ». C’est simplement non géré. Personne ne s’est assis pour demander lesquels de ces éléments doivent réellement se trouver sur la page d’accueil.

L’arithmétique de la lenteur

Le problème n’est pas un plugin en particulier — c’est la somme. Vingt ou trente plugins ajoutant chacun quelques dizaines de kilooctets ne semble pas grand-chose isolément. Mais le navigateur ne les vit pas isolément. Il subit :

• Le CSS bloquant le rendu — la page ne peut pas s’afficher tant que le navigateur n’a pas téléchargé et analysé tout le CSS.
• Le JavaScript bloquant le rendu — le navigateur s’arrête pour exécuter des scripts qu’il n’utilisera peut-être jamais.
• Les allers-retours — chaque fichier supplémentaire est une requête de plus sur le chemin critique.

C’est ainsi qu’un site WordPress finit avec un score de performance autour de 60 alors que son propriétaire affirme, en toute honnêteté, qu’il a « fait simple ».

Ce que je fais réellement

La solution n’est pas de « supprimer tous vos plugins ». C’est le conseil de quelqu’un qui n’a jamais géré un vrai site d’entreprise. Les plugins existent parce qu’ils résolvent de vrais problèmes. La discipline consiste à auditer ce que chacun charge, et à couper ce dont une page donnée n’a pas besoin.

L’ordre pratique :

1. Inventaire. Lister chaque plugin actif et ce qu’il intègre.
2. Cartographie des chargements. Vérifier quel plugin s’affiche réellement sur quelle page.
3. Désactiver et mesurer. Désactiver un plugin et relancer Lighthouse. Le score dit la vérité plus vite que n’importe quelle documentation.
4. Couper ou charger conditionnellement. Tout ce qui n’est pas utilisé sur une page ne doit pas y être envoyé.
5. Interroger le builder. Si tout le site repose sur un page builder, c’est généralement le levier le plus important — et souvent la raison de la lenteur initiale.

Le résultat

Sur les projets que j’ai repris, le schéma est constant. Retirer les ressources de plugins inutilisées et n’envoyer que ce dont chaque page a besoin fait passer un site des années 60 et 70 aux années 90 — et, avec la bonne pile, jusqu’à 100/100.

Les plugins n’ont pas disparu. C’est le gaspillage qui a disparu.

La conclusion honnête

Vos plugins WordPress ne sont pas l’ennemi. L’ennemi, c’est l’accumulation non gérée — la superposition lente d’outils sur d’autres outils jusqu’à ce que plus personne ne se souvienne de leur utilité. C’est un problème de maintenance, pas un problème de technologie. Et comme tout problème de maintenance, il coûte moins cher à régler tôt qu’à subir pendant des années.

Si vous voulez savoir ce que votre propre site charge, la première étape est gratuite : ouvrez votre site dans un navigateur, ouvrez l’onglet réseau, et regardez ce qui est réellement téléchargé. Vous pourriez être surpris de ce qui se tient devant votre bâtiment.