Optimiser WooCommerce : comment accélérer une boutique lente

Pour optimiser WooCommerce, il faut d’abord comprendre pourquoi une boutique est plus lente qu’un site vitrine : le panier, la commande et le compte client ne peuvent pas être mis en cache, chaque panier rempli sollicite la base de données, et les extensions s’accumulent. La bonne méthode consiste à mesurer, puis à agir dans cet ordre : serveur et PHP, cache de page avec les exclusions propres à WooCommerce, cache objet persistant, base de données (HPOS, actions planifiées), et enfin catalogue, thème et scripts.

Ce guide détaille ces leviers pour accélérer WooCommerce, tels que je les applique sur les boutiques dont je m’occupe : réglages officiels, code commenté et pièges à éviter. Il est à jour pour WordPress 7.1 et les versions récentes de WooCommerce.

Pourquoi une boutique WooCommerce ralentit plus qu’un site vitrine

Un site vitrine peut être servi presque entièrement depuis un cache. Une boutique, non : dès qu’un client remplit son panier, WooCommerce lui ouvre une session et une partie des pages devient personnelle. S’y ajoutent :

• des pages impossibles à mettre en cache : panier, commande, « Mon compte » ;
• des requêtes AJAX (?wc-ajax=) pour l’ajout au panier, les frais de port ou le mini-panier, qui passent toujours par PHP ;
• une base de données qui grossit : commandes, sessions clients, actions planifiées, transients ;
• des extensions (paiement, livraison, avis, marketing) qui ajoutent des requêtes et chargent souvent leurs scripts partout ;
• un catalogue lourd : nombreuses variations, filtres par attribut, grandes images.

L’enjeu dépasse la technique : une boutique rapide améliore l’expérience d’achat, réduit les abandons, favorise la conversion et compte pour le référencement, puisque les Core Web Vitals font partie des signaux d’expérience de page utilisés par Google.

Mesurer avant d’optimiser

Les bons indicateurs

• Le temps de réponse du serveur (TTFB) : le travail de PHP et de la base de données, l’indicateur clé des pages hors cache.
• Le LCP : l’affichage du plus grand élément, souvent l’image produit.
• L’INP : la réactivité aux clics (choix d’une variation, ajout au panier). Il a remplacé le FID dans les Core Web Vitals en mars 2024.
• Le CLS : la stabilité visuelle de la page.

Privilégiez les données terrain (Search Console, PageSpeed Insights quand le trafic suffit) ; les tests en laboratoire (Lighthouse, GTmetrix) servent à comparer avant et après.

Tester les pages qui vendent

L’accueil, presque toujours en cache, ne dit pas grand-chose. Mesurez une catégorie, une fiche produit simple et une variable, le panier, la commande et « Mon compte », puis recommencez avec un produit dans le panier, et une fois connecté à un compte client : c’est là que le cache ne joue plus. Pour le temps de réponse, l’onglet Réseau du navigateur suffit.

Trouver le coupable avec Query Monitor

L’extension Query Monitor affiche pour chaque page les requêtes SQL (lentes, en double, regroupées par extension), les appels HTTP externes et le temps de génération. Utilisez-la sur une copie de préproduction : vous pourrez y désactiver des extensions sans risquer de bloquer des commandes. Un seul appel externe lent (transporteur, licence, synchronisation de stock) peut expliquer un panier qui met plusieurs secondes à s’afficher.

Diagnostic rapide

Le socle serveur : PHP, base de données et ressources

Une version de PHP à jour

Chaque version de PHP apporte des gains de performance, et une version sans correctifs de sécurité n’a pas sa place sur un site qui encaisse des paiements. Les exigences serveur de WooCommerce demandent désormais PHP 8.3 ou plus (testé jusqu’à 8.4), version que WordPress recommande aussi. D’après le calendrier de PHP, PHP 8.2 ne recevra plus aucun correctif de sécurité après le 31 décembre 2026 ; PHP 8.3 en reçoit jusqu’à fin 2027, PHP 8.4 jusqu’à fin 2028. Testez tout changement de version en préproduction, et vérifiez avec votre hébergeur qu’OPcache est actif.

