Eine WordPress AI workload beanspruchte 27 Sekunden PHP-Zeit
Eine WordPress AI workload zur Erstellung eines einzelnen featured image verbrauchte in einem am 22. Oktober 2026 veröffentlichten Kinsta-Test etwa 27,36 Sekunden kumulative PHP-Verarbeitungszeit. PHP ist die Software, mit der WordPress dynamische requests ausführt, und ein PHP worker ist ein einzelner verfügbarer Serverprozess, der solche Aufgaben verarbeitet. Die Messung ist wichtig, weil jeder an einem synchronen AI request beteiligte worker belegt bleibt, während ein externes Modell die Anfrage verarbeitet und seine Antwort zurückgibt.
WordPress kann über crawler traffic, Plugins, die den AI Client verwenden, und externe Anwendungen, die die Abilities API abfragen, mit künstlicher Intelligenz interagieren. Eine API, also eine application programming interface, ist eine festgelegte Methode, über die Softwaresysteme requests und Ergebnisse austauschen. WordPress stellt die Abilities API bereit, um Aktionen verfügbar zu machen, die Software aufrufen kann, während der AI Client Aufgaben an einen ausgewählten AI provider weiterleitet. Vorgänge wie image generation und audio transcription können mehrere Sekunden dauern und in dieser Zeit die für Besucher und andere automatisierte requests verfügbare worker-Kapazität reduzieren.
Kinsta testete das offizielle WordPress.org AI plugin mit einem konfigurierten Google connector. Der Prozess erforderte einen API key des Providers, die Aktivierung dieses Providers unter Settings > Connectors und die Installation des AI plugin. Das Plugin registrierte abilities wie Image Generation und Editing, die unter Tools > Abilities Explorer sichtbar waren. Anschließend wurde ein neuer Beitrag erstellt und der workflow über dessen Steuerelement Generate featured image gestartet. Kinsta wies darauf hin, dass die Beispiele zu unterschiedlichen Zeitpunkten aufgezeichnet wurden, weshalb die Zeitangaben zwischen den Monitoring-Ansichten variieren. Die Ergebnisse hängen zudem stark von der Antwortzeit des Providers und der Verarbeitung durch das Plugin selbst ab.
Für die Serveranalyse wurden Kinsta APM und access logs verwendet. APM steht für application performance monitoring und zeichnet auf, womit eine Anwendung ihre Ausführungszeit verbringt. Laut Kinsta können Kunden das Tool unter Sites > sitename > APM aktivieren, einen Monitoring-Zeitraum auswählen und später transactions, Plugins, Themes, WordPress hooks, langsame database queries und externe requests untersuchen. Ein access log ist der record des Webservers über eingehende requests, einschließlich der anfragenden IP-Adresse und des User Agent, der angeforderten Adresse, des status code und der gesamten Ausführungszeit. Kinsta stellt access, cache und error logs über sein Dashboard bereit und ermöglicht außerdem den Download von logs über seine Tools für Dateiverwaltung und remote access.
Während eines zweiminütigen APM-Fensters belief sich die PHP-Ausführungszeit insgesamt auf etwa 27 Sekunden, der database server benötigte 271 Millisekunden und externe transactions machten mehr als 19 Sekunden aus. Requests an die Adresse /wp-json, die von der WordPress REST API verwendet wird, waren die langsamsten transactions. Eine REST API ist eine Webschnittstelle, über die Software Daten oder Aktionen anfordert. Die Plugins ai-provider-for-google und ai machten zusammen fast 90 Prozent der aufgezeichneten Dauer aus.
Die Daten zu externen requests zeigten, dass POST requests an generativelanguage.googleapis.com 95,51 Prozent der gesamten Zeit externer transactions ausmachten, während GET requests an denselben Dienst 3,94 Prozent ausmachten. POST requests senden Daten zur Verarbeitung, während GET requests eine Ressource abrufen. Die POST-Aufrufe summierten sich auf mehr als 18 Sekunden. Kinstas APM unterscheidet zwischen der Gesamtdauer – der Summe aller Aufrufe eines endpoint – und der maximalen sowie durchschnittlichen Dauer eines samples. Es meldet außerdem die durchschnittliche Ausführungsrate pro Minute; die Gesamtdauer darf daher nicht mit der Länge eines einzelnen request verwechselt werden.
Der transaction trace zeigte den execution path hinter der image generation. WordPress startete über wp-blog-header.php, und WP_REST_Server leitete den request weiter. Generate_Image.php rief generate_image im WordPress AI image namespace auf, class-wp-ability.php übergab die Ausführung an WP_AI_Client, und PromptBuilder.php stellte die Anweisungen zusammen. GoogleTextGenerationModel.php wandelte sie in einen mit Gemini kompatiblen request um. HttpTransporter.php leitete den Aufruf anschließend über die WordPress HTTP API an WP_Http->request weiter. Dadurch wurde eine synchronous, blocking connection geöffnet, was bedeutet, dass derselbe PHP worker auf Google wartete, anstatt für einen anderen job verfügbar zu werden. Ein im trace erfasster request belegte seinen worker länger als acht Sekunden. APM stellte außerdem einen stack trace bereit, also einen nach Dateien und Codezeilen aufgeschlüsselten record des ausgeführten PHP-Codes.
Die access logs zeigten vier nacheinander ausgeführte Operationen der Abilities API. Bei der prompt generation wurde der Beitragsinhalt an Gemini gesendet; der Vorgang dauerte 5,432 Sekunden. Bei der image generation wurde die daraus entstandene Beschreibung an Googles Imagen-Modell gesendet und 9,795 Sekunden auf den binary oder base64 image payload gewartet, eine Textdarstellung der Bilddaten. Anschließend forderte die alt-text generation Gemini auf, das Bild zu analysieren, und benötigte dafür 11,305 Sekunden. Zum Schluss lud der image import den payload herunter und registrierte ihn innerhalb von 0,839 Sekunden in der WordPress Media Library. Ein nachfolgender GET request rief das fertige JPEG aus dem uploads-Verzeichnis mit 0,000 Sekunden PHP-Zeit ab, weil der Webserver die statische Datei auslieferte, ohne WordPress auszuführen. Auf die in der Analyse angegebenen Werte gerundet benötigten die vier PHP-Operationen insgesamt 27,36 Sekunden.
Die Entwicklertools des Browsers boten eine separate clientseitige Ansicht. Nach dem Öffnen des Network panel und dem Filtern nach background web requests erfasste Kinsta 5,52 Sekunden für die prompt generation, 9,92 Sekunden für die image generation, 7,32 Sekunden für den alt text und 1,79 Sekunden für image download, cropping und die Registrierung in der Media Library. Daraus ergab sich eine gesamte Wartezeit im Browser von 24,55 Sekunden. Diese Zahlen unterscheiden sich von den Messwerten der server logs, weil die Operationen zu unterschiedlichen Zeitpunkten ausgeführt wurden – nicht weil beide Ansichten denselben Durchlauf messen.
Der Test legt keine festen Kosten für jede AI-Funktion fest, demonstriert jedoch die Methode und das Kapazitätsrisiko. Mehrere sich überschneidende blocking jobs können die verfügbaren PHP workers belegen, queues und latency erhöhen und die Wahrscheinlichkeit von timeouts, HTTP 5xx server errors oder downtime steigern. Kinsta kam zu dem Schluss, dass zwei oder drei gleichzeitige Aufgaben ein traditionelles Setup mit begrenzten Ressourcen auslasten könnten. Der tatsächliche Schwellenwert hängt jedoch von der worker-Zuweisung, dem traffic, dem Code und den Antwortzeiten des Providers ab. Auch die bandwidth-Nutzung kann steigen, wenn image payloads übertragen werden.
Websitebetreiber sollten diese Messung in einer staging environment wiederholen, also einer privaten Kopie für Tests, und sowohl server traces als auch Browser-Zeitmessungen untersuchen, bevor sie eine AI-Funktion auf einer stark frequentierten production site bereitstellen. Eine Infrastruktur mit caching, database optimisation und skalierbarer worker-Kapazität kann die Verarbeitungsverzögerung eines externen Modells nicht beseitigen, aber mehr Spielraum für gleichzeitige requests schaffen. Für Organisationen, die ihr Hosting als managed service betreiben lassen möchten, gilt: AEU Hosting bietet durchgehend abgesichertes managed WordPress hosting.