WooCommerce-Chat-Plugin am Black Friday: Hält es dem Ansturm stand?

Bei normalem Betrieb wirken die meisten Chat-Plugins unauffällig. Der Shop hat 50 Besucher pro Stunde, 5 davon öffnen den Chat, der Aufruf des Sprachmodells dauert 2 Sekunden, und im Backend merkt man von der Last kaum etwas. Dann kommt der Black Friday, und aus 50 werden 800. In derselben Stunde öffnen 80 Besucher den Chat. Der Modellaufruf dauert immer noch 2 Sekunden, aber jetzt laufen 80 davon gleichzeitig im selben PHP-FPM-Pool, der auch die Kasse bedient.

Nicht der Chat bricht zusammen, sondern der Shop. Oder fast: Die Kasse braucht plötzlich 14 Sekunden, die Abbruchquote im Warenkorb steigt, und es kommen E-Mails von Kunden, die nicht bezahlen konnten.

Ich habe Shops dabei zugesehen, wie sie genau das am Black Friday live untersuchen. Um 14 Uhr gilt das Chat-Plugin als Hauptverdächtiger. Um 18 Uhr hat der Shopbetreiber es abgeschaltet. Der Plugin-Anbieter schiebt es aufs Hosting, das Hosting aufs Plugin. Und der Shop verliert am umsatzstärksten Tag des Jahres einen sechsstelligen Betrag.

Dieser Beitrag ist die Analyse vor dem Ernstfall: fünf Dinge, die bei Chat-Plugins unter Spitzenlast schiefgehen, wie Sie sie testen und wie eine Architektur aussieht, die den Tag übersteht.

Warum Chat-Plugins unter Spitzenlast versagen

Fünf typische Fehlerquellen. Die meisten Chat-Plugins haben mindestens zwei davon.

1. Synchrone KI-Aufrufe innerhalb von WordPress

Manche Plugins rufen OpenAI, Anthropic oder ein anderes Modell direkt aus der laufenden WordPress-Anfrage heraus auf: wp_remote_post() an die Modell-API, auf die Antwort warten, sie ans Frontend zurückgeben. Bei normalem Betrieb dauert das 1 bis 3 Sekunden. Unter Last wird die Modell-API selbst langsamer (am Black Friday rufen sie alle auf), und der Aufruf dauert 8 bis 15 Sekunden. Die PHP-FPM-Worker hängen im Warten fest. Der Pool läuft voll. Der übrige Shop-Verkehr stockt.

Wenn ein Chat-Plugin damit wirbt, „zu 100 % auf Ihrem WordPress-Hosting zu laufen, ohne externen Dienst“, ist es genau diese Architektur. Günstig in einem ruhigen Shop. Teuer, wenn es darauf ankommt.

2. Synchrone Webhooks beim Speichern von Produkten

Sie synchronisieren den Katalog in der Nacht vor dem Black Friday neu, 8.000 Produkte. Das Chat-Plugin schickt bei jedem gespeicherten Produkt einen Webhook an sein Backend. Laufen diese Webhooks synchron, wartet jedes wp_update_post im Import auf die Antwort des Webhooks. Aus einem Import von 5 Minuten wird eine Stunde, und so lange ist das Backend des Shops blockiert.

Am schmerzhaftesten zeigt sich das bei Preisänderungen in großen Mengen am Morgen des Sales. Der Shop-Manager klickt auf „30 % Rabatt auf die Kategorie Elektronik“, 1.200 Produkte, und jedes Speichern löst einen synchronen Webhook aus. Das Backend friert ein. Der Rabatt ist erst nach 40 Minuten live, und die Angebotsseite zeigt den Besuchern am Morgen die alten Preise.

3. Neuindizierung bei jeder Produktänderung

Manche Chat-Backends bauen bei jeder Produktänderung den gesamten Embedding-Index neu auf. Bei einem Shop mit 10.000 Artikeln dauert das 10 Minuten. Löst jedes Speichern während einer Massenänderung diesen Vorgang aus, stauen sich im Backend Hunderte vollständige Neuindizierungen. Der Chat arbeitet mit veralteten Daten. Manche Plugins antworten gar nicht mehr, bis die Warteschlange abgearbeitet ist.

4. Ein Widget, das schwere Shop-Daten in den Browser lädt

Das Chat-Widget lädt auf jeder Seite. Das ist in Ordnung. Manche Widgets laden aber umfangreiche Shop-Daten (den kompletten Produktkatalog, Suchindizes) in den Browser, um schneller suchen zu können. Bei 800 Besuchern pro Stunde am Black Friday werden diese Datenpakete 800 Mal pro Stunde heruntergeladen, und zwar pro Seite. Der Speicherbedarf im Browser steigt. Mobile Käufer, die den Großteil des Black-Friday-Verkehrs ausmachen, stoßen an Speichergrenzen. Seiten frieren ein. Besucher springen ab.