Base de données et mémoire

WooCommerce demande MySQL 8.0 ou plus, ou MariaDB 10.6 ou plus, et une limite de mémoire WordPress d’au moins 256 Mo (constante WP_MEMORY_LIMIT dans wp-config.php, dans la limite permise par l’hébergeur). Plus de mémoire n’accélère pas le site en soi, mais évite les erreurs lors des imports, des exports et sur les écrans d’administration chargés.

Un hébergement dimensionné pour une boutique

Un hébergement performant est la base d’une boutique WooCommerce rapide. Une offre mutualisée d’entrée de gamme suffit à un site vitrine, rarement à une boutique. Ce qui compte : des ressources garanties (processeur, mémoire, processus PHP), Redis disponible, un cache serveur compatible avec WooCommerce, HTTP/2 ou HTTP/3, et la compression Brotli ou Gzip, qu’un bon hébergeur active par défaut. Si votre offre ne permet rien de tout cela, un hébergement dimensionné pour une boutique WooCommerce règle une bonne partie du problème avant même de toucher au site.

Mettre WooCommerce en cache sans casser le panier

Cache de page : ce qu’on cache et ce qu’on exclut

Le cache de page sert le HTML final sans exécuter PHP. Il convient à l’accueil, aux catégories, aux fiches produit et aux contenus. La documentation de WooCommerce demande d’en exclure :

• les pages Panier, Commande et Mon compte ;
• les visiteurs qui portent les cookies woocommerce_cart_hash, woocommerce_items_in_cart ou wp_woocommerce_session_ ;
• les adresses d’ajout au panier (?add-to-cart=) et les requêtes wc-ajax ;
• les sessions _wc_session_, si le cache porte aussi sur la base de données.

WP Rocket exclut automatiquement panier, commande et compte ; LiteSpeed Cache fait de même sur un serveur LiteSpeed ; un cache serveur (Varnish, Nginx) demande d’écrire les règles soi-même. Vérifiez le résultat avec un panier rempli, n’empilez jamais deux caches de page, et méfiez-vous des optimisations JavaScript : la documentation de WooCommerce déconseille de minifier les fichiers JavaScript avec WP Rocket. Après chaque réglage, testez l’ajout au panier, les variations et le paiement.

Le cache objet persistant (Redis)

C’est le levier le plus sous-estimé, car il accélère ce que le cache de page ne couvre pas : panier, commande, compte client, requêtes AJAX et administration. Un cache objet persistant (Redis ou Memcached) conserve d’une page à l’autre le résultat des requêtes que WordPress ne garde sinon que le temps d’une page. Depuis WordPress 6.1, la Santé du site recommande d’en utiliser un quand le volume du site le justifie. Il faut un serveur Redis fourni par l’hébergeur et une extension qui y relie WordPress, comme Redis Object Cache ou le module dédié de LiteSpeed Cache.

Les fragments de panier (wc-cart-fragments)

Le script wc-cart-fragments tient le mini-panier à jour sur les pages en cache grâce à une requête ?wc-ajax=get_refreshed_fragments, elle-même jamais en cache. Le conseil « désactivez les fragments de panier » date de l’époque où il se chargeait partout. Depuis WooCommerce 7.8 (juin 2023), le script ne se charge plus que là où le widget Panier est affiché. Beaucoup de thèmes le rechargent pourtant pour leur mini-panier d’en-tête : ouvrez l’onglet Réseau sur un article de blog et cherchez get_refreshed_fragments.

Si la requête apparaît partout, la meilleure solution est le bloc Mini panier de WooCommerce, qui ne dépend pas de ce script. À défaut, limitez le script aux pages de la boutique. Placez ce code dans une extension « must-use » (par exemple wp-content/mu-plugins/devwp-performance-boutique.php), où s’ajouteront les autres extraits de ce guide, et testez-le d’abord en préproduction.

