CentrioHost Blog

A very common scenario when dealing with WordPress is diagnosing high admin-ajax.php usage. If you have been working with WordPress for a while, you have most likely encountered this when running speed tests or checking your server access logs. This is generally caused by 3rd party plugins or from frequent un-cachable admin dashboard requests, due to the Heartbeat API, such as autosaving drafts. It is important though that you diagnose high admin-ajax.php spikes when you see them, as they have been known to bring a site to a crawl. Check out the following recommendations below on some ways to tackle the admin-ajax.php issue in WordPress.

• What is the admin-ajax.php File?
• Plugins Can Cause admin-ajax.php to Spike
• CPU Issues with admin-ajax.php on Back-end

What is the admin-ajax.php File?

The admin-ajax.php file itself is not a bad thing when used correctly. It is part of core, and was added by the WordPress development team in version 3.6. The purpose of admin-ajax.php is to create a connection between the browser and the server using AJAX. This allows for extended functionality such as improving auto-saving, revision tracking, login timeouts, session management, and notifications about a post being locked when there are multiple editors. Which are all great features, especially for those working with multiple admins and authors.

The idea is to have a relatively simple API that sends XHR requests to the server every 15 seconds and triggers events (or callbacks) on receiving data. Other components would be able to “hitch a ride” or get notified about another user’s activities. This can be used to block simultaneous editing of widgets and menus or any other tasks that require regular updates from the server. — Make WordPress Core

And for those of you who perhaps aren’t as tech-savvy, your only exposure to admin-ajax.php might simply be that you are trying to figure out why it is slowing down your speed tests in tools such as Pingdom (as seen in the example below). Or you might be seeing tons of requests to it in your host’s access logs.

Seeing admin-ajax.php in speed tests and access logs are typically the result of two different scenarios happening, one front-end, and the other back-end, of which we will dive into below.

1. Plugins Can Cause admin-ajax.php to Spike

The first and most common issue that people see with admin-ajax.php is those generated from 3rd party plugins. This is typically seen on the front-end and show up in speed tests. Developers utilize this file and or AJAX to add functionality to their plugins. But just because you see a request to admin-ajax.php doesn’t necessarily mean it is slowing down your site. AJAX loads after the page loads and certain requests can be loaded asynchronously. However, this also doesn’t always mean the developer is doing it in the correct way or that it is coded effectively for performance. For developers, here are some tips on how to properly use AJAX in WordPress themes and plugins.

Below are a couple examples on how we quickly diagnosed an admin-ajax.php spike. We are using GTmetrix, due to the fact that it allows us to dig into the individual post and response data. Pingdom, unfortunately, doesn’t let you see request form data. You can also use Google Chrome Devtools or WebPageTest.

High admin-ajax.php Spike From Visual Composer Plugin

Here is a 3rd party WordPress site we found that was encountering some very large spikes with admin-ajax.php. As you can see, GTmetrix is reporting a spike of over 8 seconds! The rest of their waterfall looks ok, but this is something that definitely needs to be addressed by the owner of the site.

If you click into the POST admin-ajax.php request, you can see three different tabs: Headers, Post, and Response. When diagnosing these types of issues, you really are interested in the contents of the Post and Response tabs. For this site, we can instantly see clues in the Response tab. We can see that part of the request has to do with the “vc_shortcodes-custom-css” script.

A quick copy and paste into Google and we can instantly see that this is coming from the Visual Composer page builder plugin for WordPress. You would be surprised just how much Google indexes.

The next step for this person should be to ensure that their Visual Composer plugin is fully up to date. If it is, they should reach out to the developers of the plugin and report the issue with admin-ajax.php. In fact, this appears to be a common issue with this plugin, as seen in this post on Stack Overflow. The great thing about WordPress is that if a developer is unable to resolve your issue with the plugin, there are most likely alternative plugins out there for you try that do the same thing. For example, when it comes to page builders you could also try out Beaver Builder or Elementor.

High admin-ajax.php Spike From Notification Bar Plugin

Here is the second example on our developer site. Upon installing a certain 3rd party plugin, we instantly saw a huge spike to admin-ajax.php.

Again, if you click into the POST admin-ajax.php request, you investigate further. We can see that in the post data it has “action=mtsnb_add_impression&bar_id=88&ab_variation=none.”

Typically the first part of a post action will also relate to a CSS class in a plugin. So again, we do a quick Google search of “mtsnb” and the first result that pops up is in fact, the Notification Bar plugin we have running on our development site.

If you are a developer, there are of course other ways to track down which plugin might be generating POST response, but we have found that a quick speed test and Google search can also be quite effective.

Surefire Way to Determine Origin of admin-ajax.php

Above are a few easy ways to quickly find the plugin on your WordPress site that might be causing the issue. In our experience, that works 99% of the time. But for the other times where the post data or actions might not be as clear, you can always do it the old school way. Simply disable all the plugins on your WordPress site. Run a speed test on your site, if admin-ajax.php is nowhere to be found, re-enable each plugin one by one while you run tests ea