Ajax is a JavaScript-based web technology that helps you to build dynamic and interactive websites. WordPress uses Ajax to power many of its core admin area features such as auto-saving posts, user session management, and notifications.
By default, WordPress directs all Ajax calls through the admin-ajax.php file located in the site’s /wp-admin directory.
Numerous simultaneous Ajax requests can lead to high admin-ajax.php usage, resulting in a considerably slowed down server and website. It’s one of the most common problems faced by many unoptimized WordPress sites. Typically, it manifests itself as a slow website or an HTTP 5xx error (mostly 504 or 502 errors).
In this article, you’ll learn about WordPress’ admin-ajax.php file, how it works, its benefits and drawbacks, and how you can diagnose and fix the high admin-ajax.php usage issue.
Ready to go? Let’s roll out!
What Is the admin-ajax.php File?
The admin-ajax.php file contains all the code for routing Ajax requests on WordPress. Its primary purpose is to establish a connection between the client and the server using Ajax. WordPress uses it to refresh the page’s contents without reloading it, thus making it dynamic and interactive to the users.
Since the WordPress core already uses Ajax to power its various backend features, you can use the same functions to use Ajax on WordPress. All you need to do is register an action, point it to your site’s admin-ajax.php file, and define how you want it to return the value. You can set it to return HTML, JSON, or even XML.
As per WordPress Trac, the admin-ajax.php file first appeared in WordPress 2.1. It’s also referred to as Ajax Admin in the WordPress development community.
The chart above only shows the amount of admin-ajax.php requests, not where they might be coming from. It’s a great way to see when the spikes are occurring. You can combine it with other techniques mentioned in this post to narrow down the primary cause.
You can also use Chrome DevTools to see how many requests are being sent to admin-ajax.php. You can also check out the Timings tab under the Network section to find out how much time it takes to process these requests.
As for finding the exact reason behind high admin-ajax.php usage, there are primarily two main causes: one due to frontend, and the other due to backend. We’ll discuss both below.
How to Debug High admin-ajax.php Usage on WordPress
Third-party plugins are one of the most common reasons behind high admin-ajax.php usage. Typically, this issue is seen on the site’s frontend and shows up frequently in speed test reports.
But plugins aren’t the only culprit here as themes, the WordPress core, the webserver, and a DDoS attack can also be the reason behind high Admin Ajax usage.
Let’s explore them in more detail.
How to Determine the Origin of High admin-ajax.php Usage for Plugins and Themes
Ajax is often used by WordPress developers to create dynamic and interactive plugins and themes. Some popular examples include adding features such as live search, product filters, infinite scroll, dynamic shopping cart, and chat box.
Just because a plugin uses Ajax doesn’t mean that it’ll slow down your site.
Usually, Admin Ajax loads towards the end of the page load. Also, you can set Ajax requests to load asynchronously, so it can have little to no effect on the page’s perceived performance for the user.
As you can see in the WebPageTest report above, admin-ajax.php loads towards the end of the requests queue, but it still takes up 780 ms. That’s a lot of time for just one request.
When developers don’t implement Ajax properly on WordPress, it can lead to drastic performance issues. The above GTmetrix report is a perfect example of such behavior.
You can also use GTmetrix to dig into individual post and response data. You can use this feature to pinpoint what’s causing the issue.
To do that, go to GTmetrix report’s Waterfall tab, and then find and click the POST admin-ajax.php item. You’ll see three tabs for this request: Headers, Post, and Response.
Checking out the request’s Post and Response tabs will give you some hints to find out the reasons behind the performance issue. For this site, you can see clues in the Response tab.
You can see that part of the response has something to do with an input tag with id set to “fusion-form-nonce-656”.
A quick search of this clue will lead you to ThemeFusion’s website, the creators of Avada theme. Hence, you can conclude that the request is originating from the theme, or any of the plugins it’s bundled with.
In such a case, you must first ensure that the Avada theme and all its related plugins are fully updated. If that doesn’t fix the issue, then you can try disabling the theme and see if that fixes the issue.
Unlike disabling a plugin, disabling a theme isn’t feasible in most scenarios. Hence, try optimizing the theme to remove any bottlenecks. You can also reach out to the theme’s support team to see if they can suggest a better solution.
Testing another slow website in GTmetrix led to finding similar issues with Visual Composer page builder and Notification Bar plugins.
Thankfully, if you cannot resolve an issue with the plugin, you most like have many alternative plugins available to try out. For example, when it comes to page builders you could also try out Beaver Builder or Elementor.
How to Determine the Origin of High admin-ajax.php
Sometimes, the Post and Response data presented in speed test reports may not be as clear and straightforward. Here, finding the origin of high admin-ajax.php usage isn’t as easy. In such cases, you can always do it the old-school way.
Disable all your site’s plugins, clear your site’s cache (if any), and then run a speed test again. If admin-ajax.php is still present, then the most likely culprit is the theme. But if it’s nowhere to be found, then you must activate each plugin one-by-one and run the speed tests each time. By process of elimination, you’ll lock down on the issue’s origin.
Tip: Using a staging environment (e.g. Kinsta’s staging environment) is a great way to run tests on your site without affecting your live site. Once you’ve determined the cause and fixed the issue in the staging environment, you can push the changes to your live site.
Diagnosing Backend Server Issues with admin-ajax.php
The second most common reason for high admin-ajax.php usage is the WordPress Heartbeat API generating frequent Ajax calls, leading to high CPU usage on the server. Typically, this is caused because of many users logged into the WordPress backend dashboard. Hence, you won’t see this show up in speed tests.
By default, the Heartbeat API polls the admin-ajax.php file every 15 seconds to auto-save posts or pages. If you’re using a shared hosting server, then you don’t have many server resources dedicated to your site. If you’re editing a post or page and leave the tab open for a significant time, then it can rack up a lot of Admin Ajax requests.
For example, when you’re writing or editing posts, a single user alone can generate 240 requests in an hour!
That’s a lot of requests on the backend with just one user. Now imagine a site where there are multiple editors logged in concurrently. Such a site can rack up Ajax requests rapidly, generating high CPU usage.
That was the situation discovered by DARTDrones when the company was preparing its WooCommerce site for an expected surge in traffic following an appearance on Shark Tank.
Before being featured on the television show, the DARTDrones site was receiving over 4,100 admin-ajax.php calls in a day with only 2,000 unique visitors. That’s a weak requests-to-visits ratio.
Investigators noticed the /wp-admin referrer URL and correctly determined the root cause. These requests were due to DARTDrones’ admins and editors updating the site frequently in anticipation of the show.
WordPress has fixed this Heartbeat API issue partially long ago. For instance, you can reduce the frequency of requests generated by the Heartbeat API on hosts with limited resources. It also suspends itself after one hour of keyboard/mouse/touch inactivity.
High Traffic Due to a DDoS Attack or Spam Bots
Overwhelming your site with a DDoS attack or spam bots can also lead to high admin-ajax.php usage. However, such an attack doesn’t necessarily target increasing Admin Ajax requests. It’s just collateral damage.
If your site is under a DDoS attack, your priority should be to get it behind a robust CDN/WAF like Cloudflare or Sucuri. Every hosting plan with Kinsta includes free Cloudflare integration and Kinsta CDN, which can help you offload your website’s resources to a large extent.
To learn more about how you can protect your websites from malicious attacks like these, you can refer to our in-depth guide on how to stop a DDoS attack.
Summary
WordPress uses Ajax in its Heartbeat API to implement many of its core features. However, it can lead to increased load times if not used correctly. This is typically caused due to a high frequency of requests to the admin-ajax.php file.
In this article, you learned the various causes for high admin-ajax.php usage, how to diagnose what’s responsible for this symptom, and how you can go about fixing it. In most cases, following this guide should get your site back up and running smoothly in no time.
However, in some cases upgrading to a server with higher resources is the only viable solution. Especially for demanding use cases such as ecommerce and membership sites. If you’re running such a site, consider upgrading to a managed WordPress host who is experienced with these types of performance issues.
If you’re still struggling with high admin-ajax.php usage on your WordPress site, let us know in the comments section.
I have WP-rocket, but use a shared hosting.
Would it change anything to my performance to change the HeartBeat rate ?
Hi there,
Thanks for the article. It was sometimes hard to understand but im trying to get the hang of it.
I have issues on our website with high usage of the admin-ajax.php.
lsphp:/home/kgd1q/eluun.nl/wp-admin/admin-ajax.php 96%
As you can see it runs to 96% CPU usage. It results into the ” error to connect to database” message and the website is unreachable for 1 minute.
How can i fix this?
You didn’t even say how to fix it. You just said buy a bigger server.