5. Datenbanksperren durch gespeicherte Gespräche

Chat-Plugins, die jede Nachricht in wp_options oder wp_postmeta ablegen, erzeugen Schreibkonflikte. Jede Chatnachricht ist ein Schreibvorgang. Der Autoload-Mechanismus der WordPress-Optionen kommt ins Stocken, wenn eine einzelne Option groß wird. Aufgeblähte Autoload-Daten in wp_options bremsen bekanntermaßen so manchen Shop am Black Friday aus, und Gesprächsprotokolle an dieser Stelle machen es schlimmer.

Wie eine Architektur aussieht, die den Tag übersteht

Drei Grundsätze, nichts davon ist exotisch.

1. Der KI-Aufruf läuft außerhalb von WordPress. Das Widget im Shop ist ein schlanker Client, der direkt mit einem Chat-Backend spricht, das getrennt von WordPress betrieben wird. WordPress schickt Produktdaten per Webhook, wenn ein Produkt gespeichert wird, und ist an den Gesprächsanfragen nie beteiligt. PHP-FPM bleibt frei für die Kasse.
2. Webhooks gehen erst am Ende der Anfrage raus, nicht mittendrin. Wird ein Produkt gespeichert, stellt das Plugin den Webhook für die Shutdown-Phase zurück (register_shutdown_function oder Action Scheduler). Das Speichern meldet sich im Backend nach Millisekunden zurück. Der Webhook wird verschickt, nachdem die Antwort beim Nutzer angekommen ist. Massenänderungen laufen in normaler Zeit durch.
3. Die Indizierung ist inkrementell, nicht vollständig. Bei jeder Produktänderung wird nur das geänderte Produkt neu eingebettet und indiziert. Das Backend erledigt 1.200 einzelne Aktualisierungen in Sekunden, statt des kompletten Neuaufbaus, an dem ältere Lösungen hängen blieben.

Es ist dasselbe Muster, mit dem Werbenetzwerke, Analyse-Tools und Zahlungsanbieter den Black Friday überstehen: WordPress schlank halten, die schwere Arbeit aus der Anfrage heraushalten und, wo möglich, abschicken, ohne auf die Antwort zu warten.

Wie Emporiqa mit Spitzenlast umgeht

Das Emporiqa-Plugin folgt den drei Grundsätzen oben.

Das Widget im Shop verbindet sich per HTTPS mit dem Backend von Emporiqa. WordPress ist an keinem Gespräch beteiligt. Ein Kunde öffnet den Chat, stellt eine Frage, und die Antwort kommt vom Backend. Die Last auf WordPress bleibt unverändert.

Produkt-Webhooks beim Speichern werden auf register_shutdown_function verschoben. Das Speichern ist im Backend in normaler Zeit fertig. Der Webhook geht raus, nachdem der Shopbetreiber die Erfolgsmeldung sieht. Massenänderungen laufen in normaler WordPress-Geschwindigkeit.

Indiziert wird pro Produkt. Das Backend bettet das geänderte Produkt neu ein und aktualisiert den Vektorindex an Ort und Stelle. Eine Massenänderung an 1.200 Produkten ergibt 1.200 kleine Aufträge im Backend, keinen Neuaufbau von 10 Minuten.

Der Gesprächsverlauf liegt im Backend von Emporiqa, nicht in wp_options oder wp_postmeta. Die WordPress-Tabellen bleiben sauber.

Wenn beim Speichern von Produkten aufwendige eigene Logik läuft (andere Systeme benachrichtigen, an ein ERP synchronisieren, Caches neu erzeugen), steuern Sie das über den WordPress-Filter:

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);

Setzen Sie DOING_BULK_IMPORT in Ihrem Importskript, führen Sie den Import ohne Chat-Webhooks durch und starten Sie danach eine einzige vollständige Synchronisierung. Der Chat holt den Stand dann in einem Durchgang nach statt in 8.000.

So testen Sie ein Chat-Plugin vor dem Black Friday unter Last

Fünf Tests, alle auf einer Testumgebung. Keiner dauert länger als eine Stunde.

