WooCommerce Black Friday : Pourquoi votre plugin de chat ralentit votre site

La plupart des plugins de chat semblent bien dans le trafic normal. La boutique reçoit 50 visiteurs par heure, le chat s'ouvre pour 5 d'entre eux, l'appel LLM prend 2 secondes, l'admin remarque à peine la charge. Le Black Friday arrive et ces 50 deviennent 800. Le chat s'ouvre pour 80 sessions dans la même heure. L'appel LLM prend toujours 2 secondes, mais maintenant 80 d'entre eux s'exécutent simultanément dans le même pool PHP-FPM qui sert le paiement.

Le chat ne plante pas. La boutique le fait. Ou presque : le paiement commence à prendre 14 secondes, le taux d'abandon de panier triple, les e-mails d'assistance affluent des acheteurs qui n'ont pas pu payer.

J'ai regardé les boutiques déboguer cela en temps réel le Black Friday. Le plugin de chat est le principal suspect à 14 h. À 18 h le propriétaire de la boutique l'a désactivé. Le fournisseur du plugin de chat blâme l'hébergement. L'hébergement blâme le plugin. La boutique perd six chiffres de GMV le jour le plus occupé de l'année.

Cet article est la pré-mortem. Cinq choses qui vont mal avec les plugins de chat sous charge de pointe, comment les tester et à quoi ressemble une architecture qui survit.

Pourquoi les plugins de chat échouent sous charge de pointe

Cinq motifs d'échec courants. La plupart des plugins de chat souffrent d'au moins deux.

1. Appels LLM synchrones à l'intérieur de WordPress

Certains plugins font l'appel à OpenAI, Anthropic ou quel que soit le modèle de l'intérieur du cycle de requête de WordPress. wp_remote_post() contre l'API du modèle, attendez la réponse, retournez-la au front-end. Dans le trafic normal, l'appel prend 1-3 secondes. Sous charge, l'API du modèle elle-même ralentit (tout le monde l'appelle le Black Friday), l'appel prend 8-15 secondes. Les travailleurs de PHP-FPM sont occupés à attendre. Le pool se remplit. Le reste du trafic de la boutique s'arrête.

Si votre plugin de chat dit qu'il fonctionne « 100 % sur votre hébergement WordPress, aucun service externe requis », c'est l'architecture. Bon marché sur une boutique tranquille. Cher quand cela compte.

2. Envois webhook synchrones à la sauvegarde du produit

Vous resynchronisez le catalogue la veille du Black Friday. 8 000 produits. Le plugin de chat déclenche un webhook à son backend à chaque sauvegarde de produit. Si ces webhooks s'exécutent de manière synchrone, chaque wp_update_post dans l'import attend la réponse webhook. Un import qui devrait prendre 5 minutes en prend une heure. L'admin de la boutique est verrouillé pendant que l'import s'exécute.

Cela se montre le plus douloureusement sur les mises à jour de prix en masse le matin de la vente. Le gestionnaire de magasin appuie sur « appliquer 30 % de réduction à la catégorie Électronique », 1 200 produits, chaque sauvegarde déclenche un webhook synchrone. L'admin gèle. La réduction ne devient pas directe depuis 40 minutes. La page de l'affaire affiche les anciens prix au trafic du matin.

3. Ré-indexation à chaque mise à jour de produit

Certains backends de chat reconstruisent l'index d'incorporation entier quand les produits changent. Sur une boutique avec 10 000 SKU, c'est un travail de 10 minutes. Si le déclencheur s'exécute à chaque sauvegarde pendant une mise à jour en masse, le backend fait la queue pour des centaines de ré-indexations complètes. Le chat devient obsolète. Certains plugins cessent de répondre pendant que la file se vide.

4. Widget côté admin chargeant les ressources de vitrine

