Optimisation WooCommerce : ce qui ralentit vraiment votre boutique.
Le problème n'est presque jamais les images. C'est le JavaScript inutile, les requêtes base de données qui s'empilent, et un checkout qui décourage vos clients. Voici comment corriger ça.
Les Core Web Vitals, en clair.
Google mesure trois choses sur votre site : la vitesse d'affichage (LCP), la stabilité visuelle (CLS), et la réactivité aux clics (INP). Ces trois métriques influencent votre référencement ET l'expérience de vos clients.
Le temps avant que le contenu principal soit visible. Cible : moins de 2,5 secondes. Sur un WooCommerce mal configuré, c'est souvent 4 à 6 secondes sur mobile.
Est-ce que la page "saute" pendant le chargement ? Des images sans dimensions, des polices qui se chargent tard, des bannières qui apparaissent — tout ça fait fuir les visiteurs. Cible : 0.
Quand un visiteur clique sur "Ajouter au panier", combien de temps avant que quelque chose se passe ? Cible : moins de 200ms. Les scripts lourds bloquent cette réactivité.
Cart fragments : le script qui plombe toutes les boutiques WooCommerce.
wc-cart-fragments.js est chargé par WooCommerce sur chaque page de votre site. À chaque chargement, il envoie une requête AJAX vers admin-ajax.php pour mettre à jour l'icône du panier. Même si le panier est vide. Même sur votre page "À propos".
Ce que ça coûte :
- Une requête HTTP non cachable par page vue
- Du temps serveur consommé pour rien (PHP workers mobilisés)
- Un TTFB gonflé artificiellement
- Sur un site à 10 000 visites/mois : ~300 000 requêtes inutiles par mois
La solution :
Désactiver cart fragments sur les pages non-panier. Le panier se met à jour uniquement quand c'est nécessaire. Le gain est immédiat et mesurable.
add_action('wp_enqueue_scripts', function() { if ( !is_cart() && !is_checkout() ) { wp_dequeue_script('wc-cart-fragments'); } });
22 fichiers CSS, 43 scripts JavaScript — sur une seule page.
C'est ce qu'on trouve sur un WooCommerce typique. Chaque plugin ajoute ses propres fichiers, souvent sur toutes les pages, même quand ils ne servent pas. Un slider sur la home charge son JS sur la page produit. Le formulaire de contact charge son CSS sur le checkout.
Les coupables habituels :
- Page builders (Elementor, Divi) : 200-400 Ko de CSS/JS sur chaque page
- Plugins de réseaux sociaux : scripts externes qui bloquent le rendu
- Google Fonts : chaque famille de police = une requête bloquante
- WooCommerce lui-même : CSS et JS chargés partout, y compris sur les pages non-shop
La solution :
Identifier ce qui se charge sur chaque page et supprimer ce qui ne sert pas. Outil : Perfmatters avec son Script Manager — il permet de désactiver CSS/JS page par page, par type de contenu, par device. C'est chirurgical.
Votre base de données grossit silencieusement.
WordPress stocke tout dans wp_options, wp_postmeta, et wp_posts. Avec le temps, ça s'accumule : révisions d'articles, transients expirés, options de plugins désinstallés, et surtout les fameuses options autoloadées — chargées à chaque requête, même quand elles ne servent plus.
Les symptômes :
- TTFB qui augmente progressivement au fil des mois
- Back-office WooCommerce de plus en plus lent
- Requêtes de recherche produit qui timeout
Ce que je vérifie :
- Le poids des options autoloadées (souvent > 1 Mo)
- Les requêtes lentes via le MySQL Slow Query Log
-
L'état des index sur
wp_postmeta - Les transients expirés qui s'accumulent
Les outils :
Identifier les requêtes lentes et le plugin responsable
Nettoyer les options autoloadées
wp db query pour analyser la base directement
Le cache ne résout pas tout — mais bien configuré, il change tout.
Il y a trois niveaux de cache à mettre en place, dans l'ordre :
Object Cache (Redis)
Le plus impactant pour WooCommerce. Redis stocke en mémoire vive les résultats de requêtes base de données. Au lieu de recalculer les mêmes données à chaque page vue, WordPress les récupère instantanément. Outil : Object Cache Pro + Redis.
Page Cache
Stocke la page HTML complète pour la servir sans exécuter PHP. Efficace pour les pages statiques, mais attention aux pages dynamiques (panier, checkout) qui ne doivent pas être cachées. Outil : WP Rocket ou équivalent.
Edge Cache (CDN)
Le cache est distribué sur des serveurs partout dans le monde. Le visiteur reçoit la page depuis le serveur le plus proche. Outil : Cloudflare APO — conçu spécifiquement pour WordPress.
Le piège classique :
Installer un plugin de cache et considérer que c'est réglé. Un cache mal configuré peut servir une page panier vide à un client qui vient d'ajouter un produit, ou afficher un prix en cache alors que le stock a changé.
Le checkout, c'est là que vous perdez de l'argent.
Le taux moyen d'abandon de panier en e-commerce est de 70% (Baymard Institute, 2024). Les raisons principales : processus trop long, création de compte obligatoire, pas assez de moyens de paiement.
Checkout legacy vs checkout blocs :
Le checkout classique de WooCommerce est un formulaire monolithique qui charge tout en une fois. Le checkout blocs (introduit dans WooCommerce 8.3) est modulaire, plus rapide, et supporte nativement les boutons de paiement express (Apple Pay, Google Pay).
Les gains mesurés :
- Réduction des abandons : -20 à -35% (Baymard Institute)
- Temps de chargement checkout : divisé par 2 en moyenne
- Moins de CSS/JS chargé (le checkout blocs n'embarque que ce dont il a besoin)
Votre hébergement est-il vraiment rapide ?
"Je suis sur un bon hébergeur" ne suffit pas. Ce qui compte :
- TTFB sans cache : si votre TTFB dépasse 500ms sans cache activé, le problème est côté serveur
- PHP workers : combien de requêtes simultanées ? Sur un mutualisé : 2-4. Un WooCommerce à fort trafic en a besoin de 10-20
- Version PHP : PHP 8.2+ minimum. Chaque version majeure apporte 10-20% de gains
- Redis disponible : sans Redis, pas d'Object Cache performant
- Configuration modifiable : pouvez-vous ajuster les limites mémoire, les timeouts, les workers ?
Un hébergement à 5€/mois peut convenir pour un blog. Pour un WooCommerce qui vend, il faut un hébergement qui comprend le e-commerce.
HPOS — le stockage haute performance des commandes.
Depuis WooCommerce 8.2, HPOS (High-Performance Order Storage) est disponible. Au lieu de stocker les commandes dans wp_posts et wp_postmeta (les mêmes tables que les articles de blog), HPOS utilise des tables dédiées et optimisées.
Le résultat :
- Back-office 30 à 50% plus rapide sur les requêtes commandes
- Recherche de commandes instantanée, même avec des milliers de commandes
- Base de données allégée (séparation des données commandes et contenu)
Le problème :
Certains plugins ne sont pas encore compatibles HPOS. La migration nécessite de vérifier chaque plugin, tester en staging, et basculer proprement.
Votre boutique est concernée par au moins un de ces problèmes.
Demandez un audit gratuit — je vous dis exactement ce qui ralentit votre site et ce que ça vous coûte en ventes.