Performance

When admin-ajax Becomes a WordPress Performance Problem

How to spot when admin-ajax is causing unnecessary load, which features are usually responsible, and how to reclaim your server's CPU.

Friday, October 31, 2025 at 5:18 PM
Mechanical Gears Engineering Graphic

If you monitor your website’s server logs or run a waterfall speed test on GTMetrix, you might eventually notice a recurring, heavily delayed request pointing to exactly one file: wp-admin/admin-ajax.php.

Despite its name suggesting it's only meant for backend administrators, admin-ajax.php is heavily utilized on the front lines of many standard WordPress sites. When misused or relied on too heavily by poorly coded plugins, it can rapidly congest your server, burn through CPU capacity, and drastically inflate page load times.

What Does Admin-Ajax Actually Do?

AJAX stands for Asynchronous JavaScript and XML. It is the foundational technology that allows a web page to update small pieces of dynamic data without forcing the entire visual page to reload.

For example, when a user clicks a "Heart" button to like a comment, or when an e-commerce customer clicks "Add to Cart," the site does not refresh entirely. Instead, a tiny JavaScript ping is sent silently in the background directly to the server. The admin-ajax.php file is the traditional WordPress receptionist that catches that request, processes the database change, and silently returns the "Success" status to the browser.

Why Does It Become a Core Bottleneck?

The critical problem with admin-ajax.php is that it cannot be cached.

Because it is purely designed to handle highly dynamic, real-time user requests, server caching rules are explicitly written to completely ignore it. Every single time a request hits admin-ajax.php, the server must forcefully wake up the entire PHP engine and calculate the database response dynamically.

If this happens occasionally (like a user actually adding an item to their cart), it is fine. The catastrophe occurs when plugins abuse the system.

Common Culprits of Ajax Abuse:

  1. "Post View" Counters: If you have a widget that proudly states "This article has been viewed 14,020 times!," the plugin is likely firing an uncacheable ajax request literally every single time an anonymous user loads the page just to tick the counter up by one.
  2. Continuous Heartbeat Pings: The WordPress dashboard uses a "Heartbeat" API to auto-save drafts or tell you if another editor is currently editing the same post. If left unchecked, this heartbeat pings the server relentlessly every 15 seconds.
  3. Chat Plugins & Automated Notifications: If a third-party chat widget refuses to use off-server websockets, it might repeatedly ping your server using ajax just to check if "the admin is currently online."

How to Calm the Ajax Storm

If you notice admin-ajax.php eating more than 500ms on a GTMetrix trace, you must take active debugging steps:

  • Isolate the Culprit: Use the Developer Console in Chrome, navigate to the Network Tab, and specifically filter for admin-ajax. Click the request, look at the Payload or Form Data tab, and identify the action string. That specific string will almost always reveal the exact plugin requesting the data.
  • Throttle the Heartbeat: If the chaos is coming from the backend, you can install a plugin like Heartbeat Control to severely limit the frequency of autosaves, reducing the ping rate from every 15 seconds to every 60 seconds (or disabling it on non-critical pages).

Replacing abusive plugins with lightweight alternatives or offloading heavy dynamic actions to robust, dedicated SaaS applications is the only reliable way to protect your server's CPU from the relentless drain of excessive ajax calls.

Need a calmer WordPress support setup?

See the care plans, review the agency offer, or apply for a launch slot.