Why serve cache files before PHP

A POM Cache hit already avoids page generation. Letting Apache serve that file directly removes the remaining PHP bootstrap as well.

The benefit is not a different cache format. Apache and the early PHP drop-in read the same index.html.

Work avoided by a direct hit

Without a native rule, an origin request can still require:

• a PHP worker;
• WordPress’s early bootstrap;
• loading advanced-cache.php;
• loading POM Cache’s phase-one runtime;
• reading site settings;
• checking the request and filesystem path;
• emitting the response through PHP.

The early fallback is much cheaper than a full WordPress render, but it still occupies PHP capacity. Apache can perform a file-existence check and send the file without that work.

This is most valuable when anonymous page traffic is high or PHP workers are the origin bottleneck.

What direct delivery does not improve

Apache cannot accelerate a request that must remain dynamic, including:

• a cache miss;
• an authenticated or password-authorized visit;
• a cart or session view;
• a content-changing query;
• a preview;
• a state-changing request;
• a route whose HTML file was purged.

WordPress still needs to generate missing pages and process excluded requests. Direct delivery complements the PHP fallback; it does not replace it.

The cost of moving earlier

The earlier a layer answers, the less application context it knows.

Apache
  knows HTTP and filesystem state
        ↓
early POM Cache PHP
  also knows effective cache settings and POM request guards
        ↓
WordPress
  also knows users, capabilities, routes, templates, and plugins

Apache must decide from information available in the request: method, path, query string, headers, cookies, hostname, and whether the target exists. Any safety condition known only to WordPress cannot protect a response that Apache already returned.

Why the PHP path remains essential

Keep the drop-in configured even after direct delivery works:

• it is the fallback when Apache conditions do not match;
• it can normalize recognized tracking-only parameters;
• it provides the X-POM-Cache header for observable early hits;
• it keeps cache reuse available on installations without native rules;
• it gives developers a controlled late-policy extension point.

It is also the safest baseline for isolating web-server problems. If PHP can reuse the file but Apache cannot, generation and storage are already known to be correct.

Measure the right comparison

Compare three origin states separately:

1. full WordPress render after a purge;
2. early PHP hit with Apache direct delivery disabled;
3. direct Apache hit.

Use several requests and inspect origin behavior, not only browser load time. DNS, TLS, CDN location, connection reuse, and asset downloads can hide the difference between the three paths.

The target outcome is reduced origin work without changing the page, status, access boundary, or invalidation behavior.

When not to add the rule

Stay with PHP delivery until:

• the canonical host and multisite mapping are stable;
• cache generation and purging are already verified;
• a server administrator can test and roll back configuration;
• personalized routes and cookies are known;
• the effective rule can restrict static delivery to public read requests;
• the CDN can be bypassed during diagnosis.

Proceed to Back up and review server rules before deployment before copying configuration.