Question: According to my host, the file admin-ajax.php or wc-ajax=get_refreshed_fragments is causing extremely high CPU load. How can I stop this?

Answer:

Your host is pointing at the symptom. The cause runs deeper.

admin-ajax.php and wc-ajax=get_refreshed_fragments are dynamic WordPress and WooCommerce request paths. WooCommerce uses them to keep cart data synchronized, refresh cart fragments, update cart-related interface elements and reflect customer-specific state.

These requests can happen even when the visible page itself looks simple or is served from cache. A visitor may open a page, receive a fast cached document, and still trigger an additional dynamic AJAX request shortly afterward.

The CPU load comes from what happens when those AJAX requests reach the server:

They can trigger a normal WordPress execution path for a very small piece of dynamic information.

That means WordPress may load the active plugin environment, initialize WooCommerce, run hooks, check sessions, inspect cart state, execute theme or plugin logic and perform database work just to determine what should happen with a cart fragment or AJAX response.

This is why the request can become expensive even when the actual result looks trivial. The expensive part is not only the returned fragment. The expensive part is the WordPress and plugin execution required to produce it.

This is not simply a WooCommerce bug. It is a consequence of the way WordPress handles dynamic requests. AJAX requests are not automatically isolated from the global plugin stack.

Common recommendations can still help. Disabling cart fragments on pages where they are not needed, reducing unnecessary AJAX triggers, improving object cache behavior, checking slow hooks, removing unused WooCommerce extensions and optimizing database queries are all valid steps.

But those steps mostly reduce how often the problem appears or how expensive the WooCommerce logic itself becomes. They do not fully change the structural issue:

When the AJAX request does run, WordPress may still load far more plugin code than the request actually needs.

That is why simply blocking every AJAX request is not a clean solution. Some of these requests are needed for real cart, checkout or session behavior. The goal is not to break WooCommerce. The goal is to reduce unnecessary execution around the WooCommerce functionality that is actually required.

So the better question is not only how to stop admin-ajax.php or cart fragments entirely. The better question is how to make those dynamic request paths execute only the code they genuinely need.

Can WordPress prevent unrelated plugins from loading during WooCommerce AJAX requests?

Not by default.

WordPress normally loads active plugins as part of the global runtime before a specific AJAX request can be handled with fine-grained context. By the time WooCommerce responds to a cart-fragment request, many unrelated plugins may already have entered the request.

That is why tools that suppress frontend scripts, optimize assets, improve caching or reduce cart-fragment frequency do not fully solve the execution-layer problem. They may reduce the number of requests, but they usually do not decide which plugins are allowed to load when such a request actually reaches WordPress.

For this type of CPU problem, the structural question is:

Which plugins should be allowed to execute for this WooCommerce AJAX request at all?

This is where Performance by Prevention becomes relevant. The goal is not merely to optimize the full WordPress runtime after it has already loaded. The goal is to prevent unrelated plugin execution before the request becomes expensive.

LiteCache Rush applies this principle to WordPress. It determines the request context early and controls which plugins are allowed to load before the normal WordPress bootstrap continues.

For WooCommerce AJAX and cart-fragment requests, that means WooCommerce, session handling and genuinely required shop-related plugins can remain available, while unrelated plugins such as sliders, contact forms, page-builder extras, SEO tools, gallery plugins or marketing integrations do not have to enter that request if they are not needed.

That changes the nature of the fix:

Instead of only reducing how often the AJAX request happens, Performance by Prevention reduces what WordPress has to execute when the AJAX request happens.

So the practical answer is not to blindly kill admin-ajax.php or wc-ajax. The cleaner approach is to keep required WooCommerce behavior working while preventing unrelated plugin execution from amplifying the CPU cost of every dynamic request.