What POM Cache does

POM Cache reduces the amount of WordPress and PHP work required to deliver repeatable public responses. It stores eligible output as ordinary files at the origin and can serve those files on later requests instead of rebuilding the same response.

It is an opinionated static cache for POM WordPress deployments, with first-class multisite scoping and a separate cache for progressive archive JSON.

Static HTML page caching

When an anonymous request produces a complete, cacheable HTML response, POM Cache writes an index.html file for that host and URL path. A later request can use that file through one of two routes:

• Apache delivery uses the recommended rewrite rules and can return the file without loading WordPress or PHP.
• PHP early delivery uses WordPress’s advanced-cache.php drop-in and returns an existing file before normal plugin and theme execution.

The generated file contains a POM Cache timestamp comment. PHP-served hits also include an X-POM-Cache response header. Apache delivery is faster, but both routes reuse the same HTML file.

Independent progressive JSON caching

Compatible POM progressive archives can request JSON separately from the surrounding page. POM Cache can write those responses into an independent JSON cache and serve them through Apache, early PHP, or the WordPress read fallback.

HTML and JSON are intentionally separate:

• enabling one does not automatically enable the other;
• each cache has its own status and delete button;
• each has independent invalidation settings;
• JSON has its own maximum file size and Cache-Control value.

This separation lets a site clear archive data without discarding every cached page, or clear HTML while preserving valid JSON.

Request safety

POM Cache is designed for reusable public output. Its normal cache path rejects or bypasses requests that should not share a static response, including:

• authenticated WordPress sessions and password-protected content cookies;
• WooCommerce session or cart cookies;
• state-changing POST, PUT, and DELETE requests in the PHP cache path;
• WordPress administration, Customizer, REST, feed, and redirect responses;
• HTML requests with non-tracking query parameters;
• JSON-oriented Accept headers on the HTML cache path;
• incomplete, fatal, or normally uncacheable responses such as a standard 404.

Developers can add stricter exclusions. They should not weaken the safeguards merely to increase the hit rate.

Apache, another web server, and the CDN must preserve the same method and privacy boundary before serving a public file. Verify that contract at every active delivery layer.

Current-site operations on multisite

Cache identities include the host and the current multisite site path where required. The settings tools and admin-bar action purge the current site rather than sweeping the whole network.

This behavior keeps one site’s editorial action from deleting every tenant’s files. It also means that a network-wide change may require a deliberate purge for each affected site.

Invalidation and visibility

The General settings can purge HTML after public post or taxonomy changes. Progressive JSON provides separate switches for post, taxonomy, and translation changes. These automatic purges are disabled until an administrator chooses the policy.

The settings page reports:

• the number and size of current-site HTML files;
• the number and size of current-site progressive JSON files;
• whether WordPress can load the expected cache drop-in and constants.

POM Cache does not automatically age files out. Freshness comes from the selected invalidation policy and deliberate manual purges.

Where it fits

A typical request path is:

Visitor → CDN (optional) → Apache rewrite → POM Cache file
                                      ↘ PHP/WordPress on a miss

POM Cache owns the origin HTML and progressive JSON files. Apache may serve them directly. A CDN may then cache the origin response and negotiate Brotli or Gzip for the visitor.

Read What POM Cache deliberately does not do before assigning image conversion, compression, or CDN responsibilities to the plugin.