Inicio - Documentación - POM Cache - 05 Compression and CDN - Use CloudFront Brotli compression with POM Cache

Use CloudFront Brotli compression with POM Cache

CloudFront can compress an eligible uncompressed POM Cache response at the edge and cache the resulting representation. POM Cache does not need a Brotli file on disk.

This guide describes the AWS behavior relevant to POM Cache. CloudFront settings and access remain deployment-owned.

Confirm the origin baseline

Before changing CloudFront:

  1. bypass the distribution through the approved origin-testing method;
  2. request a cached public page;
  3. confirm the origin returns the correct HTML;
  4. record Content-Type and Content-Length;
  5. confirm the response is not already carrying Content-Encoding;
  6. verify authenticated and cart requests remain outside public static delivery.

If the origin already compresses, decide whether to keep origin compression or move ownership to CloudFront. Do not treat both as independent optimizations.

Configure the cache behavior

In the AWS CloudFront console:

  1. select the distribution;
  2. open Behaviors;
  3. edit the behavior that serves the relevant POM public content;
  4. set Compress objects automatically to Yes;
  5. select or create a cache policy with Gzip and Brotli compression support enabled;
  6. save and wait for the distribution change to deploy.

AWS requires a cache policy—not legacy cache settings—for Brotli. In API, SDK, or infrastructure-as-code terms, the relevant controls are Compress, EnableAcceptEncodingGzip, and EnableAcceptEncodingBrotli.

CloudFront then normalizes supported Accept-Encoding values and adds that dimension to the cache key. AWS advises against redundantly adding Accept-Encoding to the origin request policy when compression caching is enabled. See Serve compressed files and Understand cache policies.

Do not choose a cache policy for compression alone

A policy also controls TTLs, cookies, query strings, and headers. A policy that is efficient for immutable assets can be unsafe for WordPress HTML.

Before attaching it, confirm:

  • administration, login, account, cart, checkout, previews, and APIs do not enter the public behavior;
  • viewer methods are restricted appropriately;
  • cookies and query strings follow the site’s public-cache contract;
  • minimum TTL does not force private/no-cache responses into storage;
  • host and multisite routing remain correct.

Compression support does not make an unsafe edge cache safe.

Understand CloudFront’s eligibility checks

According to AWS, automatic compression depends on factors including:

  • viewer Accept-Encoding includes br or gzip;
  • the object has a supported Content-Type;
  • origin Content-Length is valid;
  • size is between 1,000 and 10,000,000 bytes;
  • response status is 200, 403, or 404;
  • the response has a body;
  • the edge has not retained an older uncompressed copy.

CloudFront compression is best-effort. A valid request can occasionally receive an uncompressed cached object.

If the origin already sends any Content-Encoding, CloudFront treats the response as already encoded and does not compress it again.

Prefer HTTPS for browser Brotli

Modern browser Brotli support is associated with HTTPS delivery. Keep the public site canonical on HTTPS and test the actual viewer URL, not an internal HTTP-only origin endpoint.

When both Brotli and Gzip are accepted and an eligible variant is available, CloudFront normally prefers Brotli. Existing cached variants can influence what a viewer receives, so verify the header rather than assuming.

Replace pre-existing uncompressed edge objects

Enabling compression does not transform objects already stored at edge locations. They can remain uncompressed until expiry, eviction, or invalidation.

After the new behavior deploys:

  1. invalidate the controlled test path;
  2. request it with Accept-Encoding: br,gzip;
  3. inspect Content-Encoding;
  4. repeat until an edge hit is observed;
  5. compare with Accept-Encoding: identity.

Do not invalidate the whole distribution merely to test one page.

Expected response

For a compatible eligible viewer, expect:

Content-Encoding: br

or, when Gzip is selected:

Content-Encoding: gzip

The response Content-Type remains the resource type, such as text/html; compression does not change HTML into another media type.

Use Verify Brotli or Gzip delivery for a repeatable test and Coordinate POM Cache clearing with CDN invalidation when content changes.