Why AI Plugins Slow WordPress: PHP Workers and Timeouts

An AI plugin slows WordPress when it calls a language model inside the page request and waits for the answer. While it waits, that request holds one of your server’s PHP workers, and a site only has a fixed number of them. A few slow AI calls at once can leave ordinary visitors queuing, which shows up as slow pages, 502 or 504 errors, or a Cloudflare 524. The fix is to move slow calls out of the page request, not to buy a bigger server.

Why one slow call affects the whole site

Most WordPress hosting runs PHP through PHP-FPM. It keeps a pool of worker processes, and each incoming request that needs PHP (a page that is not cached, a checkout, an admin screen, an AJAX or REST call) takes one worker until it finishes. The size of the pool is set by your host, and on smaller plans it is not large.

A normal WordPress page finishes quickly and hands its worker back. An AI feature is different. When a plugin sends a prompt to a model provider with wp_remote_post(), PHP sits and waits for the reply. A language model can take many seconds to answer, longer for long outputs. The worker is busy the whole time, doing nothing but waiting.

If several visitors use a chat widget at once, or a bulk “generate descriptions” job runs while the shop is busy, those waiting requests can take most of the pool. Everyone else queues behind them. Cached pages may still load, which is why the problem often looks random: the home page is fine, but cart, checkout and wp-admin crawl.

How it shows up

• Slow uncached pages only while the AI feature is in use. The site is fine overnight and slow when the chat widget is busy.
• 502 Bad Gateway or 504 Gateway Timeout. The web server in front of PHP gave up waiting for a worker or for a reply.
• Cloudflare error 524. If your site is behind Cloudflare, a 524 means Cloudflare connected to your server but did not get an HTTP response within its proxy read timeout. Cloudflare’s error 524 documentation states the current default and the options.
• wp-admin hangs while content is generated. Common with plugins that write titles, excerpts or product descriptions on save.
• Slow pages for random visitors at odd times. Scheduled AI jobs run through WP-Cron, which by default is triggered by visits to your site, so the job lands on a real visitor’s timing.

How to confirm the cause

1. Look for worker exhaustion. Some hosts show PHP worker usage in their dashboard. If you can read the PHP-FPM log, the message to look for is “server reached pm.max_children setting”. Seeing it at the times the site was slow is strong evidence.
2. Time the AI requests. For anything that runs in wp-admin, install the free Query Monitor plugin, trigger the feature, and open its HTTP API Calls panel. It lists each outgoing request with its URL and how long it took. For a front-end chat widget, open your browser’s developer tools, go to the Network tab, send a message and look at how long the request to your site takes.
3. Use the slow log if you have server access. PHP-FPM can write a stack trace of any request that runs longer than a set time (request_slowlog_timeout and slowlog in the pool config). The trace names the plugin file that was waiting.
4. Know which timeout fired. There are several in the chain: the plugin’s own HTTP timeout, the web server’s timeout for PHP (for example fastcgi_read_timeout on nginx), PHP-FPM’s request_terminate_timeout, and Cloudflare’s. The error you see tells you which layer gave up first.

One common misunderstanding: raising PHP’s max_execution_time often changes nothing here. The PHP manual notes that on Linux the limit counts the script’s own execution time, and time spent on things outside the script, such as stream operations and database queries, is not included. A request waiting on a model’s reply is mostly waiting, so it is usually one of the other timeouts that ends it.

Why bigger limits are not the fix

The tempting response is to raise every timeout and ask the host for more workers. Longer timeouts only let requests wait longer while others queue. More workers each need memory, so the host can only add so many, and slow AI calls will fill a bigger pool too. Those changes buy headroom; they do not remove the cause.

The fix: keep slow calls out of the page request

1. Queue work that does not need an instant answer

Summaries, product descriptions, tagging, translations and anything else that can finish a minute later belongs in a background queue. Action Scheduler is the queue library WooCommerce ships with, and plugins can bundle it on its own. Instead of calling the model when a post is saved, the plugin adds a job to the queue and returns straight away:

