« WordPress est lent » n'est pas un diagnostic, surtout sur WooCommerce

Remkus de Vries a publié récemment un texte qui résume bien une frustration que je rencontre chaque semaine en audit. Son titre dit l’essentiel : « WordPress is slow » usually means you stopped looking too early. En français : « WordPress est lent » veut généralement dire que vous avez arrêté de chercher trop tôt.

Sa thèse est simple. « WordPress est lent » n’est pas un diagnostic, c’est l’expression d’une frustration. Un site n’est jamais lent parce qu’une étiquette est posée dessus. Il est lent parce que, quelque part dans la pile, quelque chose fait trop de travail. C’est là que l’analyse commence, pas là qu’elle s’arrête.

Je voulais reprendre cette idée et la pousser là où je travaille tous les jours : les boutiques WooCommerce. Parce que c’est précisément sur WooCommerce que le raccourci « WordPress est lent » fait le plus de dégâts, et que c’est aussi là qu’il est le plus facile à démonter.

Une boutique lente prouve une seule chose

Comme l’écrit Remkus, « un site WordPress lent prouve qu’un site WordPress peut être lent. C’est tout. » Il ne prouve pas que WordPress est lent par nature, ni que toutes les boutiques le sont, ni que les extensions sont automatiquement coupables.

La performance est spécifique. Avant de répondre « c’est lent », il faut savoir : lent où ? Le premier octet (TTFB) ? L’exécution PHP ? Les requêtes en base ? Le cache de page ? Le panier ? Le checkout ? La recherche produit ? L’espace client connecté ? Le back-office ?

Ce sont des problèmes différents, qui demandent des outils différents et des solutions différentes. Tant que vous n’avez pas localisé où passe le temps, vous n’avez rien diagnostiqué. Vous avez décrit votre agacement.

Sur WooCommerce, le travail se cache à des endroits précis

WooCommerce ajoute par-dessus WordPress une couche de travail bien réelle, et donc des endroits bien identifiés où ça coince. Le panier, le checkout et le compte client ne sont par définition pas cachables : ils changent à chaque visiteur. Un plugin de cache de page ne fera donc rien pour eux, et c’est exactement pour ça qu’un plugin de cache ne suffit jamais sur une boutique.

Les vrais coupables sont presque toujours les mêmes : un hébergement sous-dimensionné qui plafonne PHP et MySQL, des requêtes sur postmeta qui ne passent pas à l’échelle quand le catalogue grossit, des options autochargées qui gonflent à chaque chargement de page, des tables techniques qui enflent faute de nettoyage, un thème qui charge ses assets partout, et un front saturé de JavaScript tiers. Aucune de ces causes n’est « WordPress ». Toutes sont des décisions d’implémentation.

L’expérience n’est pas une preuve

Remkus rappelle un point que j’aime beaucoup : « l’expérience n’est pas un substitut à la preuve. » On peut avoir vingt ou trente ans de métier et continuer à confondre une mauvaise implémentation WooCommerce avec une limite intrinsèque de WordPress.

Un argument technique a besoin de mesures, pas de biographie. Sur une boutique, cela veut dire : un TTFB, un taux de hit du cache, un nombre de requêtes SQL par page, un journal des requêtes lentes, un temps d’exécution PHP, un waterfall des ressources, des Core Web Vitals, le poids du payload, le coût du JavaScript. C’est exactement ce que je regarde dans un audit de performance WooCommerce avant d’avancer la moindre conclusion.

Les extensions ne sont pas le problème

Le réflexe classique, c’est « WordPress, et c’est pire avec les plugins ». Remkus le formule mieux que moi : « une extension n’est pas une catégorie de performance, c’est un mécanisme d’empaquetage. »

Le nombre d’extensions n’est pas une métrique. Une extension peut ajouter une micro-fonctionnalité sans aucun impact sur le front, pendant qu’une autre plombe chaque requête. Les bonnes questions ne portent jamais sur le nombre, mais sur le travail : cette extension tourne-t-elle à chaque requête ? Charge-t-elle son CSS et son JavaScript sur toutes les pages ou seulement là où c’est utile ? Interroge-t-elle la base d’une façon qui tient la charge ? Gonfle-t-elle l’autoload ? Contourne-t-elle le cache ? Pénalise-t-elle le checkout, la recherche, le cron, l’API REST ?

Le problème n’a jamais été l’existence des extensions. C’est le travail non maîtrisé. Et ça, ça se mesure, extension par extension.

CMS n’est pas un diagnostic

Dernier raccourci courant : « WordPress, c’est un CMS, pas un framework, donc c’est lent. » C’est une erreur de catégorie. Un CMS peut être rapide, un framework peut être lent, un site statique peut être lent, et une stack JavaScript moderne peut être lente elle aussi. Dire « stack moderne » ne définit rien : ça compare la meilleure version imaginée d’une alternative à la pire version possible de WooCommerce.

WooCommerce peut tourner sur du PHP moderne, derrière un CDN et de l’edge caching, avec un object cache persistant (Redis), des index SQL adaptés, un chargement d’assets sélectif et un budget front strict. Au même titre qu’une appli JavaScript peut expédier trop de scripts ou empiler des appels d’API coûteux. La modernité ne garantit pas la vitesse. La discipline, si.

La bonne question

La question utile n’est donc pas « WooCommerce est-il lent ? ». C’est : quel travail fait cette boutique précise, où ce travail a-t-il lieu, et qu’est-ce qu’on peut supprimer, mettre en cache, différer, optimiser ou déplacer ailleurs ?

Pour citer une dernière fois Remkus : « un site WordPress lent ne prouve pas que WordPress est lent. Il prouve que quelqu’un doit continuer à chercher. » C’est tout mon métier : suivre le travail jusqu’à l’endroit où il se passe, au lieu de m’arrêter à l’étiquette posée sur la plateforme.

Cet article s’appuie sur l’analyse de Remkus de Vries, spécialiste performance WordPress et co-fondateur du WordCamp Europe. Lire l’article original (en anglais) : « WordPress Is Slow » Usually Means You Stopped Looking Too Early.

Vous soupçonnez votre boutique d’être « lente » sans savoir où passe réellement le temps ? Demandez un audit gratuit : localiser le travail est la première chose que je fais dans une optimisation WooCommerce.