<?php
/**
 * Plugin Name: Performance de la boutique
 * Description: Réglages de performance WooCommerce (à tester en préproduction).
 */

defined( 'ABSPATH' ) || exit;

/**
 * Ne charge les fragments de panier que sur les pages de la boutique.
 */
function devwp_wc_limiter_cart_fragments() {
	if ( ! function_exists( 'is_woocommerce' ) ) {
		return;
	}
	if ( is_woocommerce() || is_cart() || is_checkout() || is_account_page() ) {
		return;
	}
	wp_dequeue_script( 'wc-cart-fragments' );
}
add_action( 'wp_enqueue_scripts', 'devwp_wc_limiter_cart_fragments', 99 );
add_action( 'wp_print_footer_scripts', 'devwp_wc_limiter_cart_fragments', 1 );

Contrepartie : sur les autres pages, le compteur du mini-panier n’est plus actualisé par le navigateur. Il reste juste si votre cache laisse passer les visiteurs qui ont un panier (cookies ci-dessus) ; sinon, il affiche l’état enregistré dans le cache, souvent un panier vide.

Alléger la base de données WooCommerce

Passer au stockage des commandes HPOS

Historiquement, WooCommerce rangeait les commandes dans wp_posts et wp_postmeta, au milieu des pages et des articles. Le stockage haute performance des commandes (HPOS) les place dans des tables dédiées et indexées (wc_orders, wc_order_addresses, wc_order_operational_data, wc_orders_meta), ce qui allège la liste des commandes, la recherche et l’administration. Il est activé par défaut sur les nouvelles boutiques depuis WooCommerce 8.2 (octobre 2023). Une boutique plus ancienne peut encore utiliser l’ancien stockage : vérifiez-le dans WooCommerce > Réglages > Avancé > Fonctionnalités, rubrique « Stockage des données de commande ». Pour migrer :

1. vérifiez la compatibilité de vos extensions, que WooCommerce signale sur cet écran ;
2. faites une sauvegarde complète ;
3. en préproduction, activez la synchronisation (mode de compatibilité), laissez la copie se terminer, puis basculez sur HPOS ;
4. testez une commande, un remboursement, les e-mails, les exports et la facturation ;
5. reproduisez en production, gardez la synchronisation quelques jours, puis désactivez-la : elle permet de revenir en arrière, mais double les écritures.

Sur une grosse boutique, la synchronisation se lance plus sûrement en WP-CLI avec wp wc cot sync (voir la documentation HPOS).

Surveiller les actions planifiées (Action Scheduler)

WooCommerce et de nombreuses extensions confient leurs tâches de fond à Action Scheduler, une file d’attente stockée en base. Quand je reprends une boutique lente, c’est l’un des premiers écrans que j’ouvre : WooCommerce > État > Actions planifiées. Des milliers d’actions en attente ou échouées signalent une file bloquée ou une extension trop bavarde ; le filtre par crochet (hook) désigne la responsable, à corriger avant toute purge.

Action Scheduler supprime les actions terminées ou annulées au bout d’un mois et, depuis sa version 4.0, les actions échouées au bout de trois mois. Sur une boutique très active, vous pouvez raccourcir la première durée :

/**
 * Conserve les actions planifiées terminées ou annulées 7 jours au lieu d’un mois.
 */
function devwp_wc_retention_actions() {
	return 7 * DAY_IN_SECONDS;
}
add_filter( 'action_scheduler_retention_period', 'devwp_wc_retention_actions' );

WP-Cron, qui déclenche l’essentiel de ces actions, ne s’exécute qu’au rythme des visites. Mieux vaut le désactiver côté visites et le confier au planificateur du serveur. Dans wp-config.php, avant la ligne qui demande de ne plus rien modifier :