add_action( 'save_post_post', function ( $post_id ) {
	if ( wp_is_post_revision( $post_id ) || wp_is_post_autosave( $post_id ) ) {
		return;
	}
	if ( function_exists( 'as_enqueue_async_action' ) ) {
		as_enqueue_async_action( 'mysite_generate_summary', array( $post_id ), 'mysite-ai' );
	}
} );

add_action( 'mysite_generate_summary', function ( $post_id ) {
	// Call the model provider here with wp_remote_post(),
	// then save the result with update_post_meta().
} );

The queue still runs on your server, but in a background request rather than inside a visitor’s page or your editor screen. On a busy site, go one step further: set define( 'DISABLE_WP_CRON', true ); in wp-config.php and have a real server cron job run WP-Cron, or process the queue with wp action-scheduler run. Then background work runs on a schedule you control, not on whoever happens to visit.

2. Stream chat replies instead of waiting for the whole answer

A chat widget does need an answer now. Most model providers can stream the reply as it is generated. Passing that stream to the browser means the visitor sees words appear within moments instead of staring at a spinner, and data keeps flowing, so proxy timeouts are less likely to trip. Streaming through PHP needs output buffering off and, on nginx, response buffering disabled for that route (the X-Accel-Buffering: no header).

Be clear about what streaming does not fix: the PHP worker is still busy for the full length of the reply. It improves the wait the visitor feels; it does not free capacity.

3. Take PHP out of the loop for heavy chat use

If chat is a core feature with real traffic, the cleanest option is a small separate service, such as a serverless or edge function, that receives the visitor’s message, calls the model and streams the answer back. WordPress only supplies the content the bot answers from. Your PHP workers stay free for pages and checkout. Keep the provider’s API key on that service, never in the browser.

4. Do not run a model on the same server as WordPress

Running a language model locally on your WordPress server means it competes with PHP and the database for the same memory and CPU. For a typical small business site, calling a hosted model provider in the background is far kinder to the site than hosting the model next to it.

Australian privacy: customer chats sent overseas

Most model providers process requests outside Australia. If your chat widget or form sends customers’ personal information to one, and the Privacy Act applies to your business (not every small business is covered, so check), that is a cross-border disclosure under Australian Privacy Principle 8. The OAIC’s APP 8 guidelines explain that you must take reasonable steps before disclosing, and that you can remain accountable for how the overseas recipient handles the information.

Before you switch on an AI feature that handles customer messages, read the provider’s terms: where requests are processed, how long they are kept, and whether they are used for training. Say in your privacy policy that chat messages are sent to a third party provider. The OAIC has also published guidance on using commercially available AI products. This is general information, not legal advice.

Getting it built properly

Most of the slowdowns above come from how an AI feature was wired in, not from AI itself. If you want AI features that do not stall your site, with slow work queued, chat answers streamed and customer data handled with care, that is the kind of work we do.

Frequently asked questions

Why does my WordPress site slow down when people use the chatbot?

Each chat message that waits for a model’s reply holds a PHP worker until the reply arrives. With several chats at once, the pool of workers runs low and other uncached requests, such as cart, checkout and wp-admin, wait in line. Queueing or streaming the calls, or moving chat to a separate service, stops this.

Do I need a bigger server for an AI plugin?

Usually not, if the plugin calls a hosted model provider. The model runs on the provider’s hardware. What matters is whether the plugin waits for the reply inside the page request. More workers help a little, but slow calls will fill a larger pool too.

What does Cloudflare error 524 mean on a WordPress site?

Cloudflare reached your server but did not receive a response before its proxy read timeout. On a site with AI features, the usual cause is a request waiting on a slow model reply or queued behind other slow requests. Move the slow work into the background rather than trying to extend the timeout.

Can I send customer chat messages to an overseas AI provider?

Possibly, but if the Privacy Act applies to your business it is a cross-border disclosure under APP 8, so you need to take reasonable steps first and you may stay accountable for what the provider does with the data. Check the provider’s terms on location, retention and training, and update your privacy policy.