After enabling CDN compression, responses may stay the same size, become larger, or fail with corrupted downloads, decompression errors, or garbled API output. The usual problem is not that a compression algorithm stopped working. More often, a cache contains the wrong encoding variant, the origin and CDN compress the response twice, or the request and response variants are not separated correctly.
Do not troubleshoot this only through the CDN compression toggle. Compare what the client receives, what the CDN requests from the origin, the cache key, and the origin's Content-Encoding in one request path. The examples below use public text, CSS, JavaScript, and JSON responses; apply them only within the scope supported by your CDN configuration.
Establish where the mismatch occurs
Capture three sets of evidence: the response headers and body received by the client, the headers returned by the origin to the CDN, and the origin's unencoded source content. Record Content-Encoding, Content-Length, Transfer-Encoding, Vary, Cache-Control, ETag, and cache status. Do not repeatedly create misses with random parameters on large production objects.
Using the same URL, send one request with and one without Accept-Encoding. Compare the decoded content and its digest, not compressed bytes with uncompressed bytes. Document whether curl was asked to decompress automatically; its behavior depends on the command options.
curl -sS --compressed \ -D response-compressed.headers -o response-compressed.body \ 'https://cdn.example.com/assets/app.js' curl -sS \ -H 'Accept-Encoding:' \ -D response-plain.headers -o response-plain.body \ 'https://cdn.example.com/assets/app.js' sha256sum response-compressed.body response-plain.body
The second request is only an example. Providers differ in how they handle an empty Accept-Encoding, default encodings, and cache-key construction. Confirm that the test object can be read this way and record the actual response headers.
Keep Content-Encoding and cache variants aligned
Content-Encoding: gzip or br tells the client how to decode the response body. If the body is encoded but the header is missing, or the declared encoding does not match the bytes, browsers and API clients may report a decompression error.
The same URL may need separate responses for different Accept-Encoding values. Vary: Accept-Encoding communicates that requirement, but whether the CDN handles it automatically or includes it in the cache key depends on the provider and cache rules. Seeing Vary in one response is not proof that every edge stores variants in the same way.
Check these values together:
the client's
Accept-Encodingrequest header;the cache object and cache key selected by the CDN;
the request headers sent to the origin;
the origin's
Content-EncodingandVaryresponse headers;whether the CDN encoded the body again before sending it to the client.
Be especially careful with authenticated pages, personalized JSON, and responses carrying user state. Ignoring a header that affects the response merely to improve the hit ratio can mix content between users.
Double compression is more dangerous than weak compression savings
A common failure path is an origin returning gzip while the CDN fails to preserve or recognize that state and compresses the body again. The client may receive two encoding layers but only one Content-Encoding declaration. Another variation is a CDN changing length or validation headers without keeping them consistent with the body.
Define one clear compression boundary between the origin and CDN. If the origin already compresses an object, either pass it through or use a provider-supported decode-and-reencode path; do not let both layers compress unconditionally. Static .gz and .br files also should not be classified only by filename extension.
Validate a test file with its decoder. For gzip:
gzip -t response.body
This checks only whether the file is valid gzip data. It does not prove that the HTTP headers, cache variants, or decoded application content are correct. For Brotli, use a trusted brotli utility in the test environment and record its version.
A cache can preserve the wrong encoding variant
When compression settings or origin headers change, an existing cache object does not automatically become correct. Some edges may have filled a new variant while others still return an older encoding. The result can be regional or intermittent failures.
Group the anomaly by URL, Accept-Encoding, cache status, edge, and Age. Do not invalidate only the HTML: its CSS, JavaScript, font, and API objects may have independent cache entries. Prefer a precise invalidation of affected paths after confirming that the origin consistently returns the correct body.
A precise invalidation does not clear browser caches, service workers, or another hostname. Keep the configuration-change time, invalidation job ID, verification edge, and response-header summary in the deployment record. A broad purge increases origin load and does not fix a bad cache key.
Why a compressed response can appear larger
Compression is not guaranteed to reduce small text responses, data that is already compressed, or data with little repetition. The compression stream has its own overhead. If the comparison uses transport-level bytes, TLS, chunked transfer, or different metric scopes can also be mixed into the result.
Images, video, archives, and compressed packages usually should not receive the same text compression again. Decide using MIME type, size, and observed response behavior rather than a file extension alone. A minimum-size threshold can be safer than forcing compression on every object, but thresholds and compression levels trade CPU for transfer size and latency.
When someone says that a response became larger, separate origin-object size, CDN-to-client body size, client-received bytes, and billable bytes. They are different measurements.
Fix and verify in a controlled sequence
Start with a small public test object. Confirm that the origin is not already double-compressing it and that the headers match the body. Then review the CDN compression rule, cache key, and Vary handling. Finally, invalidate only the affected resource paths. Do not switch compression globally without a rollback configuration and a test object.
Test at least one client that supports gzip or Brotli, one request without Accept-Encoding, and two different networks or edges. Compare the decoded body digest, Content-Encoding, Vary, ETag, response size, error rate, and origin-fetch volume.
For APIs and downloads, verify whether the client already decompresses automatically. Forwarding an automatically decoded body as if it were still compressed can create another processing error. Change one variable at a time and preserve the previous configuration, invalidation scope, and rollback steps.
References
Sources reviewed November 10, 2026. The commands are controlled read-only and file-validation examples; they do not claim testing in the reader's production environment.