define( 'DISABLE_WP_CRON', true );

Puis, dans le panneau de l’hébergeur ou la crontab, une tâche qui s’exécute chaque minute, le rythme prévu par Action Scheduler (chemin à adapter ; sans WP-CLI, la tâche peut appeler wp-cron.php en HTTP) :

* * * * * wp --path=/chemin/vers/wordpress cron event run --due-now --quiet

Sans cette tâche, la constante seule arrêterait les tâches planifiées : vérifiez ensuite que la file avance.

Transients, sessions et variations orphelines

WooCommerce > État > Outils propose des nettoyages intégrés, à lancer après une sauvegarde : transients WooCommerce et données temporaires expirées, variations orphelines (sans produit parent), régénération de la table de consultation de produit (tris et filtres par prix, stock ou note). N’effacez les sessions clients qu’en connaissance de cause : l’outil vide aussi les paniers en cours.

Inutile de chercher des « commandes abandonnées » à supprimer : WooCommerce n’enregistre pas les paniers abandonnés comme des commandes. Ils vivent dans les sessions clients, que la tâche woocommerce_cleanup_sessions purge à leur expiration. Les commandes en attente de paiement sont annulées à la fin du délai « Maintenir le stock » (WooCommerce > Réglages > Produits > Inventaire), si la gestion du stock est activée.

Révisions et options chargées automatiquement

Les révisions concernent les pages et les articles, pas les produits : le type « produit » de WooCommerce ne les gère pas par défaut. Le poids caché se trouve plus souvent dans wp_options : les options chargées automatiquement sont lues à chaque page, et des extensions désinstallées y laissent des lignes. Depuis WordPress 6.6, la Santé du site signale un volume excessif. Nettoyez après une sauvegarde, avec un outil dédié (WP-Optimize ou équivalent) plutôt qu’à l’aveugle en SQL, en identifiant l’extension propriétaire de chaque option.

Catalogue : images, variations, recherche et filtres

Images produit

Compressez vos images et utilisez des formats modernes comme WebP ou AVIF (pris en charge par WordPress depuis la version 6.5), et réglez des tailles adaptées aux vignettes et à l’image principale (Apparence > Personnaliser > WooCommerce > Images du produit dans un thème classique). Le chargement différé convient aux vignettes et à la galerie, pas à l’image principale de la fiche produit, souvent l’élément LCP. Si vous construisez vos fiches avec un constructeur de pages, voyez comment optimiser une fiche produit WooCommerce avec Elementor.

Produits à nombreuses variations

Jusqu’à 30 variations, WooCommerce intègre leurs données dans la page : le choix est instantané, mais la page est plus lourde à générer. Au-delà, il les charge à la demande, en AJAX. Si vos fiches de 20 à 30 variations sont lentes, vous pouvez abaisser ce seuil :

/**
 * Charge les variations à la demande au-delà de 20 (30 par défaut).
 */
function devwp_wc_seuil_variations() {
	return 20;
}
add_filter( 'woocommerce_ajax_variation_threshold', 'devwp_wc_seuil_variations' );

Mesurez l’effet sur l’INP : au-dessus du seuil, chaque choix déclenche une requête et les combinaisons indisponibles ne sont plus grisées à l’avance. Mieux encore, ne créez que les combinaisons réellement vendues.

Recherche et filtres

Les filtres par attribut (taille, couleur) comptent parmi les requêtes les plus coûteuses. Vérifiez que la table de consultation des attributs du produit est utilisée pour filtrer le catalogue (WooCommerce > Réglages > Produits > Avancé), et mesurez toute extension de filtres en AJAX avec Query Monitor avant de l’adopter. Limitez le nombre de produits affichés par page pour réduire le temps de chargement, surtout sur mobile. Pour un très gros catalogue, un moteur de recherche dédié, hébergé à part, peut prendre le relais de la recherche native.

Thème, extensions et scripts

