WordPress Slow Despite Caching: WP-Cron and admin-ajax

A page cache stores finished HTML and hands it to the next visitors without starting WordPress. That works for everything that looks the same for everyone and is requested via GET: home page, posts, categories. Everything else still ends up at PHP. That includes requests from logged-in users, form and cart actions, REST API calls with a personal context, and three endpoints that run in almost every installation: wp-cron.php, wp-admin/admin-ajax.php, and Heartbeat, which also talks through admin-ajax.php.

Each of these requests occupies a PHP worker while it runs. The pool is limited: the PHP-FPM sample configuration that ships with PHP sets pm.max_children to 5 (PHP source code) and notes that these defaults are meant for a server without much resources. Hosts and distributions set their own values, but the principle stays the same: once all workers are busy, the next request waits in the queue before a single line of PHP runs. How to spot that state on the FPM status page is described in the section on worker saturation.

Visitors notice it exactly where the cache does not help anyway. The home page stays fast, but adding to the cart, searching or submitting a form waits for a free worker. The Time to First Byte of these requests rises while every measurement of the home page stays green. web.dev rates 0.8 seconds (web.dev) or less as a good TTFB; uncached requests are the first to miss that mark under load. How to bring server response time down in a targeted way is covered on the page about TTFB optimization.

With a complete page cache, the problem flips. If the cache serves a page before WordPress reaches init, core does not see that request and cannot trigger anything. On a well-cached website with little backend activity, hours may pass before the next uncached request arrives. The handbook names the consequence itself: if you schedule a task for 2:00 PM and no page loads occur until 5:00 PM, scheduling errors could occur (WordPress Plugin Handbook). Site Health then reports a late scheduled event, together with the note that scheduled posts or automatic updates may not work as intended (WordPress source code).

WP-Cron is therefore busy both too often and too rarely: too often because every run ties up a worker in the middle of visitor traffic, and too rarely because cached page views trigger no run at all. Moving to a system cron, described further down, solves both.

The Plugin Handbook states that all WordPress AJAX requests must be sent to wp-admin/admin-ajax.php (WordPress Plugin Handbook). For extensions and themes this was the easiest way to load data from within a page for a long time. On the frontend it shows up in many places: buttons that load more posts, list filters, live search, view counters, forms, popups with changing content, or a cart counter that is fetched again after every page view.

For the cache, these calls are useless. Most of them go out as POST, and HTTP semantics do not allow a POST request to be satisfied from a stored POST response (RFC 9110). On top of that, admin-ajax.php sends headers that prevent caching (WordPress source code); since version 6.8 (WordPress Code Reference) they include no-store and private regardless of whether anyone is logged in. Even a GET call to this endpoint therefore ends up at PHP.

The math is simple: if every cached page carries an Ajax call that fires on load, every page view causes another PHP request, and one with a full core start at that. The page cache saves the HTML but not the worker. With lists that load more via a button, every follow-up page also runs through PHP individually; which pattern suits long lists is compared in Pagination, load more or infinite scroll.

Heartbeat on the frontend deserves a separate look. Core has dedicated filters for visitors who are not logged in (WordPress source code). If a theme or extension loads Heartbeat on public pages, every open visitor window ticks against admin-ajax.php. Whether that happens shows up in the source of a page viewed in a private window: if heartbeat.min.js or heartbeatSettings appear there, the ticks run for guests too.

The documentation describes the approach itself: set up the system task scheduler and disable WP-Cron in wp-config.php. The note is clear. Without that step, WordPress would continue to run WP-Cron on each page load, which is then no longer necessary and contributes to extra resource usage on the server (WordPress Plugin Handbook).

There are two ways to make the call. The handbook shows fetching wp-cron.php over HTTP, for example with wget. That works everywhere but again runs through the web server and PHP-FPM and occupies a worker there. Where WP-CLI is installed, wp cron event run --due-now is the better fit: the command runs all due events and respects the lock against overlapping runs (WP-CLI documentation). It runs as a separate PHP process on the command line, outside the worker pool, and is not bound by the time limits of web server and proxy.

The interval follows the finest scheduling you need. As an example, the handbook shows a call every 15 minutes (WordPress Plugin Handbook). That is enough for maintenance tasks, but for a post meant to go live at a specific minute it can mean a delay of up to a quarter of an hour. The entry above therefore runs every minute. Each run starts WordPress once on the command line and exits when nothing is due; it does not compete with visitor requests for workers, though it does compete for CPU time and the database.

Two things belong to the switch. First, the cron entry writes its output to a log file rather than into the void; only then does a run that keeps failing get noticed before a scheduled post goes missing. Second, check that the switch works: wp cron event list shows upcoming events with their next run, and calls to wp-cron.php should disappear from the access log. If they remain, an external service or an old cron entry is still calling the file.

The list of admin-ajax actions from the measurement is the work plan. Each action falls into one of three groups, and for each there is a way to bring the cache back into play.

One stumbling block on cacheable pages are nonces, the WordPress security tokens against forged requests. According to the handbook, a nonce can be used as many times as necessary within a 24 hour period (WordPress Plugin Handbook), and after 12 hours (WordPress Plugin Handbook) WordPress generates a new number. If a nonce sits in cached HTML, the calls fail as soon as the page stays in the cache longer than the token is valid. Either the cache lifetime of such pages stays below that, or the token is fetched on demand together with the action that needs it.

For view or click counters, ask whether they really have to be written at the moment of the page view. Often it is enough to take the numbers from the access log or collect them at longer intervals. Every action dropped this way gives the page cache its effect back. How the layers from browser cache via page cache to object cache work together is explained on the page about caching strategies.

At the end of November, both sides of the problem meet. Campaign pages and posts are created days in advance and scheduled for midnight, while more people than usual work in the admin area. With WP-Cron, publication depends on the first uncached request after midnight. On a website whose home page and categories come entirely from the cache, that can take a while; the scheduling errors the handbook describes then hit exactly the night everything has been working toward.

With a system cron running every minute, the post goes live on time. After that, the affected pages have to drop out of the cache and be warmed up again, otherwise visitors see the old home page. How to plan that for the night is described in Sale launch at midnight: warm the cache.

If you would like this list worked through for your own installation, the sequence of measurement, switch and follow-up measurement is on the page about WordPress performance; the measurement alone is part of the performance analysis.