Question: Why does my server CPU spike when many users hit dynamic WordPress pages that cannot be served from page cache?

Answer:

When many users hit dynamic WordPress pages that cannot be served from page cache, your server has to stop acting like a passive file distributor and start acting like a PHP application server for every single request.

That is the basic reason for the CPU spike.

A cached public page can often be delivered as a static HTML response by the web server or a CDN. A dynamic page is different. The WooCommerce checkout, shopping cart, account area, live search, LMS quiz, membership dashboard or other user-specific page usually has to be generated for that specific visitor at that specific moment.

That means WordPress, PHP, plugins and database logic become part of the live request path again.

1. The global loading penalty

WordPress normally starts by bootstrapping the application and loading the active plugin stack. By default, active plugins are not loaded only when they are useful for the current request. They are loaded globally.

So a dynamic checkout request may still initialize plugins that are unrelated to checkout, such as sliders, form plugins, gallery tools, marketing integrations, page-builder extensions, analytics plugins or other frontend features.

Each plugin can register hooks, load PHP files, allocate memory, read options, initialize integrations and prepare logic that may never be needed for the current request.

With one user, that overhead may be tolerable. With many concurrent dynamic requests, the same unnecessary work is multiplied across PHP workers. The CPU is not only running the required checkout, account or quiz logic. It is also running unrelated WordPress and plugin code around it.

2. PHP worker pressure

Dynamic WordPress requests occupy PHP workers. A PHP worker can only process one request at a time. If a request takes 1, 2 or 3 seconds because WordPress has to execute a large plugin stack, that worker stays blocked for the entire duration.

When enough users hit non-cacheable pages at the same time, workers fill up. New requests wait in a queue. The CPU then has to handle many competing PHP processes, plugin initializations, database calls and application-level operations at once.

This is why a site can look fast on cached pages but still collapse under dynamic traffic. The cached layer hides the origin cost until enough users hit pages that bypass the page cache.

3. Redis and database optimization do not remove PHP execution

An object cache such as Redis can reduce repeated database lookups. That is useful, but it does not remove the need to execute the PHP application logic that asks for, receives, loops through and interprets that data.

In other words, Redis can make some data access cheaper, but it does not stop WordPress from loading unrelated plugins or running unnecessary PHP code during the dynamic request.

4. Frontend optimization starts too late

Frontend optimization tools can improve assets, browser delivery, file size and rendering behavior. They can be valuable, but they operate after the server has already done the expensive part: generating the main document.

If the CPU spike happens while WordPress is building a dynamic response, then minifying CSS, delaying JavaScript or optimizing frontend assets cannot remove the server-side execution cost that already happened before the browser received anything.

The structural problem is therefore not only that dynamic WordPress pages are uncached. The deeper problem is that WordPress may still execute the full plugin stack for those dynamic requests, even when only a smaller subset of plugins is actually needed.

Dynamic traffic exposes the real cost of WordPress execution because the page cache can no longer hide the full plugin stack.

Can this CPU problem be reduced by preventing irrelevant plugins from loading for dynamic requests?

Yes, but not through default WordPress behavior.

WordPress does not normally decide, early in the request, which plugins are relevant for a checkout, cart, account, quiz or search request. It loads active plugins globally and lets them participate in the request before most optimization tools can make a meaningful execution-layer decision.

That is why the practical conclusion is not just "make the dynamic request faster". The stronger conclusion is:

Prevent unrelated plugin code from entering the dynamic request in the first place.

This is the principle behind Performance by Prevention.

LiteCache Rush applies this principle to WordPress by controlling plugin loading before the normal WordPress bootstrap continues. For example, a checkout request can be allowed to load WooCommerce, payment logic, session handling and required checkout-related plugins, while unrelated plugins such as sliders, contact forms, galleries, frontend-only widgets or marketing extras are prevented from loading for that request.

For dynamic traffic, that distinction matters. Classic optimization tries to make a fully loaded WordPress request less expensive. Rush reduces the amount of WordPress and plugin code that is allowed to execute for the request at all.

Lower CPU usage does not only come from faster execution. It also comes from less unnecessary execution.