Question: Why are admin-ajax and REST API requests still slow even though my frontend pages are cached?

Answer:

Cached frontend pages and dynamic endpoint requests are two different performance problems.

Frontend page caching works well when WordPress can generate a page once and then serve the saved HTML again later. In that case, visitors may receive a cached document without WordPress having to rebuild the full page for every request.

Requests to admin-ajax.php and the REST API endpoint /wp-json/ are different. They usually exist because something needs fresh, request-specific processing: live cart totals, search filters, wishlist changes, login checks, form submissions, background syncs, external integrations, or user-specific data.

Those requests cannot usually be solved by the same static page cache that helps public frontend pages. They must reach WordPress and produce a dynamic response, often JSON or a small piece of request-specific data.

The problem is that WordPress does not treat these requests as lightweight by default.

When an AJAX or REST request reaches WordPress, the normal bootstrap process still begins. WordPress loads its core environment and active plugins before the specific endpoint logic can do its work. On a plugin-heavy site, this can mean that a tiny background request still wakes up a large amount of unrelated PHP code.

For example, an AJAX cart update or REST API lookup may still trigger the loading of plugins that have nothing to do with that request, such as:

• contact form plugins
• slider or gallery plugins
• page builder extensions
• SEO plugins
• review widgets
• marketing integrations
• forum or membership add-ons
• other globally active plugins

That creates a universal bootstrap penalty.

A small dynamic endpoint request can still pay the cost of loading a large global WordPress plugin stack.

This is why admin-ajax and REST API requests may stay slow even when the visible frontend page is cached. The cached page is not the bottleneck anymore. The bottleneck is the dynamic request that bypasses the page cache and forces WordPress to execute.

Traditional optimization can still help, but it does not fully remove this structural cost.

Object caching with Redis or Memcached can reduce repeated database lookups, but it does not stop PHP from loading and executing unrelated plugin code. Asset managers can remove CSS and JavaScript from the browser, but they do not prevent server-side plugin PHP from loading during an AJAX or REST request. Page caching can bypass WordPress for cached documents, but dynamic endpoint requests often have to reach WordPress anyway.

So the deeper issue is not only whether the frontend page is cached. It is whether WordPress is allowed to load too much unrelated code for a small dynamic endpoint request.

Can WordPress prevent unnecessary plugin execution for AJAX and REST API requests before they run?

Not by default.

WordPress normally loads active plugins globally. By the time an individual AJAX action or REST route is processed, much of the plugin stack may already have entered the request. That is why many optimization tools can improve caching, database access, assets or delivery, but still cannot prevent unrelated plugins from loading at the beginning of the dynamic request.

This is where Performance by Prevention becomes relevant.

Instead of only trying to make a heavy endpoint request faster after WordPress has already loaded everything, the prevention approach asks:

Which plugins should not load for this specific AJAX action or REST API route at all?

LiteCache Rush applies this principle to WordPress by controlling plugin loading before the normal WordPress bootstrap continues. For suitable, explicitly configured endpoint contexts, Rush can allow the plugins required for a specific AJAX or REST operation while preventing unrelated plugins from entering that request.

For endpoint performance, that distinction matters:

Caching can protect cached frontend documents.

Performance by Prevention reduces unnecessary server-side execution for dynamic requests that must still reach WordPress.

So the structural fix is not only faster caching. It is reducing what WordPress is allowed to execute when a small dynamic endpoint request does not need the full plugin stack.