1. Massenimport von Produkten. Importieren Sie 1.000 Produkte per WP-CLI oder Import-Tool. Messen Sie die Dauer einmal mit aktiviertem und einmal mit deaktiviertem Chat-Plugin. Der Unterschied sollte unter 10 % liegen. Ist der Import 50 % langsamer, laufen die Webhooks synchron.
2. Massenänderung von Preisen. Wählen Sie im Backend 500 Produkte aus und ändern Sie den Preis. Messen Sie die Zeit. Gleiche Schwelle: weniger als 10 % langsamer als ohne Plugin.
3. Gleichzeitige Chats. Öffnen Sie Ihren Shop in 20 Browser-Tabs. Öffnen Sie in allen 20 den Chat und schicken Sie innerhalb von 30 Sekunden in jedem eine Nachricht. Die erste Antwort sollte in unter 5 Sekunden da sein, die letzte in unter 8. Stauen sich die Antworten auf 30 Sekunden und mehr, arbeitet das Backend unter Last alles nacheinander ab.
4. Kasse unter Chat-Last. Schließen Sie, während die 20 Chats laufen, in einem 21. Tab eine Bestellung ab. Die Kasse sollte in normaler Zeit durchlaufen. Wird sie spürbar langsamer, teilt sich der Chat die PHP-FPM-Worker mit dem Shop.
5. Prüfung der Datenbank-Schreibvorgänge. Führen Sie wp option list --autoload=yes --format=count vor und nach einem Tag mit vielen Chats aus. Die Zahl der Autoload-Optionen sollte gleich bleiben. Ist sie gestiegen, schreibt der Chat bei jedem Gespräch Autoload-Optionen.

Scheitert ein Test auf der Testumgebung, scheitert er im Live-Shop mit echtem Black-Friday-Verkehr noch deutlicher. Sortieren Sie das Plugin aus, bevor Sie sich festlegen.

Was das nicht leistet

• Zu knappes Hosting ausgleichen. Läuft Ihr Shop auf einem Shared Hosting, das schon an einem normalen Dienstag kämpft, rettet Sie am Black Friday kein Chat-Plugin. Die Architektur oben sorgt dafür, dass der Chat nicht zum Engpass wird. Einen zu schwachen Server kann sie nicht ausgleichen.
• Kostenspitzen beim KI-Modell verhindern. Der Black Friday bringt mehr Gespräche und damit mehr Modellaufrufe. Emporiqa rechnet nach Verbrauch ab: Sie zahlen pro Gespräch und pro von der KI entworfener E-Mail-Antwort, die Sie senden, mit einem Monatslimit, das Sie im Abrechnungsbereich selbst festlegen. Die Spitze ist also planbar. Erhöhen Sie das Limit vor dem umsatzstarken Wochenende, denn ist es erreicht, wird der Chat in Ihrem Shop ausgeblendet. Manche Chat-Plugins rechnen pro Nachricht ohne Obergrenze ab, was an einem vollen Tag teuer werden kann.
• Ihr Team ersetzen. Der Chat beantwortet Routinefragen zu Produkten und legt Artikel selbstständig in den Warenkorb. Der Black Friday bringt aber die ungewöhnlichen Fälle ans Licht: Gilt die Aktion für diesen Artikel? Ein Sonderfall beim Versand? Ein Artikel aus einem Blitzangebot fehlt? Hier muss ein Mensch übernehmen. Ist Ihr Team knapp besetzt, wird die Warteschlange für die Übergabe zum Engpass, nicht der Chat selbst.

Warum dieser Test für Shops mit über 50.000 $ Umsatz an Sale-Tagen am meisten zählt

Für einen kleinen Shop ist ein Chat-Plugin, das am Black Friday langsam wird, ärgerlich. Für einen Shop, der an diesem Tag 50.000 $ und mehr umsetzt, kostet jede Minute mit lahmender Kasse spürbar Umsatz. Fällt der Chat 5 Minuten aus, ist das verkraftbar. Ist die Kasse 30 Minuten lang langsam, weil das Chat-Plugin PHP-FPM auslastet, ist ein sechsstelliger Betrag weg.

Der Lasttest mit fünf Schritten ist eine günstige Versicherung. Führen Sie ihn im Oktober auf der Testumgebung durch, dann wissen Sie im November, welches Plugin den Tag übersteht.

Weitere Beiträge zu WooCommerce und Chat: variable Produkte, Mehrsprachigkeit mit WPML und Polylang und Folgen der HPOS-Umstellung. Die vollständige Einrichtung für WooCommerce beschreibt der Beitrag warum die meisten WooCommerce-Chat-Plugins bei der Architektur danebenliegen. Wenn Sie die Kosten eines langsamen Kassentags gegen die Kosten des Chat-Tools abwägen wollen, bietet die ROI-Analyse einen Ausgangspunkt.

Erstellen Sie ein kostenloses Emporiqa-Konto, ohne Karte, und führen Sie die Lasttests oben durch, bevor der Ansturm kommt. Oder probieren Sie zuerst die Live-Demo aus: Sie läuft in einem gut sortierten Elektronikshop, und der Chat verhält sich bei jedem Sortiment gleich. Hinweise zur Architektur finden Sie auf der Seite Emporiqa für WooCommerce.