Static HTML cache and WordPress object cache are different
POM Cache is a page cache, not a persistent WordPress object cache. The difference is architectural: static HTML can answer a request before WordPress runs, while an object cache helps only after PHP and WordPress have started.
What the static HTML cache stores
POM Cache stores the finished public document:
wp-content/cache/pom-cache/example.com/about/index.htmlOn a hit, that one file can replace the work normally required to:
- bootstrap WordPress;
- load active plugins and the theme;
- query posts, terms, menus, and options;
- render blocks, templates, and shortcodes;
- assemble the final HTML response.
This produces the largest saving on anonymous pages whose complete output can safely be shared.
What the WordPress object cache stores
The WordPress object-cache API stores values used during a request, such as database query results or computed objects. Without a persistent backend, those values generally last only for the current request. With Redis, Memcached, or another persistent implementation, later WordPress requests can reuse them.
Even with persistence, PHP still starts and WordPress still decides what to render. The browser never receives a Redis object as a finished page.
Side-by-side comparison
| Question | POM static HTML | Persistent object cache |
|---|---|---|
| Stored unit | Complete rendered page | Internal values grouped by cache keys |
| Earliest possible hit | In Apache, before PHP | After WordPress starts |
| Best audience | Anonymous public traffic | Dynamic, authenticated, and uncached WordPress work |
| Typical backend | Filesystem | Redis, Memcached, or another object-cache service |
| Page personalization | Must bypass or use a different strategy | Can still be calculated per request |
| Invalidated by Delete Cache | Yes | No |
| Flushed by an object-cache command | No | Yes |
Why using both can make sense
The two layers complement each other.
Consider a product archive immediately after its static page was purged:
- POM Cache has no
index.html, so WordPress renders the request. - A persistent object cache may reduce database and computation work during that render.
- POM Cache stores the completed public HTML.
- Later anonymous views can skip WordPress entirely.
Authenticated visitors continue to bypass the shared page file but can still benefit from the object cache.
Purge the layer that owns the stale data
Clearing POM Cache removes its HTML files; it does not flush WordPress object groups. Conversely, flushing Redis or another persistent object cache does not delete POM Cache’s index.html files.
Use this diagnostic rule:
- the page source remains an old complete snapshot → purge HTML, then any CDN edge copy;
- WordPress renders the right page but performs expensive repeated queries → investigate object-cache coverage;
- the edge continues serving the old response after the origin is current → invalidate the CDN;
- progressive archive data is stale while the page shell is correct → purge Progressive JSON, not the HTML store.
What POM Cache deliberately removed
POM Cache does not provide a legacy PHP “WP-Cache” payload mode and does not install an object-cache.php drop-in. Its HTML contract is intentionally simple: one complete index.html per eligible host-and-path key.
That simplicity makes direct web-server delivery possible and keeps page caching independent from whichever persistent object-cache technology the site chooses.
Next, compare the two HTML delivery paths in Apache delivery and PHP delivery compared.