Slow site sur WooCommerce - Causes & solutions

Symptômes : comment confirmer le diagnostic

Avant d'agir, confirme de quel type de lenteur il s'agit. Les correctifs ne sont pas les mêmes selon que le temps est perdu côté serveur (TTFB), côté requête base de données (admin lent), ou côté rendu navigateur (LCP/INP).

• Front-office lent : LCP > 2,5 s, TTFB > 600 ms (seuil que Google flag). Le navigateur attend la première réponse HTML.
• Back-office lent : la liste des commandes (wp-admin/edit.php?post_type=shop_order) ou la liste produits met plusieurs secondes à charger. Symptôme classique de table wp_postmeta non indexée ou de wp_actionscheduler_actions gonflée.
• Panier/checkout lents : TTFB élevé spécifiquement sur /panier et /commande, souvent à cause des cart fragments AJAX (wc-cart-fragments.js) rechargés sur chaque page.
• Core Web Vitals en rouge dans Search Console, avec INP dégradé (la métrique d'interactivité qui a remplacé FID en mars 2024 — si un outil te parle encore de FID, il est périmé).
• wp-admin global lent : le Heartbeat (admin-ajax.php toutes les 15 s) et l'object cache absent saturent le serveur sous charge.

Impact business immédiat

La lenteur n'est pas un problème cosmétique : elle attaque directement le chiffre d'affaires et l'acquisition.

• Conversion : au-delà de 3 s de chargement mobile, environ 50 % des visiteurs abandonnent. Chaque produit ajouté au panier qui traîne, c'est un panier perdu.
• SEO : les Core Web Vitals (LCP, CLS, INP) sont un signal de classement. Un TTFB > 600 ms et un LCP > 2,5 s te font reculer sur les requêtes commerciales concurrentielles.
• Coût d'acquisition : tu paies du trafic (Ads, social) qui rebondit avant conversion. Le ROAS s'effondre mécaniquement quand la page d'atterrissage est lente.
• Opérationnel interne : un wp-admin lent ralentit le traitement des commandes par tes équipes — temps perdu multiplié par chaque commande gérée.

Causes classées par probabilité

Sur un WooCommerce typique de quelques milliers de produits empilant 35 à 50 plugins actifs, voici l'ordre dans lequel les causes apparaissent en audit réel.

• 1. wp_options surchargée d'autoload (très fréquent) : des plugins stockent des options autoload=yes chargées à chaque requête. Au-delà de 800 Ko–1 Mo d'autoload, gain immédiat de 200 à 500 ms en nettoyant.
• 2. wp_actionscheduler_actions gonflée (sous-estimé) : des dizaines de milliers d'actions complete/failed jamais purgées ralentissent l'admin et les crons WooCommerce.
• 3. Object cache absent : sans Redis/Memcached, les requêtes répétées et le Heartbeat tapent la base à chaque appel.
• 4. Plugins lourds ou mal codés : hooks template_redirect et filtres de tracking ajoutant 400 à 800 ms par page.
• 5. wp_postmeta volumineuse : ~40 entrées meta par commande, sans HPOS la lecture des commandes scanne une table énorme.
• 6. Thème surchargé (Elementor/Divi mal optimisés) vs thème léger (Storefront, GeneratePress, Blocksy, Kadence, Astra).
• 7. PHP périmé : encore beaucoup de boutiques en PHP 7.4. PHP 8.2/8.3 apporte un gain de débit réel sur le même hardware.
• 8. Hébergement mutualisé saturé : TTFB > 2 s sous charge, RAM < 256 Mo = goulot structurel.
• 9. Images non optimisées (pas de WebP/AVIF, pas de lazy load) et cart fragments rechargés partout.

Diagnostic : les commandes à lancer

Mesure d'abord, corrige ensuite. Installe Query Monitor pour voir où part le temps (onglet Queries by component isole le plugin fautif), puis confirme avec ces commandes côté serveur. La plupart supposent WP-CLI disponible (mutualisé : utilise phpMyAdmin pour les requêtes SQL).

SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS autoload_mb,
       COUNT(*) AS nb_options
FROM wp_options
WHERE autoload = 'yes';

-- Top 20 des options autoload les plus lourdes
SELECT option_name, ROUND(LENGTH(option_value)/1024, 1) AS kb
FROM wp_options
WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 20;

# Compter les actions par statut
wp action-scheduler status

# Nombre de lignes dans la table (souvent le vrai coupable)
wp db query "SELECT status, COUNT(*) FROM wp_actionscheduler_actions GROUP BY status;"

# Purger les actions terminées de plus de 30 jours
wp action-scheduler clean --batch-size=500

php -v                              # vise 8.2 ou 8.3
wp cache type                       # 'Default' = pas d'object cache persistant
redis-cli ping                      # PONG si Redis est dispo
wp eval 'echo WP_MEMORY_LIMIT;'     # vise >= 256M, idéalement 512M+

# Activer le slow query log MySQL puis lire les requêtes > 1s
tail -f /var/log/mysql/mysql-slow.log

# Repérer les pics admin-ajax (Heartbeat) dans le log d'accès
grep 'admin-ajax.php' /var/log/nginx/access.log | grep heartbeat | wc -l

# Mesurer le TTFB brut d'une page produit
curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s  Total: %{time_total}s\n' https://ta-boutique.fr/produit/exemple/

# Voir si HPOS est actif et si les tables sont synchronisées
wp wc hpos status

# Compter les commandes dans l'ancien stockage (wp_posts) vs nouveau (wp_wc_orders)
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_type='shop_order';"
wp db query "SELECT COUNT(*) FROM wp_wc_orders;"

Solutions pas-à-pas

Applique dans cet ordre, du gain le plus rapide au plus structurel. Teste sur un environnement de staging avant la prod, et mesure le TTFB après chaque étape pour valider l'impact réel.

1. Nettoie l'autoload. Désactive le plus gros consommateur identifié par la requête SQL (souvent un plugin de tracking ou de log). Passe son option en autoload='no' ou supprime-la via le plugin Advanced Database Cleaner, puis vide les transients : wp transient delete --all.
2. Purge Action Scheduler. Lance wp action-scheduler clean, puis depuis WooCommerce → Statut → Action Scheduler, supprime les actions failed/complete. Programme un nettoyage récurrent.
3. Active un object cache persistant. Installe le plugin Redis Object Cache (ou WP Redis), connecte Redis, active-le. Le Heartbeat et les requêtes répétées cessent de marteler MySQL. Confirme avec wp cache type → doit afficher 'Redis'.
4. Augmente la mémoire dans wp-config.php, avant la ligne /* That's all, stop editing! */ : define('WP_MEMORY_LIMIT', '512M'); et limite les révisions : define('WP_POST_REVISIONS', 5);
5. Désactive le Heartbeat en admin (snippet via le plugin Code Snippets, pas dans functions.php d'un thème non-enfant) pour soulager admin-ajax.php.
6. Allège les assets WooCommerce. Avec Perfmatters ou Asset CleanUp, décharge wc-cart-fragments.js partout sauf sur les pages panier/checkout, et limite woocommerce-layout.css / woocommerce.css aux pages boutique.
7. Mets en place le cache page. WP Rocket, LiteSpeed Cache ou FlyingPress — mais exclus impérativement /panier, /commande et /mon-compte du cache full-page.
8. Optimise les images : Imagify ou ShortPixel pour générer WebP/AVIF, lazy load activé. Cadre les dimensions e-commerce (vignette 300×300, principale 800×800, zoom 1200×1200) pour éviter le CLS.
9. Migre vers HPOS si pas encore fait (WC 8.2+) : WooCommerce → Réglages → Avancé → Fonctionnalités → active le stockage haute performance des commandes. L'admin commandes lit alors wp_wc_orders (indexée) au lieu de scanner wp_postmeta. Vérifie d'abord la compatibilité de tes extensions avec wp wc hpos status.
10. Passe PHP en 8.2/8.3 et active OPcache côté serveur. Teste les plugins en staging : certains anciens cassent sur les fonctions dépréciées.
11. Ajoute un CDN (Cloudflare) pour servir les assets statiques au plus près du visiteur et abaisser le TTFB géographique.

add_action( 'init', 'bugrescue_stop_heartbeat', 1 );
function bugrescue_stop_heartbeat() {
    wp_deregister_script( 'heartbeat' );
}

Spécificités par version

Les leviers de performance diffèrent selon ta version de WooCommerce. Vérifie la tienne dans WooCommerce → Statut.

• WooCommerce 7.x : HPOS existe mais en bêta/opt-in et toutes les extensions ne sont pas prêtes. Les commandes vivent encore dans wp_posts/wp_postmeta — c'est là que l'admin commandes rame le plus. Optimise wp_postmeta et l'object cache en priorité.
• WooCommerce 8.0–8.1 : transition. HPOS se stabilise mais reste à activer manuellement, en mode synchronisé (double écriture) recommandé avant bascule complète.
• WooCommerce 8.2+ : HPOS est stable et proposé par défaut sur les nouvelles installations. C'est le gain back-office majeur — active-le après contrôle de compatibilité des extensions.
• WooCommerce 9.x : HPOS est la norme. Action Scheduler est plus actif (synchronisation, e-mails, webhooks) : la purge régulière de wp_actionscheduler_actions devient indispensable, sinon la table gonfle vite.
• PHP : sous 7.4, tu laisses du débit sur la table. PHP 8.2/8.3 améliore nettement le throughput à hardware égal. Attention aux extensions anciennes qui cassent sur les fonctions dépréciées — teste en staging.
• WordPress 6.x : INP est la métrique d'interactivité officielle des Core Web Vitals depuis mars 2024. FID est obsolète : tout audit qui le cite encore est à réactualiser.

Quand appeler un expert

Tu peux gérer seul l'autoload, la purge Action Scheduler, le cache et l'optimisation images. Fais-toi accompagner quand le TTFB reste au-dessus de 600 ms après object cache et cache page (problème serveur ou requête SQL profonde), quand la migration HPOS échoue à cause d'une extension incompatible critique pour ton activité, ou quand la lenteur persiste malgré un audit Query Monitor sans coupable évident.

Dans ces cas, un profilage serveur (slow query log, New Relic) et une analyse des hooks personnalisés s'imposent. BugRescue intervient sur ce diagnostic de performance WooCommerce : isolation de la requête lente, optimisation base de données et arbitrage hébergement vs applicatif, sans casser tes fonctionnalités marketing.

FAQ