Understand early cache delivery

Early delivery is the PHP fallback between Apache and the normal WordPress render. It is fast because POM Cache can return an existing index.html before WordPress loads the active plugins, resolves the main query, or selects a template.

When phase one starts

WordPress core loads wp-content/advanced-cache.php only when WP_CACHE is true. The POM Cache drop-in then loads:

POM_CACHE_HOME . 'pom-cache-phase1.php'

Phase one reads the effective runtime and storage settings for the current site and prepares the same host-and-path mapping used during generation.

Checks performed before the lookup

The early runtime returns control to WordPress when the request is:

• a WordPress backend, login, cron, XML-RPC, CLI, or related internal route;
• associated with a WordPress login, post-password, or comment-author cookie;
• associated with a WooCommerce session or cart cookie;
• POST, PUT, or DELETE;
• a Customizer changeset request;
• protected by DONOTCACHEPAGE.

If the configured cache path is empty or resolves to /, POM Cache marks the request non-cacheable instead of operating on an unsafe directory.

Static request eligibility

For HTML, the method must be GET or HEAD. The URL must have no remaining meaningful query string, must not point to rejected WordPress PHP/backend paths, and must not request JSON, ActivityPub JSON, or linked-data JSON through the Accept header.

Recognized tracking parameters can be removed by the PHP runtime. If removing them leaves no query state, the canonical HTML file may be used. Parameters that change content remain a bypass.

File resolution

POM Cache builds the candidate path from:

• Cache Location;
• the pom-cache subdirectory;
• the current request host without its port;
• the normalized URL path;
• the fixed filename index.html.

It resolves the real path, verifies that the file exists and is readable, and confirms that it remains below the configured cache root. A path that fails containment is never served.

The early response

On a valid hit, phase one:

1. defines DONOTCACHEPAGE so no later component tries to cache the response again;
2. sets HTTP status 200;
3. sends Content-Type: text/html with the WordPress site character set;
4. sends Content-Length when available;
5. adds the POM Cache diagnostic header;
6. reads the file for GET, or omits the body for HEAD;
7. ends request processing.

The diagnostic value is:

X-POM-Cache: Served static cache from PHP; phase=early

No theme hook, shortcode, analytics injection performed in PHP, or normal plugin request callback runs after that point. Anything required in a cached page must already be present in the stored HTML or be added by the browser, web server, or CDN.

What happens on an early miss

An early miss is not an error. The drop-in returns control to WordPress. The normal plugin load can then register phase two, render the page, and decide whether the completed response should become a new file.

The late lookup registered by phase two is disabled for serving by default. That prevents a newly known user or route context from casually reusing shared HTML. Developers can implement an explicit late policy when they can prove the response remains public.

Verify this phase in isolation

1. Ensure the WordPress configuration report shows three OK states.
2. Keep direct Apache delivery disabled for the test.
3. Generate a public cache file with one signed-out request.
4. Reload the exact URL with no cookies or meaningful query string.
5. confirm the phase=early response header;
6. repeat with HEAD and confirm that headers are present without a response body;
7. sign in and confirm the early header disappears.

Continue to Understand cache generation after WordPress renders to see how the file used by phase one is produced.