Question: My homepage is fast from cache, but the first request after a cache purge is painfully slow. How can I reduce the work WordPress does before the cache exists?

Answer:

When your page cache is purged, the next uncached visitor may trigger a cold-cache request. Because no ready-made HTML snapshot exists yet, WordPress has to rebuild the homepage dynamically before the caching layer can store the next static version.

That first request is therefore very different from a normal cached hit. A cached homepage can often be delivered quickly as static HTML. A cold-cache homepage request has to wake up WordPress, execute PHP, load plugins, query data, render the page and only then allow the cache plugin to write the new HTML response.

The painful part is not only that WordPress has to read from the database. The larger problem is the global WordPress boot process.

The global boot overhead

By default, WordPress loads the active plugin stack globally on dynamic requests. It does not first ask whether every active plugin is actually needed to generate the public homepage.

So the first homepage request after a purge may still initialize code from plugins that are unrelated to the homepage, such as checkout extensions, form plugins, membership tools, LMS components, backend utilities, analytics integrations, marketing plugins, sliders, galleries or page-builder add-ons.

Each of those plugins may register hooks, load PHP files, read options, initialize integrations, allocate memory or prepare logic that does not contribute to the actual homepage response.

That is why a cold-cache homepage can feel unexpectedly slow. The server is not only generating the homepage. It may also be executing a large amount of unrelated WordPress and plugin code around the homepage generation process.

Why cache warmers only hide part of the problem

A cache warmer can reduce the chance that a real visitor has to trigger the first uncached request. That is useful, but it does not reduce the amount of work required to build the page.

The warmer still has to make WordPress generate the page dynamically. If many pages are purged at once, the warming process can become its own burst of CPU, PHP worker and database pressure.

So cache preloading can move the cold-cache cost away from the visitor, but it does not remove the cost from the server.

Why Redis does not remove the plugin execution cost

An object cache such as Redis can make repeated database lookups cheaper. That can help, especially on sites with heavy option queries or repeated data access.

But Redis does not stop WordPress from loading unrelated plugins. It does not prevent PHP files from being included, hooks from being registered, integrations from initializing or plugin code from executing during the cold-cache request.

In other words, Redis can reduce some database cost, but it does not remove the global plugin-loading cost.

The real structural issue

The first request after a cache purge is slow because the cache cannot help until after WordPress has already done the expensive work. That makes cold-cache requests a useful stress test for the real origin cost of the site.

A cold-cache request exposes the full cost of generating the page before the page cache exists.

Classic optimization still matters. PHP version, object cache, database health, cache warming, fewer heavy plugins and good hosting can all help. But they do not fully solve the deeper problem if WordPress still loads the full plugin stack to generate a homepage that only needs part of that stack.

To reduce the work WordPress does before the cache exists, the important question is not only how to regenerate the page faster. The deeper question is how much unrelated code should be allowed to participate in that first uncached generation request at all.

Can a cold-cache request be made cheaper by preventing irrelevant plugins from loading before the cache is rebuilt?

Yes, but not through default WordPress behavior.

WordPress normally loads active plugins globally before most optimization tools can make request-specific execution decisions. That means a homepage generation request may still include plugins that have no functional role in building the homepage.

This is where Performance by Prevention becomes relevant.

Instead of only trying to make a fully loaded cold-cache request faster, the prevention approach asks a more direct question:

Which plugins should not load for this homepage generation request at all?

LiteCache Rush applies this principle to WordPress by controlling plugin loading before the normal WordPress bootstrap continues. For a homepage context, Rush can allow the theme, cache-related logic and required homepage dependencies, while unrelated plugins such as checkout tools, LMS components, form handlers, backend managers, marketing integrations or page-specific extras do not enter that request.

That matters especially after a cache purge. The first request still has to generate the page, but it no longer has to carry every unrelated plugin through that generation path.

Cold-cache optimization is not only about rebuilding the cache faster. It is also about preventing unnecessary execution before the cache can be rebuilt.

For a cached homepage, this distinction is easy to miss because most visitors only see the fast cached result. The cold-cache request reveals what the server really has to execute when the cache layer is not there yet.