Skip to main content
angular_fun000f
Level 1
September 22, 2026
Question

Is Brotli (Content-Encoding: br) supported/configurable on the Adobe-managed CDN in AEM as a Cloud Service?

  • September 22, 2026
  • 1 reply
  • 23 views

We are investigating Brotli compression for static CSS/JavaScript assets on an AEM as a Cloud Service production environment.

Fastly documentation confirms that Fastly supports Brotli compression. However, we would like to understand whether Brotli is officially supported and configurable when using the Adobe-managed CDN provided with AEM as a Cloud Service.

Our current production testing shows:

  • Accept-Encoding: gzip → Content-Encoding: gzip
  • Accept-Encoding: br,gzip → Content-Encoding: gzip
  • Accept-Encoding: br → no Content-Encoding header and the uncompressed response is returned
  • Vary: Accept-Encoding is present

We have reproduced this behavior with both CSS and JavaScript assets across multiple production AEMaaCS domains.

Could someone from the Adobe AEMaaCS/CDN team please clarify:

  1. Is Brotli (Content-Encoding: br) officially supported by the Adobe-managed CDN for AEM as a Cloud Service?
  2. If supported, is Brotli enabled by default, or does it need to be enabled for a customer environment?
  3. Is there an officially supported cdn.yaml configuration or another AEMaaCS configuration/process to enable Brotli?
  4. Is Brotli supported/configurable at the AEM Dispatcher layer, or is compression handled exclusively by the Adobe-managed CDN?
  5. If Brotli is supported by the underlying CDN but is not currently being served, does enabling it require an Adobe support request?

Any Adobe documentation or official guidance on this would be appreciated.

1 reply

vamshi_mut
vamshi_mut
Level 1
September 22, 2026

Hi,

  1. Are these standard client libraries (/etc.clientlibs) generated by AEM, or are they immutable frontend assets deployed outside of clientlibs (e.g., via a decoupled SPA frontend)?
  1. Are you seeing this solely on custom domains, or have you verified the identical behavior on the internal *.adobeaemcloud.com author/publish URLs?

Adobe's standard managed CDN profile defaults to Gzip transport compression. When you force Accept-Encoding: br, it passes through to the origin, which cannot fulfill it, resulting in the uncompressed fallback you observed.

We actually ran into similar issue on our environment but we had our own CDN in front and handled for specific end points.

  1. If you want to keep it strictly on the Adobe-managed CDN, you will need to open a ticket via the Admin Console so their engineering team can evaluate enabling Fastly's automatic edge-compression optimizations for your specific endpoints.

Terms & ConditionsAccessibility statement

Loading footer...