“Block admin-ajax.php, it’s slowing down your site” is one of the most repeated pieces of bad WordPress performance advice I keep running into. I get why it spreads — it shows up in nearly every “why is my server response time high” checklist, usually right next to advice to disable XML-RPC or lock down the REST API entirely, something I push back on for similar reasons in disabling the REST API without breaking the block editor. The trouble is, blindly blocking admin-ajax.php doesn’t just tidy up wp-admin. It breaks things your visitors actually use on the frontend.

What admin-ajax.php actually is

Despite the word “admin” in the name, admin-ajax.php is WordPress’s general-purpose AJAX router for the entire site, not just the dashboard. AJAX, if you haven’t run into the term, just means a page fetching or sending small bits of data in the background without a full reload — think of a cart total updating the instant you click “add to cart,” with no page refresh.

Plugins and themes hook into this router to power exactly that kind of feature. A few examples you’ve probably used without realizing what powered them:

• WooCommerce’s cart fragments — the mini-cart count and total updating live when you add something to your cart.
• The Heartbeat API — used for post locking (the “someone else is editing this post” warning), autosave, and some login-state checks.
• Live comment posting, AJAX-based search, infinite scroll, “load more” buttons, and quiz or form plugins.

So when a generic checklist tells you to block requests to admin-ajax.php in your .htaccess file or firewall, you’re not just locking down the admin area. You’re breaking the shopping cart, comment forms, autosave, and whatever else your theme or plugins built on top of it. I’ve seen sites where this caused “add to cart” buttons to silently stop updating the cart count, with no visible error to the customer — just a WooCommerce store quietly losing sales.

The actual problem is usually one specific plugin

When admin-ajax.php shows up as slow in a performance report or a waterfall chart, it’s almost never the file itself causing the slowness. It’s some feature calling it too often, or with too much overhead per call. Here’s how I track down which one.

1. Look at the Network tab

Open your browser’s developer tools, go to the Network tab, reload the page, and filter for admin-ajax.php. Watch for three things:

• How often it fires. Once on page load is normal; firing every few seconds is a red flag.
• The action parameter in the request’s data — this tells you exactly which feature is calling it, for example action=woocommerce_cart_fragments or action=heartbeat.
• The response time and size for each call.

That action value is your answer key. Search the plugin’s code, or just its name alongside that action string, and you’ll find exactly what’s triggering it and how often. This same “watch the network requests, then narrow down the cause” approach is worth keeping in your back pocket generally — it’s the same first step I use when debugging a slow wp-admin dashboard.

2. Cart fragments (WooCommerce)

WooCommerce’s wc-cart-fragments script refreshes the cart via AJAX on essentially every page load by default, even on pages that have nothing to do with shopping. If your site has content pages that don’t need live cart data, you can dequeue the script there:

add_action( 'wp_enqueue_scripts', function() {
    if ( ! is_cart() && ! is_checkout() && ! is_shop() ) {
        wp_dequeue_script( 'wc-cart-fragments' );
    }
}, 99 );

3. Throttle the Heartbeat API instead of ripping it out

Heartbeat is genuinely useful — it’s what prevents two people from overwriting each other’s edits on the same post — so I don’t recommend killing it outright unless you’re sure you don’t need post locking or autosave. Throttling how often it pulses is usually enough to cut the load significantly:

add_filter( 'heartbeat_settings', function( $settings ) {
    $settings['interval'] = 60; // seconds between pulses, default is much shorter
    return $settings;
});

If you’re confident you don’t need it on the frontend at all — most public-facing pages don’t — you can disable just that copy while leaving it intact in wp-admin, where post locking still needs it:

add_action( 'init', function() {
    if ( ! is_admin() ) {
        wp_deregister_script( 'heartbeat' );
    }
});

4. Disable specific AJAX-heavy features you don’t actually use

Some themes and page builders turn on AJAX-based live search, related-post widgets, or comment AJAX by default, whether or not you use them. Check your theme and plugin settings for toggles before writing any custom code — a lot of this is configurable without touching functions.php at all. It’s a similar spirit to the small handful of settings I check in wp-config.php on every new install, covered in the wp-config.php settings I change every time — a few minutes of checking defaults saves a lot of guesswork later.

The bottom line

Don’t block admin-ajax.php wholesale. Identify the specific action that’s firing too often using the Network tab, then either throttle it (Heartbeat), scope it to the pages that actually need it (cart fragments), or turn off the specific feature causing it. Leave the router itself alone — half your site’s interactivity depends on it.

Frequently Asked Questions About admin-ajax.php

Is admin-ajax.php actually part of wp-admin?

Only in name. Despite “admin” being in the filename, it’s used across your entire site, including the parts your visitors see — the cart, comment forms, live search, and similar interactive features all route through it.

Do I need a developer to fix this?

Reading the Network tab to identify which feature is calling it too often is something most site owners can do themselves with a bit of patience. Actually writing the fix — dequeuing a script, adjusting Heartbeat’s interval — is a small code change, so if you’re not comfortable editing functions.php yourself, that part is worth handing to a developer.

Will blocking admin-ajax.php break anything on my site?

Very likely, yes. Anything built with live AJAX interactivity — cart updates, comment posting, autosave, infinite scroll — depends on it working. Blocking it wholesale tends to break these features silently, without an obvious error message pointing to the cause.

How do I know if admin-ajax.php is actually my problem, or something else entirely?

Check the Network tab for how often it’s firing and how long each call takes. If it’s firing constantly or taking a long time to respond, it’s worth investigating further. If it barely appears, your slowness is probably coming from somewhere else entirely.

Should I just disable Heartbeat completely instead of throttling it?

Only if you’re sure you don’t rely on post locking (the “someone else is editing this” warning) or autosave protection. For most sites, throttling the interval gets you nearly all of the performance benefit while keeping those safety features intact.

Why does this bad advice keep showing up in performance checklists?

Because admin-ajax.php genuinely can show up as a slow or frequent request in a performance scan, and “block it” looks like a quick win to whoever wrote the checklist. It’s a classic case of treating a symptom as if it were the disease — the fix isn’t blocking the router, it’s finding what’s overusing it.

Once you’ve found the specific feature driving the traffic and dealt with it directly, admin-ajax.php stops being a performance problem on its own — because it was never really the problem to begin with.