Thème et constructeur de pages

Ce qui compte, c’est ce que le thème charge sur chaque page. Avada ou Elementor peuvent servir une boutique rapide si l’on désactive les modules inutilisés et que l’on n’empile pas les animations. Pour Avada, voyez comment régler les performances d’un site Avada.

Auditer les extensions une par une

Limitez-vous aux extensions essentielles et assurez-vous qu’elles sont compatibles et à jour. Mais le nombre compte moins que ce que fait chacune. En préproduction, désactivez-les une à une en mesurant avec Query Monitor : une seule extension mal conçue peut coûter plus que dix extensions sobres. Surveillez celles qui chargent scripts et styles sur toutes les pages alors qu’elles ne servent qu’à la fiche produit ou à la commande.

Scripts tiers et chargement conditionnel

Pixels publicitaires, outils d’analyse, chat, widgets d’avis : ces scripts tiers dégradent surtout l’INP. Chargez-les en différé (defer, que wp_enqueue_script() sait ajouter depuis WordPress 6.3) et uniquement sur les pages concernées. Pour la méthode, voyez comment charger scripts et styles seulement là où ils servent.

Un CDN, utile ou non ?

Un CDN permet de distribuer vos contenus statiques à travers un réseau de serveurs proches de vos visiteurs. Il est précieux pour une clientèle internationale ; pour une boutique française hébergée en France, le gain est plus modeste et ne remplace aucun des leviers précédents.

Accélérer le tunnel de commande

Le panier et la commande ne sont jamais servis par le cache : chaque affichage, changement de livraison ou code promo exécute PHP. C’est là que se jouent les ventes, et là que serveur, PHP et cache objet font tout le travail.

• Retirez de ces pages les extensions qui n’y servent pas (fenêtres surgissantes, ventes incitatives, scripts marketing).
• N’activez que les moyens de paiement et de livraison réellement proposés : certains interrogent une API externe à chaque calcul.
• Testez avec un vrai panier, connecté et non connecté, en surveillant les appels HTTP dans Query Monitor.
• Depuis WooCommerce 8.3, les nouvelles boutiques utilisent les blocs Panier et Validation de commande ; avant de quitter les anciens shortcodes, vérifiez la compatibilité des extensions qui modifient la commande.

L’espace client fait partie du parcours : voyez aussi comment personnaliser la page de connexion WooCommerce sans l’alourdir.

Quand l’administration WooCommerce est lente

Une administration lente trahit souvent un problème de fond. Les causes habituelles : commandes encore dans wp_posts (HPOS), actions planifiées accumulées, absence de cache objet persistant, API Heartbeat de WordPress sollicitée par plusieurs onglets ouverts toute la journée, statistiques et extensions de rapports qui calculent sur de gros volumes, imports en masse lancés en pleine journée. Query Monitor fonctionne aussi dans l’administration : ouvrez l’écran lent et regardez quelles requêtes et quelles extensions dominent.

Garder une boutique rapide dans la durée

L’optimisation des performances est un processus continu. Une nouvelle extension ou quelques milliers de commandes de plus suffisent à faire glisser les temps de réponse. Sur les boutiques que je maintiens, je m’en tiens à quelques routines : mises à jour testées d’abord en préproduction, surveillance continue, nouvelle mesure des pages clés après chaque changement important, et coup d’œil régulier aux actions planifiées et à la Santé du site.

Si vous préférez déléguer ces contrôles, un suivi de maintenance avec mises à jour testées en préproduction les prend en charge. Gardez en tête que chaque boutique est unique et peut nécessiter des optimisations spécifiques : ce guide donne un ordre de priorité, pas une recette figée.

Questions fréquentes sur l’optimisation de WooCommerce

Votre boutique reste lente malgré ces réglages, ou vous préférez ne pas intervenir vous-même en production ? Vous pouvez faire optimiser votre boutique par un développeur WooCommerce.

Mis à jour en octobre 2026.