Le widget de chat se charge sur chaque page. Raisonnable. Mais certains widgets chargent des ressources de vitrine lourdes (catalogues de produits complets, index de recherche) côté client pour une recherche rapide. Le Black Friday, 800 visiteurs par heure signifie 800 de ces charges utiles téléchargées par heure. Par page. La pression mémoire du navigateur augmente. Les acheteurs mobiles, qui sont la plupart du trafic du Black Friday, frappent les erreurs de mémoire insuffisante. Les pages se figent. Rebonds.

5. Contention de verrouillage de base de données du stockage de conversation

Les plugins de chat qui stockent chaque message dans wp_options ou wp_postmeta créent une contention d'écriture. Chaque message de chat est une écriture. Le mécanisme d'autoload des options de WordPress peut s'étouffer quand une option grandit. L'inflation d'autoload wp_options est un tueur de Black Friday connu ; les journaux de conversation de chat assis là le rendent pire.

À quoi ressemble une architecture qui survit

Trois principes. Aucun d'entre eux n'est exotique.

1. L'appel LLM s'exécute en dehors de WordPress. Le widget sur la vitrine est un client mince qui parle directement à un backend de chat hébergé séparément de WordPress. WordPress envoie les données de produits via webhook à la sauvegarde du produit et ne participe jamais au chemin de la requête de conversation. PHP-FPM est libre de servir le paiement.
2. Les webhooks s'envoient à l'arrêt, pas en ligne. Quand un événement de sauvegarde de produit se déclenche, le plugin fait la queue pour un webhook pour la phase d'arrêt (register_shutdown_function ou Action Scheduler). La sauvegarde retourne à l'admin en quelques millisecondes. Le webhook se vide après que la réponse soit livrée à l'utilisateur. Les sauvegardes en masse se complètent en temps normal.
3. La ré-indexation est incrémentale, pas complète. Chaque mise à jour de produit ré-incorpore et ré-indexe uniquement le produit modifié. Le backend gère 1 200 ré-indexations incrémentielles en secondes, pas la reconstruction de catalogue complète qui a étouffé les anciennes conceptions.

Le motif est le même qui permet aux réseaux publicitaires, aux outils d'analyse et aux processeurs de paiement de gérer le Black Friday : garder WordPress mince, garder le travail lourd hors du chemin des requêtes, tirer et oublier où possible.

Comment Emporiqa gère la charge de pointe

Le plugin Emporiqa est construit autour des trois principes ci-dessus.

Le widget sur la vitrine se connecte au backend d'Emporiqa via HTTPS. WordPress n'est pas en chemin d'aucune conversation. Un chat s'ouvre, une question est posée, la réponse revient du backend. La charge de WordPress est inchangée.

Les webhooks de produit à la sauvegarde sont différés à register_shutdown_function. La sauvegarde retourne à l'admin en temps normal. Le webhook se vide après que l'admin voie le message de réussite. Les sauvegardes en masse s'exécutent à des vitesses normales WordPress.

L'indexation est par produit. Le backend ré-incorpore le produit qui a changé et met à jour l'index de vecteur sur place. Une mise à jour en masse de 1 200 produits entraîne 1 200 petits travaux backend, pas une reconstruction de 10 minutes.

L'historique de conversation vit dans le backend d'Emporiqa, pas dans wp_options ou wp_postmeta. Les tables de WordPress restent propres.

