Pourquoi mon site WooCommerce est lent ? Les 7 vraies causes

« Mon site WooCommerce est lent » : c’est la phrase par laquelle commencent la plupart des demandes d’audit que je reçois. La bonne nouvelle, c’est que la lenteur d’une boutique WooCommerce n’a rien de mystérieux. Après des dizaines de boutiques auditées, ce sont presque toujours les mêmes 7 causes qui reviennent, dans des proportions variables. Cet article les passe en revue, avec pour chacune le moyen de vérifier vous-même si elle vous concerne.

Un préalable : « mon site est lent » n’est pas un diagnostic. Avant de corriger quoi que ce soit, il faut mesurer où le temps se perd. Les vérifications ci-dessous sont classées de la plus fréquente à la plus structurelle.

1. Cart fragments : le script qui travaille pour rien

WooCommerce charge wc-cart-fragments.js sur toutes les pages de votre site. Son rôle : mettre à jour l’icône du panier via une requête AJAX vers admin-ajax.php, à chaque chargement de page. Même quand le panier est vide, même sur vos articles de blog. Ces requêtes ne sont pas cacheables : chacune mobilise PHP et votre base de données.

Comment vérifier : ouvrez les DevTools (F12, onglet Réseau), rechargez une page, cherchez wc-ajax=get_refreshed_fragments. Si elle apparaît sur une page sans panier, vous payez cette taxe sur chaque visite.

La correction tient en quelques lignes et le gain est immédiat : je l’ai détaillée dans désactiver cart fragments sans casser le panier.

2. Des plugins qui chargent leurs fichiers partout

Chaque plugin actif peut ajouter ses CSS et JS sur toutes les pages, même là où il ne sert pas. Le plugin de formulaire charge ses scripts sur vos fiches produit, le slider charge les siens au checkout. À 30 plugins, la page d’accueil embarque 80 à 120 requêtes.

Comment vérifier : DevTools, onglet Réseau, filtrez par CSS puis par JS. Comptez. Au-delà de 25-30 fichiers sur une page produit, il y a du ménage à faire. Regardez les noms de dossiers : /plugins/xxx/ vous dit qui charge quoi.

La correction : désenregistrer les assets là où ils sont inutiles (wp_dequeue_script ciblé par type de page), remplacer les plugins les plus bavards, et se méfier des thèmes usines à gaz. C’est un travail de dentelle, mais c’est souvent le plus gros gain sur le poids de page.

3. Une base de données encombrée

Trois coupables habituels côté base : les options autoloadées (chargées sur chaque requête, elles gonflent silencieusement, surtout quand des plugins désinstallés laissent leurs données), les transients expirés qui s’accumulent, et les tables de sessions ou d’Action Scheduler jamais purgées.

Comment vérifier : une requête SQL suffit pour le premier point :

SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload = 'yes';

Sous 800 Ko, tout va bien. Au-delà de 1 Mo, chaque page de votre site paie cette dette. J’ai vu des boutiques à 5 Mo et plus : le détail et les corrections sont dans nettoyer les options autoloadées.

4. Les scripts tiers : analytics, pixels, chats

Google Analytics, pixel Meta, Hotjar, chat en ligne, avis clients : chaque outil ajoute 50 à 150 Ko de JavaScript qui s’exécute sur le fil principal du navigateur, celui-là même qui doit afficher votre page. C’est le premier responsable des mauvais scores INP et Total Blocking Time.

Comment vérifier : PageSpeed Insights, section « Réduisez l’impact du code tiers ». La liste est nominative.

La correction : supprimer les outils que personne ne regarde (soyez honnête), et déplacer les autres hors du fil principal, par exemple avec Cloudflare Zaraz qui exécute ces scripts côté edge. J’ai consacré un article complet aux scripts tiers sur WooCommerce.

5. Un hébergement sous-dimensionné

WooCommerce n’est pas un blog : panier, variations, prix personnalisés et checkout génèrent du contenu dynamique que le cache ne peut pas absorber. Sur un mutualisé à 5 €/mois, le TTFB (le temps que met le serveur à commencer à répondre) s’effondre dès que quelques visiteurs naviguent en même temps.

Comment vérifier : mesurez le TTFB en contournant le cache, par exemple curl -so /dev/null -w "%{time_starttransfer}\n" "https://votre-site.fr/?test=123". Moins de 300 ms : bon. Plus de 600 ms : votre hébergement (ou votre base de données) est un plafond de verre, et aucun plugin ne le percera.

Pendant que vous y êtes : vérifiez votre version de PHP (8.2 minimum, chaque version majeure apporte 10 à 20 % de gains) et la présence d’un cache objet type Redis, dont j’explique l’intérêt dans le cache produit WooCommerce.

6. Un checkout d’ancienne génération

Le checkout en shortcode [woocommerce_checkout], encore majoritaire sur les boutiques de plus de 3 ans, est plus lourd et plus lent que le checkout en blocs. Certaines passerelles de paiement anciennes aggravent le cas en chargeant leurs scripts sur tout le site, alors qu’ils ne servent qu’à l’étape de paiement.

Comment vérifier : regardez le code source de votre page de commande. Si vous trouvez woocommerce-checkout sans structure de blocs, vous êtes en legacy. Et dans l’onglet Réseau, cherchez les scripts de vos passerelles (stripe, paypal…) sur une page qui n’a rien à voir avec le paiement.

La correction : la migration vers le checkout en blocs, en testant d’abord en staging.

7. Un cache mal configuré, ou pas de cache du tout

Le paradoxe WooCommerce : le panier et le checkout ne doivent jamais être cachés (sinon un client voit le panier d’un autre), mais tout le reste doit l’être agressivement. Beaucoup de boutiques sont dans l’entre-deux : soit aucun cache HTML, soit un cache qui casse le panier et qu’on a fini par désactiver.

Comment vérifier : si vous êtes derrière Cloudflare, regardez l’en-tête cf-cache-status de vos pages (DevTools, onglet Réseau, cliquez sur le premier document). DYNAMIC sur toutes vos pages produit = votre HTML n’est jamais servi par le CDN. Sur une boutique que j’ai auditée récemment, 6 % seulement des requêtes étaient servies par le cache : le serveur encaissait tout.

Attention toutefois : un plugin de cache seul ne règle pas les causes 1 à 6, il les masque au mieux. J’ai expliqué pourquoi dans les plugins de cache ne suffisent pas.

Par où commencer ?

Dans l’ordre du meilleur rapport gain/effort : cart fragments (cause 1, une heure de travail), le cache HTML bien configuré (cause 7), les scripts tiers (cause 4), puis le ménage dans les assets et la base de données (causes 2 et 3). L’hébergement et le checkout (causes 5 et 6) sont des chantiers plus lourds, à décider chiffres en main.

C’est exactement le travail de priorisation que fait un audit : mesurer chaque cause sur votre boutique, chiffrer le gain attendu, et vous donner l’ordre d’exécution. Vous pouvez suivre ma méthode d’audit en 15 minutes pour un premier état des lieux, ou passer par l’audit de performance complet si vous voulez le plan d’action détaillé. Et l’ensemble des corrections est décrit dans le guide d’optimisation WooCommerce.

Votre boutique coche plusieurs de ces cases ? Demandez un audit gratuit : vous saurez sous 48h lesquelles vous coûtent vraiment des ventes.