What POM Cache deliberately does not do
POM Cache is intentionally narrower than an all-in-one optimization suite. Its responsibility is to create, serve, inspect, and invalidate reusable public HTML and progressive JSON files. The following work belongs to another layer.
Responsibility map
| Task | Responsible layer |
|---|---|
| Generate reusable public HTML | POM Cache |
| Cache compatible progressive archive JSON | POM Cache |
| Convert JPEG or PNG files to WebP | Image-generation or optimization workflow |
| Choose an existing WebP file for a compatible browser | Apache or equivalent web-server rule |
| Generate Brotli or Gzip responses | CDN or web server |
| Cache responses near visitors | CDN |
| Expire files after an arbitrary age | Deliberate site invalidation policy, not POM Cache |
| Cache personalized account or cart output | Not a shared public cache |
No Brotli or Gzip file generation
POM Cache writes one plain origin file for a cached response. It does not spend PHP time producing separate .br or .gz copies.
Compression is negotiated from the visitor’s Accept-Encoding header. A CDN such as CloudFront, or a correctly configured web server, can select Brotli or Gzip at delivery time. Keeping that work outside the plugin avoids duplicate compressed files, stale variants, conflicting headers, and double compression.
Check Content-Encoding in the public response to verify the delivery layer. A value such as br proves that the CDN or server compressed the response; it does not mean POM Cache generated a compressed cache artifact.
No image conversion
POM Cache does not transform uploaded images. If a same-folder WebP version already exists, Apache can rewrite a request for the original JPEG or PNG to that WebP file when the browser supports it.
That workflow has two separate requirements:
- an image process must create the WebP file;
- the web server must choose it safely and retain the original as fallback.
Neither operation is part of HTML or progressive JSON caching.
No automatic edits to server configuration
The Advanced tab displays recommended rules, but the plugin does not:
- insert rules into
.htaccess; - add constants to
wp-config.php; - create or replace
wp-content/advanced-cache.php; - remove another cache plugin’s drop-in.
These files can affect the entire WordPress installation. A site owner or deployment process must review, back up, and apply the changes manually.
The Fix Configuration button is not an exception. It writes the current site’s POM Framework settings files using effective values; it never edits the drop-in or wp-config.php.
No CDN management
POM Cache does not rewrite asset URLs, provision CloudFront, or purge every edge object. Origin cache and CDN cache are different copies:
- deleting an origin file does not prove that a CDN object was invalidated;
- a CDN hit does not prove that the origin currently contains the same response;
- CDN compression and cache headers must be checked independently.
Diagnose the origin first, then the edge.
No shared caching of personalized state
An authenticated page, private account area, cart, checkout, password-protected post, or other visitor-specific response must not become shared static HTML. The PHP cache path bypasses recognized WordPress, password, comment-author, and WooCommerce session cookies and rejects state-changing requests. Apache and CDN rules must enforce the equivalent boundary before returning a public file.
If an otherwise public page contains a small personalized component, keep the shared HTML public and load the private fragment through an appropriate visitor-specific mechanism. Do not remove cookie or method safeguards to force a cache hit.
No automatic age-based expiry
POM Cache does not run a garbage-collection timer and does not delete files merely because they are old. This is deliberate: elapsed time alone cannot tell whether content is stale.
Freshness should follow real events:
- a public post changed;
- a taxonomy term changed;
- a translation changed;
- an administrator requested a purge;
- a deployment changed rendered output.
Enable only the matching invalidation switches and monitor disk use. The absence of automatic expiry makes a tested purge policy essential before production launch.
No replacement for application optimization
A cached response can hide expensive page generation on repeat visits, but it does not fix a slow uncached request, an inefficient database query, oversized media, blocking JavaScript, or a remote API delay. Measure the first dynamic request as well as subsequent cache hits.
Continue with Requirements and compatibility to confirm that the origin can support the cache layer.