Si vous avez une logique personnalisée lourde lors de la sauvegarde du produit (notification d'autres systèmes, synchronisation avec les ERP, régénération du cache), exposez-la via le filtre WordPress :

add_filter('emporiqa_should_sync_product', function($should_sync, $product) {
    if (defined('DOING_BULK_IMPORT') && DOING_BULK_IMPORT) {
        return false;
    }
    return $should_sync;
}, 10, 2);

Définissez DOING_BULK_IMPORT dans votre script d'import, faites l'import sans déclencher les webhooks de chat, puis exécutez une synchronisation complète unique après. Le chat rattrape en un seul lot au lieu de 8 000.

Comment stress-tester un plugin de chat avant le Black Friday

Cinq tests, tous exécutés sur staging. Aucun ne prend plus d'une heure.

1. Import de produits en masse. Importez 1 000 produits via WP-CLI ou l'outil d'import. Chronométrez l'import avec le plugin de chat activé et désactivé. La différence devrait être inférieure à 10 %. S'il est 50 % plus lent, les webhooks s'exécutent de manière synchrone.
2. Mise à jour de prix en masse. Dans l'admin, sélectionnez 500 produits, appliquez un changement de prix. Chronométrez-le. Même seuil : ralentissement inférieur à 10 % par rapport au plugin désactivé.
3. Sessions de chat simultanées. Ouvrez 20 onglets de navigateur vers votre vitrine. Ouvrez le chat dans les 20, envoyez un message dans chacun en 30 secondes. La première réponse devrait arriver en moins de 5 secondes ; la dernière devrait arriver en moins de 8. Si les réponses s'accumulent à 30+ secondes, le backend est monofilaire sous charge.
4. Paiement sous charge de chat. Pendant que 20 sessions de chat s'exécutent, complétez un paiement dans un 21e onglet. Le paiement devrait se compléter en temps normal. Si le paiement ralentit perceptiblement, le chat partage les travailleurs de PHP-FPM avec la vitrine.
5. Vérification d'écriture en base de données. Exécutez wp option list --autoload=yes --format=count avant et après une journée de chat occupée. Le compte d'autoload devrait être inchangé. S'il a grandi, le chat écrit les options d'autoload à chaque conversation.

Si un test échoue sur staging, il échouera pire en production avec le vrai trafic du Black Friday. Filtrez le plugin avant de vous engager.

Ce que cela ne fait pas

• Survivre à votre hébergement étant sous-dimensionné. Si votre boutique est sur l'hébergement partagé qui a du mal avec le trafic normal du mardi, aucun plugin de chat ne vous sauvera le Black Friday. L'architecture ci-dessus garde le chat d'être le goulot ; elle ne peut pas compenser un serveur sous-alimenté.
• Éliminer les pics de coûts LLM. Le Black Friday signifie plus de conversations, ce qui signifie plus d'appels LLM. Les plans avec des allocations plafonnées dépasseront. Emporiqa publie les taux de dépassement par niveau afin que le pic soit prévisible ; certains plugins de chat facturent au message sans plafond, ce qui peut être cher un jour occupé.
• Remplacer le personnel humain. Le chat ferme les ventes routinières sans surveillance. Le Black Friday présente les cas inhabituels : admissibilité à la promotion, expédition de cas limite, article manquant d'une offre flash. L'escalade humaine est requise. La file d'escalade de l'outil de chat, pas le chat lui-même, devient le goulot si votre équipe d'assistance est à court.

Pourquoi ce test importe le plus pour les boutiques faisant > 50 k$ les jours de vente

Pour une petite boutique, un plugin de chat qui ralentit le Black Friday est ennuyeux. Pour une boutique faisant 50 k$ + le jour, chaque minute de paiement dégradé coûte des revenus mesurables. Une panne de 5 minutes du chat est acceptable. Un ralentissement de 30 minutes du paiement parce que le plugin de chat frappe PHP-FPM est six chiffres partis.

La vérification de stress à cinq tests est une assurance bon marché. Exécutez-la sur staging en octobre, vous saurez en novembre quel plugin survit le jour.

Lecture connexe sur WooCommerce + chat : produits variables, multilingue WPML et Polylang et impact de la migration HPOS. Pour la présentation complète de la configuration WooCommerce, voir pourquoi la plupart des plugins de chat WooCommerce arrivent mal l'architecture. Pour peser le coût d'une journée de paiement lent par rapport au coût de l'outil de chat lui-même, l'analyse du ROI donne un cadre de démarrage.

Essayez la démo en direct à demo.emporiqa.com ou installez le plugin sur une boutique bac à sable et exécutez les tests de stress ci-dessus. Les notes d'architecture sont dans la documentation WooCommerce.