Symptôme. Une boutique de vêtements techniques nous a contactés : le panier affichait un délai visible d’environ une seconde à chaque changement de page, même sur les pages qui n’avaient rien à voir avec le tunnel d’achat. Le thème avait été audité, les images optimisées, un cache de page correctement configuré. Et pourtant, cette lenteur persistait sur chaque page du site, y compris le blog.
Diagnostic : les cart fragments, coupables fréquents
WooCommerce utilise un mécanisme appelé « cart fragments » pour maintenir à jour l’affichage du mini-panier sans recharger la page : à chaque chargement, une requête AJAX vers admin-ajax.php régénère les fragments HTML du panier. Ce mécanisme, indispensable pour un affichage cohérent, tourne par défaut sur toutes les pages du site, même celles sans panier visible.
Query Monitor a confirmé le diagnostic : onze requêtes SQL générées uniquement par le calcul des cart fragments, sur des pages de blog qui n’affichaient aucun élément lié au panier. Le correctif consiste à limiter ce mécanisme aux pages qui en ont réellement besoin :
function wpm_disable_cart_fragments() {
if ( is_shop() || is_product() || is_cart() || is_checkout() ) {
return;
}
wp_dequeue_script( 'wc-cart-fragments' );
}
add_action( 'wp_enqueue_scripts', 'wpm_disable_cart_fragments', 20 );Diagnostic : les requêtes de variations produits
Sur les fiches produit avec de nombreuses variations (tailles, couleurs), WooCommerce charge par défaut l’ensemble des données de chaque variation dès l’affichage de la page, sous forme d’un objet JSON parfois volumineux. Sur un produit avec cinquante variations, ce chargement peut représenter plusieurs dizaines de requêtes de metadonnées supplémentaires.
Une piste efficace consiste à activer le chargement des variations via AJAX au moment de la sélection, plutôt qu’au chargement initial de la page, une option que proposent certaines extensions de performance dédiées à WooCommerce.
Diagnostic : les sessions en base de données
WooCommerce stocke les sessions des visiteurs, y compris ceux qui n’ont jamais créé de compte, dans la table wp_woocommerce_sessions. Sur un trafic soutenu sans purge régulière, cette table grossit continuellement, ce qui ralentit les requêtes qui l’interrogent à chaque page :
SELECT COUNT(*) FROM wp_woocommerce_sessions;
DELETE FROM wp_woocommerce_sessions WHERE session_expiry < UNIX_TIMESTAMP();Sur cette boutique, la table comptait plus de 90 000 lignes, dont l’immense majorité correspondait à des sessions expirées jamais nettoyées. WooCommerce programme normalement un nettoyage automatique via WP-Cron, mais celui-ci échoue silencieusement si le cron du site est mal configuré ou surchargé.
Diagnostic : les extensions de livraison
Le dernier goulot venait d’une extension de calcul de frais de livraison en temps réel, qui interrogeait une API externe à chaque changement de quantité dans le panier, sans aucune mise en cache des résultats. Le correctif a consisté à mettre en cache les tarifs par zone et par poids pendant une heure, plutôt que d’interroger l’API à chaque interaction :
function wpm_get_shipping_rate_cached( $zone_id, $weight ) {
$key = "wpm_shipping_{$zone_id}_{$weight}";
$rate = get_transient( $key );
if ( false === $rate ) {
$rate = wpm_call_shipping_api( $zone_id, $weight );
set_transient( $key, $rate, HOUR_IN_SECONDS );
}
return $rate;
}Prévention
- Limitez les cart fragments aux pages où le panier est réellement visible.
- Planifiez un nettoyage régulier de
wp_woocommerce_sessions, même si WooCommerce le prévoit déjà en théorie. - Vérifiez chaque extension qui appelle une API externe pendant le tunnel d’achat : sans cache, elle devient un point de ralentissement critique.
- Auditez les fiches produit à fort nombre de variations séparément des fiches simples : leur profil de performance diffère.
Sur une boutique, chaque milliseconde gagnée dans le tunnel d’achat se traduit directement en chiffre d’affaires, pas seulement en score d’audit.
En résumé
Ces quatre points couvrent la majorité des cas de lenteur WooCommerce que nous rencontrons : cart fragments mal ciblés, variations trop lourdes au chargement, sessions jamais purgées, et appels externes non mis en cache. Aucun ne nécessite de changer d’hébergement, tous demandent en revanche un diagnostic précis avant correction.
