Il y a un moment que traverse chaque boutique WooCommerce. C’est aux alentours de 500 000 € de chiffre d’affaires annuel, ou quelques milliers de produits actifs, ou une campagne à fort trafic qui casse quelque chose que personne n’avait remarqué en développement.
La boutique cesse de paraître rapide. Les pages panier mettent trois secondes à charger. Les abandons de paiement s’envolent. L’hébergeur dit « vous avez besoin de plus de ressources » et vous propose un forfait supérieur. PageSpeed Insights affiche tout en rouge.
Ajouter des ressources règle rarement le problème de fond. Ce qui le règle vraiment : savoir où WooCommerce ralentit spécifiquement à grande échelle, et quelles sont les sept causes presque toujours responsables.
Le schéma récurrent
Une petite boutique WooCommerce est essentiellement cacheable. Les visiteurs arrivent sur une page de catégorie (en cache), parcourent les produits (en cache), ajoutent au panier (non cacheable à partir de là), passent commande, repartent. Les pages en cache couvrent plus de 90 % du trafic, et le tunnel panier/paiement non cacheable gère une minorité de requêtes suffisamment vite.
À grande échelle, deux choses changent. Premièrement, le catalogue grossit — plus de produits, plus de variations, plus de termes de taxonomie, des requêtes plus lourdes. Deuxièmement, la part du trafic panier/paiement augmente, car les taux de conversion restent globalement stables alors que le nombre de visiteurs a été multiplié. La partie non cacheable de votre site devient le goulot d’étranglement.
Voici ce qui se casse réellement, dans l’ordre approximatif où je le constate lors des audits.
1. Gonflement des options autoloadées dans wp_options
Chaque requête WordPress charge en mémoire toutes les options marquées autoload = yes dans wp_options. Sur un WordPress par défaut, cela représente environ 200 Ko. Sur une boutique WooCommerce vieille de cinq ans avec une douzaine de plugins abandonnés qui n’ont jamais nettoyé derrière eux, cela peut atteindre 30 Mo.
Vérifiez-le avec cette requête SQL :
SELECT option_name, LENGTH(option_value)
FROM wp_options
WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 30;Si l’un des 30 premiers enregistrements dépasse 100 Ko et que vous ne savez pas pourquoi il est autoloadé, il ne devrait presque certainement pas l’être. Les coupables habituels : des résidus de transients qui n’ont jamais expiré, des journaux de tâches cron, des caches d’API tierces, des données de migration de plugins abandonnés.
Passer les pires contrevenants à autoload = no (ou les supprimer entièrement) permet généralement de gagner entre 100 et 300 ms sur chaque page non cachée. C’est le gain de performance le plus important sur la plupart des audits WooCommerce.
2. La catastrophe des requêtes wp_postmeta
WooCommerce stocke la quasi-totalité des données produit — prix, stock, attributs, dimensions, variations — dans wp_postmeta. Un produit avec 12 variations et 8 attributs génère environ 100 lignes dans wp_postmeta. Un catalogue de 500 tels produits représente 50 000 lignes. Un catalogue de 5 000 produits en représente un demi-million.
L’index WordPress par défaut sur wp_postmeta porte sur (post_id, meta_key). Il couvre le schéma « donnez-moi les métas de ce produit ». Il ne couvre pas le schéma typique de WooCommerce « donnez-moi tous les produits où _price est compris entre X et Y », ce qui force des scans complets de la table.
WooCommerce 8.2 a introduit les tables de commandes personnalisées (HPOS), qui déplace les données de commande hors de wp_postmeta entièrement. Activez-le. Pour les données produit, le remède vient soit de :
- Un index supplémentaire :
ALTER TABLE wp_postmeta ADD INDEX (meta_key(32), meta_value(32))— à manier avec précaution sur les grandes tables, mais transformateur sur les pages de catégories avec filtres de prix - Le déplacement des méta-clés fréquemment sollicitées (
_price,_stock_status,_sku) dans une table à plat personnalisée interrogée par vos pages de catégories
3. Les fragments de panier et la surcharge AJAX
WooCommerce met à jour le mini-panier à chaque chargement de page via un appel AJAX vers ?wc-ajax=get_refreshed_fragments. Sur une page mise en cache, cela signifie : la page se charge rapidement (depuis le cache), puis déclenche immédiatement une requête AJAX non mise en cache qui exécute l’intégralité du bootstrap WordPress.
Sur une boutique à fort trafic, ce seul appel génère plus de travail PHP non mis en cache que toutes les autres requêtes réunies. Sur des serveurs limités, c’est la différence entre supporter 1 000 utilisateurs simultanés et s’effondrer à 200.
Deux solutions :
- Désactiver les fragments entièrement sur les pages où le panier n’est pas visible (la plupart des pages de catégories, le blog, les pages de contenu). Un filtre, dix lignes de code.
- Déplacer le compteur du panier côté client : lire depuis un cookie défini lors de l’ajout au panier, afficher le mini-panier uniquement sur les pages panier et commande. Réduit l’appel AJAX à quasiment zéro.
4. La prolifération des extensions sur le panier et la commande
Les pages panier et commande s’exécutent sans mise en cache à chaque requête. Chaque extension qui se greffe sur woocommerce_init, woocommerce_checkout_process ou woocommerce_cart_calculate_fees paie son coût d’exécution complet sur ces pages.
Sur un site WooCommerce typique de 3 ans d’âge, on trouve généralement :
- 3 extensions de panier abandonné (une actuelle, deux laissées en place après des expériences précédentes)
- 2 intégrations de suivi des conversions différentes (une configurée par le marketing, une par le développeur précédent)
- Une extension de coupons qui ajoute 5 requêtes par calcul de panier
- Un calculateur de frais de livraison qui interroge une API distante à chaque chargement de page
L’audit des extensions sur ces deux pages uniquement — ce qui est installé, ce qui est encore activement utilisé, ce qui peut être remplacé par une fonctionnalité native de WooCommerce ou par une seule ligne de code dans le thème — réduit généralement le temps de réponse du panier/de la commande de 30 à 50 %.
5. Le cache d’objets, correctement configuré
La mise en cache des pages (Cloudflare, LiteSpeed, WP Rocket) aide les pages pouvant être mises en cache. Le panier et le tunnel de commande nécessitent un cache d’objets — Redis ou Memcached — pour maintenir des performances élevées sur les pages non mises en cache.
La plupart des boutiques n’en disposent pas, ou l’ont installé mais mal configuré : partagé entre plusieurs sites sans préfixage de clé approprié, sous-dimensionné au point que le cache se vide en permanence, ou avec des groupes spécifiques à WooCommerce (wc_session_id, wc_cart) qui ne sont en réalité pas mis en cache.
Vérifiez avec wp_cache_get_stats() ou en inspectant Redis directement. Un cache d’objets fonctionnel affiche des taux de succès supérieurs à 90 % sur une boutique active. En dessous de ce seuil, vous ne mettez probablement rien d’utile en cache.
6. La dette de régénération des images
Chaque refonte modifie les tailles d’image demandées par le thème. Les boutiques WooCommerce accumulent des dizaines de tailles intermédiaires par image produit — 300×300 pour le premier thème, 400×400 pour le second, 600×450 recadré pour une campagne.
Les fichiers originaux sont généralement en bon état. Le problème réside dans les dizaines de tailles obsolètes encore servies parce que le balisage y fait toujours référence, ou pire, l’image originale servie à 4× la taille affichée parce que la bonne taille n’existe pas.
Auditez avec wp media regenerate après avoir standardisé un ensemble de tailles d’image cohérent dans le thème. La diffusion en WebP via un CDN d’images (Cloudinary, Bunny, ou un CDN avec négociation automatique de format) vous permet de réduire le poids des images de 30 à 60 % supplémentaires sans toucher aux originaux.
7. Le traitement en arrière-plan pour les tâches lourdes
Par défaut, WooCommerce envoie les e-mails de confirmation de commande de manière synchrone, lors de la requête de validation du panier. Le client attend pendant la négociation SMTP. Si votre intégration CRM/ERP est également accrochée à woocommerce_thankyou, le client attend aussi pour cela. Si quoi que ce soit dans cette chaîne expire, la commande a déjà été créée mais le client voit une erreur.
Déplacez tout ce qui n’est pas critique pour la réponse dans ActionScheduler (le système de file d’attente déjà inclus dans WooCommerce) :
- E-mails de confirmation et e-mails administrateur
- Intégrations CRM, ERP et comptabilité
- Synchronisation des stocks vers d’autres canaux
- Renvoi des données analytiques vers tout service autre que le pixel de conversion
Le temps de réponse à la validation du panier passe de 4 à 8 secondes (typique) à moins de 1,5 seconde (réalisable). Et une API tierce lente ne peut plus mettre en échec l’ensemble du tunnel de commande.
L’ordre des opérations
Si vous vous retrouvez face à une boutique lente sans savoir par où commencer, voici l’ordre dans lequel je procéderais :
- Audit des options chargées automatiquement (1 heure, gain individuel le plus important)
- Fragments de panier (1 à 2 heures, impact immédiat sur la vitesse perçue)
- Audit des extensions sur le panier et la caisse (4 à 8 heures, gain réel et mesurable)
- Cache objet (variable selon la configuration de l’hébergeur)
- Traitement en arrière-plan pour les e-mails/intégrations (8 à 16 heures)
- Régénération des images et CDN (travail en parallèle, ne bloque pas le reste)
- Index postmeta (en dernier, nécessite une mise en staging rigoureuse et un plan de retour arrière sur les grandes tables)
Ensemble, sur une boutique que j’ai auditée, ces sept points ont régulièrement permis de réduire le LCP de 4-6 s à moins de 2 s, de doubler le nombre d’utilisateurs simultanés supportés par le même plan d’hébergement, et de faire baisser l’abandon de caisse de quelques points de pourcentage — ce qui, sur une boutique à 500 000 €, représente un chiffre d’affaires bien réel.
Rien de mystérieux là-dedans. Ce sont simplement des optimisations qui n’apparaissent pas dans les guides génériques « accélérer WordPress », parce qu’elles sont spécifiques à WooCommerce.
