Compression Is Enabled — So Why Are You Still Shipping Too Many Bytes?

“Brotli is enabled.” The box is checked in the hosting panel — yet the homepage still transfers more data than expected.

HTTP compression is not a property of your source file. It is the result of content negotiation across the real delivery path: browser, CDN, reverse proxy, and origin can all affect the representation that reaches the user.

So the useful question is not: Is Brotli enabled? It is: Which representation does a real visitor actually receive?

What the browser negotiates

Through Accept-Encoding, a client advertises the content codings it understands. The server or an intermediary can answer using, for example, gzip, br, or zstd, and identifies the selected coding in Content-Encoding. RFC 9110 defines this mechanism, while current MDN documentation lists gzip, Brotli, and Zstandard.

Text responses such as HTML, CSS, JavaScript, JSON, XML, and SVG are strong candidates. web.dev recommends compressing text-based responses and describes Brotli as generally more efficient than gzip for web content.

But enabling an algorithm does not prove that every important response reaches users compressed.

Red flag 1: Only the HTML document is compressed

Do not inspect only /. A large share of traffic may live in JavaScript chunks, CSS, JSON APIs, GraphQL responses, or server-rendered routes.

Sample the HTML document, largest JavaScript bundle, primary CSS, a representative API response, and an SVG. Compare transfer size with resource size and record Content-Type, Content-Encoding, and cache status.

If some text resource types remain uncompressed, MIME-type configuration, framework defaults, or proxy rules are common causes.

Red flag 2: Origin and browser do not see the same negotiation

A CDN is not a transparent cable. It can normalize content negotiation and recode responses at the edge.

Cloudflare, for example, documents that its CDN can adjust Accept-Encoding toward the origin based on enabled compression methods and then recompress cached assets according to visitor support.

That illustrates a general audit rule: test the public domain through the path your users take. Calling the origin directly is useful for isolation, but it does not prove what is delivered after CDN, WAF, proxy, and cache behavior.

Red flag 3: Cache behavior and Content-Encoding do not line up

When one URL can be delivered using different codings based on Accept-Encoding, caching becomes part of the feature.

RFC 9110 defines Vary as a signal describing which request fields influenced representation selection. A CDN or cache therefore has to separate encoded variants correctly or normalize them internally.

Send requests with different Accept-Encoding values. Does Content-Encoding change sensibly? Is the decoded content correct? Does the cache return the appropriate variant? Are ETags coherent?

A failure does not have to break the page. It may simply leave some clients consistently downloading a larger representation.

Red flag 4: Already-compressed media is processed again

AVIF, WebP, JPEG, video, ZIP, and many PDFs are already strongly compressed. Another HTTP compression pass often saves little while consuming CPU.

More serious is accidental double compression: one layer receives data already encoded with gzip or Brotli, processes it again, and leaves body and headers out of sync.

A review should therefore check more than the presence of Content-Encoding. It should verify that the coding, payload, and resource type agree.

Red flag 5: Maximum compression on every dynamic response

Static bundles can be precompressed into .br or .gz variants during a build. Dynamic HTML and JSON are compressed at runtime.

For dynamic content, smallest payload is not the only metric. Watch Time to First Byte, CPU utilization, concurrency, cache hit rate, and request frequency. An aggressive compression level can save bytes while unnecessarily delaying the server.

The best setting is the one that improves end-to-end performance and stability.

Brotli, gzip, or Zstandard?

gzip remains a broadly deployed fallback. Brotli is established in modern browsers. zstd also appears in current HTTP and browser documentation as a content coding and is based on the Zstandard format defined in RFC 8878.

You do not need to force all three everywhere. Clean negotiation and tested fallback behavior matter more:

1. offer a modern coding when client and infrastructure support it reliably,
2. retain gzip as a compatible fallback,
3. allow identity where compression adds little value,
4. test the real client and infrastructure matrix.

The 15-minute check

Open the production site in a clean browser profile and reload with the Network panel visible. Sort by transferred size and inspect several large text responses.

Check Content-Encoding, Content-Type, transfer size versus resource size, Vary, cache status, and whether the response actually came from the network. Then repeat controlled requests with gzip, Brotli, and — where supported — Zstandard, plus identity.

The goal is a traceable matrix: which resource types are encoded where, with which coding, by which infrastructure layer?

What Website-Pflichtencheck would inspect

A performance and hosting review follows the public delivery chain rather than trusting a hosting toggle. It can examine Accept-Encoding and Content-Encoding, transfer sizes, Brotli/gzip/Zstandard fallback behavior, unexpectedly uncompressed MIME types, CDN/proxy/origin behavior, cache variants and Vary, ETags, static precompression, unnecessary compression of media, and CPU or TTFB effects on dynamic responses.

The useful finding is not “Brotli: on.”

It is: important text responses reach real visitors in an appropriate compressed representation consistently, without shifting the cost into broken caching or excessive server work.

If nobody on the team can say which layer actually performs compression, measure the real chain once — before spending days shaving kilobytes from bundles while the delivery path is still shipping avoidable bytes.