Compression and CDN responsibilities

POM Cache owns reusable origin content. The web server or CDN owns transfer compression, edge lifetime, geographic delivery, and edge invalidation.

Keeping those responsibilities separate lets one canonical index.html serve viewers that support Brotli, Gzip, or no compression.

The delivery stack

WordPress render
    ↓
POM Cache origin file
    ↓
Apache or early PHP response
    ↓
CDN edge object and compression variant
    ↓
Viewer

Each arrow can be a cache boundary. A hit at the CDN means the origin was not contacted. A POM Cache hit describes the origin and says nothing about whether the edge reused its own copy.

What POM Cache does

For static HTML, POM Cache:

• writes one plain index.html;
• reuses the file for eligible public requests;
• purges the current site’s HTML tree through its own tools and hooks;
• does not assign an age-based lifetime;
• does not call a CDN invalidation API.

Progressive JSON is a separate origin store with its own Cache-Control setting and purge controls.

What POM Cache does not do

The plugin does not:

• write .br or .gz siblings;
• compress output during page generation;
• rewrite asset URLs to a CDN domain;
• choose a CloudFront cache policy;
• purge an edge distribution;
• make private WordPress traffic safe for edge caching.

These are infrastructure decisions because they depend on viewer capabilities, CDN cache keys, TLS, origin headers, and deployment topology.

Choose the guide by task

• Why POM Cache does not create compressed files explains the architectural decision.
• Use CloudFront Brotli compression with POM Cache provides the current AWS-oriented setup and eligibility checks.
• Distinguish the origin cache from the CDN cache identifies which layer answered.
• Coordinate POM Cache clearing with CDN invalidation gives the correct update order.
• Verify Brotli or Gzip delivery tests the public response without looking for nonexistent disk files.
• Avoid duplicate compression work assigns one owner to compression.

Safe rollout order

1. Verify the page dynamically before caching.
2. Generate and reuse the POM Cache file at the origin.
3. Verify direct Apache or early PHP behavior.
4. Define the CDN cache key and private-traffic bypass.
5. Enable edge compression.
6. Invalidate any older uncompressed or stale edge object.
7. verify anonymous, authenticated, cart, query-string, and content-encoding behavior.

Do not diagnose the origin through a warm CDN response. Equally, do not assume that deleting POM Cache makes an existing edge object disappear.

Two different Vary dimensions

Keep these concepts separate:

CloudFront’s compression settings can normalize Accept-Encoding automatically. Same-URL WebP negotiation requires an independent Accept-aware edge policy.

The POM production pattern uses CloudFront for Brotli/Gzip. Another CDN or native server compression is valid when it preserves the same responsibility boundary.