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

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

  • September 22, 2026
  • 3 replies
  • 110 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.

Best answer by AmitVishwakarma

Hi ​@angular_fun000f 
Based on the behavior described, Brotli is not currently being served by the Adobe-managed CDN for these requests.

The results indicate the following:

  • Accept-Encoding: gzip ->Content-Encoding: gzip
  • Accept-Encoding: br,gzip ->Content-Encoding: gzip
  • Accept-Encoding: br ->no Content-Encoding header

This means that the request is reaching the delivery layer, but the CDN is not selecting Brotli for the response. The absence of Content-Encoding: br does not indicate a problem with the browser or with the Accept-Encoding header.

The Vary: Accept-Encoding header is expected. However, it only tells caches that the response may vary depending on the client's supported encoding. It does not enable Brotli compression by itself.

Fastly supports Brotli compression at the CDN technology level. However, for AEM as a Cloud Service, Brotli enablement is not exposed as a documented customer-configurable property in cdn.yaml. The documented CDN configuration options mainly cover request transformations, response-header transformations, redirects, origin selectors, and traffic-filter rules.

Brotli should also not be enabled by adding only the following response header:

Content-Encoding:br

That would be incorrect unless the response body had actually been compressed using Brotli. Otherwise, clients would try to decompress an uncompressed response and the content could become unreadable.

At the Dispatcher layer, customers cannot add arbitrary Apache modules such as mod_brotli in AEM as a Cloud Service. Dispatcher configuration is limited to Adobe-supported and allowlisted modules/directives.

The recommended approach is to open an Adobe Support request through the Admin Console and ask the AEM Cloud/CDN team to evaluate enabling managed CDN edge compression for the relevant environment and static CSS/JavaScript endpoints. It would be preferable to validate this first in a lower environment. Please include the following information in the support request:

  • Program and environment details
  • CDN-facing domain names
  • Example CSS and JavaScript URLs
  • Response headers for:
    • Accept-Encoding: br 
    • Accept-Encoding: gzip -
    • Accept-Encoding: br,gzip
  • Confirmation that the origin is returning the assets without Content-Encoding 
  • A request to evaluate Brotli compression for eligible static assets

After the change is evaluated or enabled, test the CDN-facing URL using:

curl -sS -D - -o /dev/null \ -H "Accept-Encoding: br" \ "https://<cdn-domain>/<static-asset>.css"

For an eligible Brotli-compressed response, the expected headers would be similar to:

Content-Encoding: br

Vary: Accept-Encoding

 

Also make sure to test through the Adobe CDN URL rather than directly against the origin, and consider cache effects when validating the result.

3 replies

vamshi_mut
vamshi_mut
Level 2
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.

    AmitVishwakarma
    Community Advisor
    AmitVishwakarmaCommunity AdvisorAccepted solution
    Community Advisor
    September 23, 2026

    Hi ​@angular_fun000f 
    Based on the behavior described, Brotli is not currently being served by the Adobe-managed CDN for these requests.

    The results indicate the following:

    • Accept-Encoding: gzip ->Content-Encoding: gzip
    • Accept-Encoding: br,gzip ->Content-Encoding: gzip
    • Accept-Encoding: br ->no Content-Encoding header

    This means that the request is reaching the delivery layer, but the CDN is not selecting Brotli for the response. The absence of Content-Encoding: br does not indicate a problem with the browser or with the Accept-Encoding header.

    The Vary: Accept-Encoding header is expected. However, it only tells caches that the response may vary depending on the client's supported encoding. It does not enable Brotli compression by itself.

    Fastly supports Brotli compression at the CDN technology level. However, for AEM as a Cloud Service, Brotli enablement is not exposed as a documented customer-configurable property in cdn.yaml. The documented CDN configuration options mainly cover request transformations, response-header transformations, redirects, origin selectors, and traffic-filter rules.

    Brotli should also not be enabled by adding only the following response header:

    Content-Encoding:br

    That would be incorrect unless the response body had actually been compressed using Brotli. Otherwise, clients would try to decompress an uncompressed response and the content could become unreadable.

    At the Dispatcher layer, customers cannot add arbitrary Apache modules such as mod_brotli in AEM as a Cloud Service. Dispatcher configuration is limited to Adobe-supported and allowlisted modules/directives.

    The recommended approach is to open an Adobe Support request through the Admin Console and ask the AEM Cloud/CDN team to evaluate enabling managed CDN edge compression for the relevant environment and static CSS/JavaScript endpoints. It would be preferable to validate this first in a lower environment. Please include the following information in the support request:

    • Program and environment details
    • CDN-facing domain names
    • Example CSS and JavaScript URLs
    • Response headers for:
      • Accept-Encoding: br 
      • Accept-Encoding: gzip -
      • Accept-Encoding: br,gzip
    • Confirmation that the origin is returning the assets without Content-Encoding 
    • A request to evaluate Brotli compression for eligible static assets

    After the change is evaluated or enabled, test the CDN-facing URL using:

    curl -sS -D - -o /dev/null \ -H "Accept-Encoding: br" \ "https://<cdn-domain>/<static-asset>.css"

    For an eligible Brotli-compressed response, the expected headers would be similar to:

    Content-Encoding: br

    Vary: Accept-Encoding

     

    Also make sure to test through the Adobe CDN URL rather than directly against the origin, and consider cache effects when validating the result.

    Amit Vishwakarma - Adobe Commerce Champion 2025 | 17x Adobe certified | 6x Adobe SME
      angular_fun000fAuthor
      Level 1
      October 2, 2026

      ​@AmitVishwakarma ​@vamshi_mut  Thank you both.. 
      We raised an Adobe Support ticket to confirm Brotli support for the Adobe-managed Fastly CDN. Adobe confirmed that Brotli is supported at the CDN level and enabled it for our environment.
      We have also disabled the Dispatcher-level mod_deflate configuration, as Brotli compression is now handled at the CDN layer.

        Terms & ConditionsAccessibility statement

        Loading footer...