Checkout WooCommerce lent : quoi vérifier

Symptômes

• Plusieurs secondes entre le clic sur Commander et la page de remerciement ou de paiement.
• Le récapitulatif de commande tourne chaque fois que le client modifie l’adresse, le mode de livraison ou une quantité.
• Le checkout est rapide la nuit et lent aux heures de pointe.
• Des erreurs 502 ou 504 ponctuelles au checkout sous la charge.

Causes les plus fréquentes

1. Des appels externes pendant le checkout : tarifs de livraison en temps réel, services de calcul de taxes, validation d’adresse, scoring antifraude, vérifications de stock dans l’ERP, contrôles de licence.
2. Du travail effectué à la création de la commande : e-mails transactionnels envoyés par un serveur de messagerie lent, envois synchrones vers le CRM ou l’ERP, génération de factures PDF.
3. Des requêtes lentes en base de données : tables de métadonnées volumineuses, grande table de sessions, requêtes sur mesure sans index, et pas de cache d’objets persistant.
4. Trop d’actualisations : chaque modification de champ déclenche une mise à jour du récapitulatif qui relance tout ce qui précède.
5. Des workers PHP saturés : les requêtes lentes occupent le pool PHP-FPM et les nouvelles requêtes de commande attendent dans une file.

Diagnostic

1. Mesurez les bonnes requêtes

Ouvrez le panneau Réseau et faites un checkout complet. Notez le temps jusqu’au premier octet (TTFB) de :

• ?wc-ajax=update_order_review (checkout classique, à chaque actualisation)
• ?wc-ajax=checkout (checkout classique, Commander)
• /wp-json/wc/store/v1/cart/... et /wp-json/wc/store/v1/checkout (bloc de validation de commande)

Un update_order_review lent pointe vers la livraison, les taxes et les totaux ; un checkout lent pointe vers la création de la commande, le paiement et tout ce qui y est branché.

2. Décomposez le temps en préproduction

Sur une préproduction avec des données proches de la production, utilisez Query Monitor pour voir, sur la requête lente, les requêtes en base de données (les plus lentes et les doublons), les appels HTTP API avec leur durée et les hooks exécutés. Les appels externes ressortent généralement tout de suite.

3. Trouvez les requêtes lentes en production

Activez le slow log de PHP-FPM (request_slowlog_timeout, par exemple 5 secondes). Pour chaque requête qui le dépasse, PHP-FPM écrit la trace de l’endroit où le code attendait : souvent un curl_exec() dans une extension de livraison ou d’ERP.

4. Vérifiez le côté base de données

Regardez le slow query log, la taille de la table des sessions, les options chargées automatiquement et si un cache d’objets persistant (Redis ou Memcached) est actif et réellement sollicité.

Journaux et vérifications techniques

• Temps du panneau Réseau pour les requêtes du checkout.
• Query Monitor en préproduction : requêtes, appels HTTP API, hooks.
• Slow log et page de statut de PHP-FPM.
• Slow query log de MySQL.
• Journaux de messagerie ou de l’extension SMTP pour les envois lents au moment de la commande.
• Outils → Actions planifiées pour le travail de fond qui prend du retard.

Solutions

• Mettez en cache ou réduisez les appels externes : mettez en cache les réponses des transporteurs et des services de taxes quand leurs conditions le permettent, ajoutez des timeouts et évitez d’appeler des services à chaque modification de champ.
• Sortez le travail de la requête de commande : confiez les synchronisations ERP et CRM à Action Scheduler ; différez les e-mails transactionnels ou envoyez-les via un relais rapide.
• Ajoutez un cache d’objets persistant et vérifiez que les données du checkout ne sont pas vidées à chaque requête.
• Corrigez les requêtes lentes : index pour les recherches sur mesure, nettoyage des sessions expirées et des options chargées automatiquement trop volumineuses.
• Dimensionnez PHP-FPM pour le trafic réel, d’après la mémoire par worker et la concurrence en pointe.

// Envoie les e-mails transactionnels WooCommerce après la réponse plutôt que pendant le checkout.
add_filter( 'woocommerce_defer_transactional_emails', '__return_true' );

Ce qu’il ne faut pas faire

• Ne mettez pas le checkout ou le panier en cache de pages pour les « accélérer » : cela casse les sessions, les nonces et les totaux.
• N’installez pas une deuxième extension de cache : elle ne s’applique pas au checkout.
• Ne supprimez pas les extensions de livraison ou de taxes sans vérifier les règles métier qu’elles appliquent.
• Ne changez pas d’hébergement avant d’avoir mesuré où passe le temps.

Quand faire appel à un expert

Faites appel à un ingénieur quand la partie lente se trouve dans une extension ou du code sur mesure que vous ne pouvez pas modifier sans risque, quand la lenteur n’apparaît qu’avec le trafic réel, ou quand des erreurs de checkout (502/504) commencent à apparaître aux heures de pointe.

Problèmes liés

• WooCommerce / Performance Problèmes d’Action Scheduler dans WooCommerce Actions planifiées en retard, échouées et bloquées : comment la file fonctionne, pourquoi elle s’arrête et comment la réparer sans perdre de travail en attente. →
• WooCommerce / Checkout Le checkout WooCommerce ne fonctionne pas : trouver la cause racine Déterminez d’abord si l’échec se produit avant la requête de commande, pendant celle-ci ou après la réponse de la passerelle. Le panneau Réseau et les journaux PHP montrent généralement quelle couche casse. →
• WooCommerce / Erreurs Conflit d’extensions WooCommerce : comment trouver la cause Partez des preuves (l’erreur, le moment, la requête) et isolez en préproduction par moitiés, pas extension par extension en production. →

Questions fréquentes