Why POM Cache does not create compressed files

POM Cache deliberately stores the canonical uncompressed document. Compression is applied when the response is delivered, where the server or CDN knows what the viewer accepts.

This means a normal cached page has:

index.html

and does not have POM-managed siblings such as:

index.html.br
index.html.gz

One source, several transfer variants

A viewer can advertise:

Accept-Encoding: br,gzip

Another client may only accept Gzip or identity. The content is the same; only its wire encoding changes.

Keeping one origin file lets the delivery layer select:

• Brotli for an eligible compatible request;
• Gzip for another compatible request;
• the uncompressed representation when no supported encoding is available.

Why generation is the wrong moment

If POM Cache compressed during the WordPress response, it would add:

• CPU work to the cache miss;
• multiple files per page;
• atomic-write handling for each variant;
• more storage accounting;
• variant cleanup after every purge;
• format and quality settings inside PHP;
• extra failure modes when one sibling is incomplete.

None of that improves the canonical HTML. A CDN can perform the negotiation near the viewer and reuse the compressed edge object.

Invalidation stays simpler

POM Cache replaces or removes one HTML file. The edge can discard its Brotli, Gzip, and identity variants for the corresponding public path according to the CDN’s invalidation model.

POM Cache therefore does not need to know:

• which encodings have been requested;
• which edge locations hold them;
• whether the CDN recompressed or passed through an origin encoding;
• when an individual transfer variant expires.

Compression is not minification

These operations solve different problems:

• HTML minification changes the canonical document by removing or rewriting text.
• Brotli/Gzip encodes the same response for transfer and is reversed by the client.
• POM Cache stores and reuses the finished canonical document.

POM Cache does not perform either minification or compression. If another component changes HTML, validate the result before it becomes a static file.

Compression is not page caching

A compressed dynamic response can still require a complete WordPress render. An uncompressed POM Cache hit can still avoid WordPress.

Measure them separately:

Supported deployment models

Use one explicit compression owner:

1. Edge compression: origin returns the plain POM Cache representation and the CDN compresses it.
2. Origin compression: Apache or another server compresses and sends the correct Content-Encoding; the CDN passes and caches that representation.

The standard POM architecture uses the first model with CloudFront.

If compressed delivery is missing, configure the CDN or server. Searching the POM Cache directory for .br or .gz files cannot diagnose it.

Continue with Use CloudFront Brotli compression with POM Cache or Avoid duplicate compression work.