Your host’s resource report names one file at the top of its list: /wp-admin/admin-ajax.php. Or a speed test of a public page shows an admin-ajax request taking several seconds after everything else has finished. Visitors never go near the dashboard, so why is an “admin” file working this hard on the front end?
Because admin-ajax is not really about the admin. It is the general-purpose door that WordPress plugins and themes have used for years to send background requests, from both the dashboard and public pages. Seeing admin-ajax.php slow to respond, or high admin-ajax requests in the logs, tells you about the messenger, not the sender. Something on your site is calling it, and the task is to find out what, and whether it needs to.
What admin-ajax.php is for
When a page needs to talk to the server without reloading, for example to submit a form, load more posts or record a view, a script in the browser sends a request to admin-ajax.php with a parameter called action. WordPress looks up which plugin or theme registered that action and runs its code.
Two facts explain why these requests matter for speed:
- Each request loads WordPress in full. Core, every active plugin and the theme’s functions file, plus the admin environment, because admin-ajax runs as an admin request even for visitors. Plugin code that only expects to run in the dashboard runs here too.
- They are not cached. Most are POST requests, which page caches and CDNs do not store. Every one reaches PHP and usually the database.
So a page that is served from cache in a fraction of a second can still trigger one or more admin-ajax requests that take far longer, and on a busy site those requests use the same limited server processes as everything else.
Newer code often uses the WordPress REST API instead, under /wp-json/, which avoids loading the admin environment. Plenty of popular plugins still use admin-ajax, and there is nothing wrong with that when it is used sparingly.
Who calls admin-ajax on public pages
On the dashboard side, the WordPress Heartbeat is the best-known caller, and it has its own explainer covering what Heartbeat does and how to limit it. On public pages, these are the usual sources:
| Feature | What it sends | How often |
|---|---|---|
| Post view counters and popular posts lists | A request to record each view | Every page view |
| Pop-up and opt-in plugins | Impression and conversion tracking | Every page view, sometimes more |
| Live search and product filters | A query as the visitor types or filters | Every keystroke or filter change |
| Load more and infinite scroll | The next page of posts or products | Each time the visitor scrolls or clicks |
| Form plugins | Submissions, validation, file uploads | When forms are used |
| Cookie consent and statistics plugins | Logging choices or visits | Every visit |
| Live chat, notifications and “recent sales” widgets | Checks for new messages or events | On a timer, while the page is open |
| Plugins refreshing security tokens on cached pages | A fresh token so forms keep working | Every page view |
The rows to worry about are the ones that fire on every page view or on a timer. A form submission happens rarely; a view counter or a polling widget runs for every visitor.
Finding the caller in your browser
This takes a few minutes and needs nothing installed.
- Sign out, or use a private window, and load an ordinary public page with developer tools showing network activity.
- Filter the list down to
admin-ajaxand reload. Leave the page open for a minute or two to catch anything on a timer. - Click a request. In the Payload tab (called Request in some browsers) find the
actionvalue. The name is often a giveaway, as plugins usually prefix their actions with their own name. - Open the Initiator tab or column. It shows which script sent the request. If the script’s path contains
/wp-content/plugins/, the folder name after it is the plugin. If it contains/wp-content/themes/, it is the theme. - Check the Timing tab to see how long the server took to answer.
Repeat on a few page types: home, a blog post, a product page, a page with a form. Make a short list: action name, plugin, which pages, how often, how long.
When the action name does not help
Search for it. A search for the exact action name plus “WordPress” often finds the plugin’s documentation or support forum. If you have file access, searching the plugins folder for wp_ajax_nopriv_ followed by the action name finds the code that handles it, since that is how plugins register actions for logged-out visitors.
Reading the server side
Access logs show admin-ajax.php requests, but with a catch: POST requests keep the action in the request body, which ordinary logs do not record. You will see the volume and timing, and the page that sent them (the referrer), but not which action. That is why the browser check above comes first.
Logs are still useful for three things:
- Volume over time. A sudden jump after a plugin was installed or a setting changed points at that change.
- Requests with no real visitor behind them. Bursts from a few IP addresses, or requests with odd user agents, may be bots hammering an AJAX endpoint rather than real visitors. Our guide to bot traffic that eats server resources covers how to tell.
- GET requests. Some plugins send admin-ajax requests as GET, with the action visible in the address. Those you can read straight from the log.
Your host may also offer PHP slow logs, which record where long requests spent their time. A slow admin-ajax request will show a plugin path in that trace. The step-by-step approach in how to track down a slow plugin uses those logs alongside other tools.
admin-ajax.php slow: too many requests, or one slow one?
The fix depends on which problem you have.
Many requests
Usually one feature that fires on every page view or on a timer. Options, in order of preference:
- Check the plugin’s settings. Many view counters, pop-ups and statistics plugins let you switch tracking off, sample fewer visits, use the REST API instead, or count with a lighter method.
- Lengthen polling timers. A chat or notification widget checking every few seconds can often check every minute, or only when the visitor interacts.
- Load the feature only where it is used. A filter plugin’s scripts on blog posts serve nobody.
- Question the feature. Do you use the view counts? Does the “recent sales” pop-up bring in orders? If not, removing it removes the requests.
One slow request
The request is doing expensive work, or waiting for something. Because admin-ajax loads every plugin, a slow request can also be slow because an unrelated plugin does heavy work on every load. Test on a staging copy: time the request, deactivate other plugins, time it again. If it speeds up a lot, the extra time belongs to whatever you switched off. If it stays slow, the plugin handling the action is the cause; check its settings, update it, or report it to its developer with the action name and timings.
Things that make it worse
- Blocking admin-ajax.php. Security guides sometimes suggest restricting access to
/wp-admin/. If that includes admin-ajax.php, forms, carts, search and many plugins break for visitors. It must stay reachable. - Assuming it is all Heartbeat. Heartbeat does not run on the public site by default. Front-end admin-ajax traffic almost always comes from other plugins.
- Caching it blindly. Responses are often personal to the visitor or meant to record something. Caching them breaks the feature or shows one visitor’s data to another.
- Fixing the symptom with bigger hosting first. More server capacity helps, but a feature firing pointless requests for every visitor will keep using whatever you give it.
For the broader idea that a plugin can be light in the browser but heavy on the server, the section guide on what makes a plugin heavy is worth a read, and our site speed guide shows where background requests fit among page weight, caching and server time.
Frequently asked questions
Is a high number of admin-ajax requests always a problem?
No. A busy site with working contact forms, a store and live search will naturally send many. It becomes a problem when the requests are slow, when they fire on every page view for a feature nobody uses, or when they push the server against its process limits at busy times. Look at what they are for before deciding.
Why does admin-ajax.php show up on a cached page?
The page cache stores the HTML, but scripts in that page still run in each visitor’s browser and send their own requests after it loads. Those requests go straight to the server and are not cached. That is how a page that loads instantly can still create work on the server for every visit.
Should plugins use the REST API instead of admin-ajax?
For new code, the REST API is generally the better choice because it does not load the admin environment and is easier to work with. Switching an existing plugin is the developer’s job, not yours. If a plugin offers a setting to use the REST API for tracking or counting, it is usually worth trying, then testing the feature.
Can I find which plugin sent a request without technical tools?
The browser’s developer tools are the simplest way, and they are built into every desktop browser. Without them, you can deactivate plugins one at a time on a staging copy and watch your host’s request statistics, but that is slower. Once you know the action name, a quick search usually identifies the plugin.
Tracing callers can turn up more than one culprit, and some sit in plugins you rely on. If you would rather not untangle that alone, our website speed optimisation service includes a third-party script audit and a review of server response time, and any fix is applied only with your approval.
Next in this series: Multilingual WordPress Site Slow? Causes and Fixes
