Add as a preferred source on Google
Stellen wir uns mal die Situation vor. Dein neuer WooCommerce-Chatbot besteht jeden Test. Er beantwortet Fragen zu Produkten, hilft Käufern beim Vergleichen von Optionen und reagiert so schnell, dass niemand auch nur einen Gedanken an die Leistung verschwendet.
Das Problem tritt erst zutage, wenn im Shop an einem Nachmittag viel los ist. Der Bezahlvorgang dauert plötzlich etwas länger, und die Antwortzeiten steigen langsam an, da die PHP-Threads an ihre Kapazitätsgrenze stoßen. Zunächst sieht die Verlangsamung wie die Folge eines Traffic-Anstiegs aus, doch die Besucherzahlen sind in etwa gleich wie in der Woche zuvor. Was sich geändert hat, ist der Arbeitsaufwand, den der Server bei jedem Besuch bewältigen muss.
Jeder Chatbot-Austausch kann einen Live-API-Aufruf auslösen, der durch WordPress läuft, den Seiten-Cache umgeht und einen PHP-Thread belegt, während der Modellanbieter seine Antwort generiert. Möglicherweise fragt er auch die Datenbank nach Produktdetails, dem Gesprächsverlauf oder anderen Kontextinformationen ab. Der Kunde sieht, wie die Antwort innerhalb von zwei Sekunden eintrifft. Der Server sieht einen Thread, den er während dieser Zeit für nichts anderes nutzen kann.
Diese Infrastrukturfrage lässt sich immer schwerer umgehen. Mit WordPress 7.0 wurde KI über einen anbieterunabhängigen KI-Client in den Kern integriert, zusammen mit der Abilities-API und einem zentralen Connectors-Hub.
Der gleiche Druck kann von Funktionen ausgehen, die auf den ersten Blick ganz anders aussehen. KI-Suche, Produktempfehlungen, personalisierte Inhalte, redaktionelle Tools und Agenten-Integrationen interagieren jeweils auf ihre eigene Weise mit WordPress. Zu wissen, ob sie im Dashboard, im Frontend oder über eine API laufen (und ob ihre Anfragen zwischengespeichert werden können), hilft dir dabei, die benötigten Serverressourcen einzuplanen.
Wie WordPress-KI auf einer Live-Site tatsächlich aussieht
KI in WordPress ist keine einzelne Arbeitslast. Wo die Funktion läuft, wann sie läuft und ob ein Besucher sie auslöst – all das beeinflusst das Infrastrukturprofil.
KI-Chatbots und Support-Assistenten
Das ist die auffälligste Kategorie. Plugins wie AI Engine (mit mehr als 100.000 aktiven Installationen), MxChat und Tidio bringen dialogorientierte Schnittstellen ins Frontend.
Jede Nachricht kann eine dynamische Anfrage auslösen, Kontextdaten abrufen, ein externes Modell aufrufen und Konversationsdaten speichern. Anders als bei der Übermittlung eines Kontaktformulars kann eine einzige Konversation mehrere solcher Anfragen in schneller Folge generieren.
KI-Personalisierung, Empfehlungen und Suche
Personalisierung, Empfehlungen und KI-Suche laufen in der Regel im Frontend. In einem WooCommerce-Shop könnte das bedeuten, Produktvorschläge basierend auf den bereits angesehenen Artikeln eines Käufers anzupassen oder eine Suchanfrage zu interpretieren, anstatt nur den genauen Wortlaut abzugleichen. Der Rest der Seite kann oft aus dem Cache geladen werden, aber diese Ergebnisse müssen dennoch für die einzelne Anfrage generiert werden.
KI-gestützte Inhaltserstellung und redaktionelle Tools
Denk dabei an Tools wie Jetpack AI, Rank Math Content AI, Divi AI und GetGenie. Sie laufen hauptsächlich im WordPress-Dashboard.
Da diese Tools hauptsächlich im WordPress-Dashboard laufen, verlangsamen sie das Laden der Frontend-Seiten in der Regel nicht. Sie können den Server jedoch deutlich belasten, wenn mehrere Redakteure sie gleichzeitig nutzen.
KI-Agenten und MCP-Integrationen
MCP-Integrationen warten nicht darauf, dass jemand die Website besucht. Die MCP-Unterstützung von AI Engine und der offizielle WordPress-MCP-Adapter ermöglichen es einem externen Tool, sich mit WordPress zu verbinden und genehmigte Aufgaben auszuführen, wie das Auslesen von Website-Daten oder das Aktualisieren eines Beitrags. Jede Aufgabe wird als authentifizierte API-Anfrage übermittelt, was eine weitere Quelle für Serveraktivität darstellt, die berücksichtigt werden muss.
Zwei Websites können beide KI nutzen und dennoch sehr unterschiedliche Mengen an Hosting-Ressourcen benötigen. Die eine nutzt sie vielleicht gelegentlich im Editor, um Überschriften vorzuschlagen, während die andere für jeden Käufer Produktempfehlungen generiert. Um die Auswirkungen abzuschätzen, schau dir an, wo die Funktion läuft und wie oft sie eine WordPress-Anfrage auslöst.
Was KI-Funktionen tatsächlich mit deinem Server anstellen
Die Kosten einer KI-Funktion ergeben sich aus der Arbeit rund um die Modellantwort. WordPress muss weiterhin die Anfrage empfangen, den Plugin-Code ausführen, alle erforderlichen Daten abrufen, den externen Anbieter kontaktieren und das Ergebnis zurückgeben. Vier Teile dieses Prozesses haben den größten Einfluss auf die Leistung.
PHP-Threads bleiben länger belegt
Zwischengespeicherte Inhalte können ohne Verwendung eines PHP-Threads bereitgestellt werden. Eine dynamische KI-Anfrage muss jedoch von einem Thread verarbeitet werden, und jeder Thread bearbeitet jeweils nur eine Anfrage. Wenn ein Chatbot zwei Sekunden auf einen externen Anbieter wartet, bleibt der PHP-Thread, der diesen Austausch abwickelt, möglicherweise für diese zwei Sekunden belegt. Wenn gleichzeitige Unterhaltungen alle verfügbaren Threads beanspruchen, landen andere, nicht zwischengespeicherte Anfragen in einer Warteschlange.
Dies ähnelt strukturell den Bot-Traffic-Mustern, die im KI- und Bot-Traffic-Bericht von Kinsta dokumentiert sind. Bots, die Such-, Warenkorb- und andere dynamische Endpunkte ansteuern, reservieren PHP-Threads und erzwingen eine Origin-Verarbeitung. KI-Funktionen tun dasselbe absichtlich – und im Idealfall produktiv. Die Infrastrukturkosten pro Anfrage bleiben vergleichbar.
Mehr Anfragen umgehen den Cache
Viele KI-Antworten sind spezifisch für die Person, die die Anfrage stellt, und können daher nicht einfach für den nächsten Besucher wiederverwendet werden. Die Hauptproduktseite wird vielleicht noch aus dem Cache geladen, aber ein Empfehlungsfeld oder ein KI-Suchergebnis muss separat generiert werden. Je öfter das während eines Besuchs passiert, desto mehr Anfragen muss der Ursprungsserver bearbeiten.
Die Datenbankaktivitäten werden komplexer
Bevor eine Eingabeaufforderung gesendet wird, muss ein Plugin möglicherweise Produktdetails, frühere Nachrichten oder Informationen über den Nutzer aus WordPress abrufen. Da sich die Daten von einer Anfrage zur nächsten ändern, ist es schwieriger, sie zwischenzuspeichern als bei einer normalen Seitenabfrage. Wenn viele dieser Anfragen gleichzeitig eintreffen, erhöhen sie die Datenbankaktivität – gerade dann, wenn die Checkout- und Kontoseiten versuchen, ihre eigenen Aufgaben zu erledigen.
Die Latenz externer APIs wird zum Faktor für die Website-Performance
KI-Plugins müssen oft auf einen Drittanbieter-Dienst warten, bevor sie eine Anfrage abschließen können. Wenn OpenAI drei Sekunden für die Antwort braucht, wartet WordPress ebenfalls – und bei einem synchronen Aufruf tut dies auch der PHP-Thread, der den Vorgang abwickelt. Das Plugin sollte über ein Timeout verfügen, damit ein ins Stocken geratener Aufruf nicht unbegrenzt offen bleibt. Manche Workloads können auch in eine Warteschlange gestellt oder zwischengespeichert werden, obwohl ein Live-Chatbot in der Regel auf den Anbieter warten muss.
WordPress 7.0 selbst liefert ein nützliches Beispiel. Das Kernteam hat die Echtzeit-Zusammenarbeit aus der Version entfernt, nachdem Tests Bedenken hinsichtlich Serverauslastung, Speicherverbrauch und Race Conditions aufkommen ließen. Die Funktion hatte zwar weiterhin ihren Wert, war aber nicht bereit für die Veröffentlichung innerhalb der Leistungsgrenzen, die der WordPress-Kern einhalten musste.
Die drei Hosting-Merkmale, die für KI-fähiges WordPress am wichtigsten sind
KI-Workloads sind dynamisch, auftreten in Spitzen und hängen oft von Diensten außerhalb deiner Hosting-Umgebung ab. Drei Hosting-Eigenschaften entscheiden darüber, ob diese Anfragen begrenzt und diagnostizierbar bleiben oder den Rest der Website beeinträchtigen.
1. Isolierte Container-Architektur
Das kann bei Shared-Hosting ein Problem sein, wo deine Website nicht die einzige ist, die den Server nutzt. Wenn die KI-Aktivität plötzlich sprunghaft ansteigt, kann sie die CPU-, Speicher- und Datenbankressourcen beanspruchen, die anderen Websites auf demselben Server zur Verfügung stehen.
Kinsta betreibt jede WordPress-Website in einem eigenen, isolierten Linux-Container mit einem dedizierten Software-Stack, der Nginx, PHP und MySQL umfasst. Jede Website erhält zudem einen eigenen PHP-Thread und eine eigene Speicherzuweisung. Wenn ein KI-Chatbot plötzlich Dutzende von gleichzeitigen Unterhaltungen verarbeitet, bleibt seine Arbeitslast innerhalb des Containers dieser Website, anstatt Ressourcen zu beanspruchen, die einer anderen Website zugewiesen sind.
Diese Isolierung ist besonders wertvoll für Agenturen. Ein schlecht konfiguriertes KI-Plugin auf einer Kunden-Website kann zwar immer noch die Leistung dieser Website beeinträchtigen, aber das Problem wirkt sich nicht auf den Rest des Portfolios aus.
2. Eine aktuelle PHP-Version und die richtige Konfiguration
PHP 7.4 lässt zwar WordPress 7.0 laufen, ist aber nicht die Version, die du aus Leistungsgründen wählen würdest. PHP 8.x verarbeitet WordPress-Code schneller, sodass die Arbeit rund um eine KI-Anfrage weniger Zeit in Anspruch nimmt und der PHP-Thread schneller wieder verfügbar ist.
Eine neuere PHP-Version kann OpenAI oder Anthropic zwar nicht dazu bringen, schneller zu reagieren, aber sie kann den Aufwand reduzieren, den WordPress vor und nach diesem externen Aufruf leistet. Kinsta unterstützt PHP-Versionen bis einschließlich 8.5 und ermöglicht es dir, die Versionen für einzelne Live- oder Staging-Umgebungen über MyKinsta zu ändern. Wenn du die Änderung zuerst in der Staging-Umgebung testest, kannst du Kompatibilitätskonflikte im KI-Plugin, im Theme oder im benutzerdefinierten Code erkennen.
3. Einblick in die gesamte Anfrage
Leistungsprobleme bei der KI können verschiedene Ursachen haben: den PHP-Code des Plugins, eine Datenbankabfrage, den externen Modellanbieter oder unzureichende Thread-Kapazität. Ohne Daten auf Anforderungsebene können alle vier Ursachen wie eine allgemeine Verlangsamung des Hostings aussehen.
Das APM-Tool von Kinsta trennt diese Komponenten voneinander.
Eine praktische Untersuchung könnte so aussehen:
- Gehe zu Analytics > Performance, um zu überprüfen, wann die Antwortzeiten gestiegen sind.
- Öffne APM > Transaktionen, um die langsamsten Endpunkte und Anfragen zu identifizieren.
- Überprüfe APM > Extern, um Aufrufe an OpenAI, Anthropic oder einen anderen Anbieter zu messen.
- Schau unter APM > Datenbank nach langsamen oder wiederholten Personalisierungsabfragen.
- Sieh dir die Top Server-Cache-Bypässe an, um zu sehen, welche KI-gesteuerten Pfade den Ursprung erreichen.
Sobald du siehst, wo die Zeit verloren ging, hast du einen guten Ausgangspunkt. Eine langsame WordPress-Transaktion erfordert eine andere Lösung als eine überlastete Datenbank oder eine Modell-API, deren Antwort mehrere Sekunden dauert.
KI-Funktionen verändern auch dein Traffic-Profil
KI kann den Bedarf an Infrastruktur in beide Richtungen erhöhen. Deine WordPress-Website sendet mehr Anfragen an Modellanbieter, während automatisierte Systeme mehr Anfragen an deine Website senden.
KI-gestütztes Publizieren kann die Crawling-Fläche einer Website schnell vergrößern. Wenn ein Medienteam seine Produktion von fünf Artikeln pro Woche auf zwanzig erhöht, kommen mehr URLs, interne Links, Archive und Paginierungen hinzu, die Crawler durchforsten können. Die Crawler wissen nicht unbedingt, dass KI bei der Erstellung der Inhalte geholfen hat – und es interessiert sie auch nicht. Sie sehen einfach eine größere, häufiger aktualisierte Bibliothek und kehren zurück, um sie zu crawlen.
Eine Million Anfragen für zwischengespeicherte Seiten belastet einen Server ganz anders als eine Million Anfragen an dynamische URLs. In Kinstas Analyse von mehr als 10 Milliarden Anfragen greifen Crawler wiederholt auf Suchergebnisse, gefilterte Produktseiten, „In den Warenkorb“-Links und ähnliche Endpunkte zu. Jede Anfrage kann den Cache umgehen und Arbeit an PHP und die Datenbank weiterleiten.
Dadurch steht der automatisierte Traffic in Konkurrenz zu den eigenen KI-Funktionen deiner Website. Eine Chatbot-Anfrage und ein Crawler, der auf einen dynamischen Produktfilter zugreift, mögen völlig unterschiedliche Zwecke verfolgen, aber beide können PHP-Threads belegen. Wenn Crawler einen beträchtlichen Teil der verfügbaren Kapazität der Website beanspruchen, bleibt weniger Spielraum für legitime Chatbot-, Such- und Empfehlungsanfragen.
Eine KI-fähige Website braucht genügend Spielraum für die Anfragen, die ihre Besucher tatsächlich stellen. Bot-Kontrollen helfen dabei, diesen zu bewahren. Googlebot benötigt weiterhin Zugriff auf Seiten, die du indexieren lassen möchtest, und vielleicht entscheidest du, dass es sich lohnt, bestimmte KI-Crawler zuzulassen. Der Traffic, den es zu reduzieren gilt, sind wiederholte Zugriffe auf dynamische Endpunkte, die keinen Mehrwert bieten, aber dennoch PHP-Threads blockieren.
Kinsta Bot Protection bietet Steuerungsmöglichkeiten auf Umgebungsebene, um automatisierten Datentraffic zuzulassen, zu überprüfen oder zu blockieren, einschließlich einer separaten Option für KI-Crawler. Die Analysen zeigen, wie Anfragen klassifiziert und bearbeitet werden.
Bot-Analysen sind nur ein Teil des Gesamtbildes. Vergleiche sie mit APM-Traces, Cache-Bypass-Berichten und den häufigsten Client-IPs in MyKinsta. So lässt sich leichter feststellen, ob die Auslastung von deinen eigenen KI-Funktionen oder von externen Crawlern stammt und ob diese Crawler-Anfragen die Ressourcen wert sind, die sie verbrauchen.
Was du prüfen solltest, bevor du eine KI-Funktion zu einer WordPress-Website hinzufügst
Bevor du eine KI-Funktion in die Produktion überführst, teste, wie sie sich auf deiner bestehenden Infrastruktur verhält. Beginne mit diesen fünf Fragen.
1. An welcher Stelle im Anfragezyklus wird dieses Plugin ausgeführt?
Der Anforderungspfad spielt hier eine Rolle. Tools zum Erstellen und Bearbeiten von Inhalten arbeiten in der Regel innerhalb von wp-admin. Kundenorientierte Tools teilen sich die PHP-Kapazität mit dem Rest des Frontends, einschließlich der Checkout- und Kontoseiten. Ein Agent kann beide Pfade umgehen und über die API zugreifen. Überprüfe den Anforderungsablauf des Plugins, bevor du abschätzt, wie viel Kapazität es benötigt.
2. Was kann das Plugin zwischenspeichern?
Finde genau heraus, was das Plugin vom Cache ausschließt. Die Antwort selbst muss möglicherweise dynamisch bleiben, da sie sich je nach Eingabeaufforderung oder Nutzer ändert, aber zugehörige Daten wie der Konversationsstatus, Suchergebnisse oder Empfehlungen können für kurze Zeit wiederverwendbar sein. Ein dedizierter, nicht zwischengespeicherter API-Endpunkt ist wesentlich kostengünstiger als ein Plugin, das die gesamte Produktwebsite dynamisch gestaltet.
3. Was passiert, wenn die externe API langsam ist?
Teste auch einen fehlgeschlagenen Aufruf, nicht nur einen langsamen. Unterbrich vorübergehend die Verbindung in der Staging-Umgebung und beobachte, wann die Anfrage beendet wird. Manche Plugins versuchen es sofort erneut; andere bleiben offen, bis PHP sie abbricht. Wenn mehrere Chatbot-Anfragen das gleichzeitig tun, müssen Checkout- und Kontoanfragen möglicherweise auf einen PHP-Thread warten.
4. Teste zuerst in der Staging-Umgebung, während das APM-Tool läuft
Installiere das Plugin in einer Staging-Umgebung und aktiviere während des Tests das APM-Tool von Kinsta. Simuliere typische Unterhaltungen, Suchanfragen oder Workflows zur Inhaltserstellung, gegebenenfalls auch mit gleichzeitigen Aktivitäten. Überprüfe die Registerkarten Transaktionen, Extern und Datenbank, um festzustellen, wie lange Anfragen dauern und wo diese Zeit verbraucht wird.
5. Ist PHP für die zusätzliche Arbeitslast bereit?
Zeichne auf, wie sich die Staging-Site verhält, bevor du PHP änderst. MyKinsta zeigt an, ob das PHP-Thread-Limit bereits erreicht wird, sowie Daten zur Antwortzeit und zur Speicherauslastung. Stelle die Staging-Umgebung auf eine aktuelle PHP-8.x-Version um, wiederhole dieselben Arbeitsabläufe und vergewissere dich, dass das Plugin weiterhin funktioniert, bevor du die Änderung in der Produktionsumgebung vornimmst.
Die Staging-Umgebung bildet die Produktionsumgebung nicht perfekt nach. Sie kann aber dennoch zeigen, ob das Plugin zu viele Anfragen verursacht, die den Cache umgehen, zu lange auf eine externe API wartet, ressourcenintensive Abfragen ausführt oder zu wenig PHP-Kapazität für den Rest der Website übrig lässt.
Behandle jede KI-Einführung als Infrastrukturänderung
WordPress 7.0 bietet Entwicklern eine Standardmethode zur Integration mit KI-Anbietern und zum Aufruf von Modellen aus WordPress heraus. Der Server muss diese Anfragen jedoch weiterhin verarbeiten, sobald die Funktion live ist.
Bevor du die Hosting-Einstellungen änderst, öffne ein paar APM-Traces. Die Plugin-Liste zeigt nicht, wie viel Arbeit die Website leistet, und die Anzahl der PHP-Threads erklärt nicht, warum eine Anfrage langsam ist. Ein Trace zeigt, ob die Anfrage den Cache umgangen hat, wie lange PHP für die Verarbeitung gebraucht hat und ob die Verzögerung von der Datenbank oder der Modell-API stammt. Anhand dessen kannst du entscheiden, ob das Plugin überarbeitet werden muss oder die Website mehr Kapazität benötigt.
Ein KI-Plugin kann perfekt funktionieren und trotzdem schlecht zur aktuellen Kapazität der Website passen. Bevor du es auf der Kundenwebsite einsetzt, lass APM in der Staging-Umgebung laufen und überprüfe, wie lange die externen API-Aufrufe dauern, welche Anfragen den Cache verfehlen und welche PHP-Version die Umgebung verwendet. Überprüfe diese Zahlen nach dem Launch noch einmal, sobald echter Traffic hinzukommt.
Mit diesen wenigen Überprüfungen kannst du Thread-Belastung, langsame Abhängigkeiten und ressourcenintensive Abfrageverläufe erkennen, bevor sie zu einer trägen Website führen – oder zu einem schwierigen Gespräch mit dem Kunden.
Carlo ist ein leidenschaftlicher Liebhaber von Webdesign und Frontend-Entwicklung. Er beschäftigt sich seit über 10 Jahren mit WordPress, auch in Zusammenarbeit mit italienischen und europäischen Universitäten und Bildungseinrichtungen. Er hat Dutzende von Artikeln und Leitfäden über WordPress geschrieben, die sowohl auf italienischen und internationalen Websites als auch in gedruckten Magazinen veröffentlicht wurden. Du kannst Carlo auf X und LinkedIn finden.
