A compressible response was sent uncompressed

MediumConfirmedQuick winhttp.headers.compression-not-applied

What this check looks for

This page is text, it is big enough to be worth compressing, and we asked for a compressed copy — the server sent it in full anyway. Visitors are downloading several times more data than they need to.

Why it matters

Text compresses by roughly three to four times. Every visitor on a phone or a slow connection waits for bytes that did not have to be sent, and it is one of the few speed problems fixed by a single line of configuration.

When the check passes, your report says: “A compressible response was sent compressed”.

What it costs your score

When this check fails it removes 8 points from your HTTP score, before the status, confidence and repeat multipliers are applied. HTTP carries a weight of 7 in the overall score.

It shares the http.compression family ceiling of 18 points: however many findings that family produces, together they cannot remove more than that from HTTP. One underlying problem showing up in several places is still one problem.

Severity: medium
Default confidence: confirmed
Status when triggered: warn
Deduction: 8 points
Family cap: http.compression · 18
Category: HTTP
Module: Http headers
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Turn on compression for text content types, and include the ones that are usually forgotten.

Uncompressed text costs every visitor three to four times the bytes for no benefit.

Enable gzip at minimum; add Brotli where the module is available, since it compresses text noticeably better at the same CPU budget.
List the types explicitly: HTML, CSS, JavaScript, JSON, XML, SVG and plain text. JSON and SVG are the two most often missing.
Do not compress already-compressed formats — images, video, woff2 — it costs CPU and saves nothing.
Set a minimum size of a few hundred bytes; below that the framing overhead can make the response larger.
If a proxy sits in front, confirm it forwards Accept-Encoding rather than stripping it.
Make sure Vary: Accept-Encoding goes out with the compressed response, or a shared cache will serve the wrong body to the wrong client.

How to confirm it worked

curl -sSI -H 'Accept-Encoding: gzip, br' https://‹host›/ | grep -i content-encoding
curl -sS -o /dev/null -w '%{size_download}\n' -H 'Accept-Encoding: gzip, br' https://‹host›/ — compare against the same request with Accept-Encoding: identity

The configuration to publish

Content-Encoding: br
Vary: Accept-Encoding

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

nginx

gzip on;
gzip_vary on;
gzip_min_length 256;
gzip_comp_level 5;
gzip_types text/plain text/css text/xml application/javascript application/json image/svg+xml;

# Brotli, if the ngx_brotli module is available:
# brotli on;
# brotli_types text/plain text/css text/xml application/javascript application/json image/svg+xml;

Apache

<IfModule mod_deflate.c>
	AddOutputFilterByType DEFLATE text/html text/plain text/css text/xml application/javascript application/json image/svg+xml
</IfModule>

<IfModule mod_brotli.c>
	AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript application/json
</IfModule>

Caddy

encode zstd gzip

Cloudflare

Speed → Optimization → Content Optimization, or Rules → Overview → Create rule → Compression Rule to choose the algorithm per path. Dashboard paths as at 2026-09.

text/html is always compressed by nginx and must not be listed in gzip_types — listing it logs a duplicate-MIME warning. Brotli is not part of a stock nginx build: brotli on; fails to start a server without the ngx_brotli module compiled in, so leave those lines commented until nginx -V shows it.
Shown because the response identified Apache. Put it in the virtual host or server configuration rather than .htaccess: .htaccess is re-read on every request, is often disabled by AllowOverride None, and runs too late to influence a response the virtual host generates itself. mod_deflate adds Vary: Accept-Encoding on its own. mod_brotli ships with Apache 2.4.26 and later but is not enabled by default — a2enmod brotli, or the equivalent LoadModule line, is required, and the IfModule guard keeps the configuration valid until then.
Caddy's encode directive negotiates the encoding and sets Vary: Accept-Encoding itself. A stock Caddy build offers gzip and zstd; Brotli is not one of its on-the-fly encoders, so do not write encode br and expect it to work.
This applies only to responses that reach visitors through Cloudflare. An origin that is reachable directly — by IP, or through a DNS record that is not proxied — still serves the response measured here unchanged. Setting it at the origin as well covers both paths. Cloudflare compresses eligible responses by default, so a response measured as uncompressed here usually means the scan reached the origin directly.

Technical detail

The request offered Accept-Encoding: gzip, br; the response from ‹origin› came back with no Content-Encoding, as ‹content type›, ‹bytes› bytes. ‹detail›

The usual causes, in the order worth checking:

The content type is not in the server's compression list. This is the most common one: gzip_types and AddOutputFilterByType are explicit allow-lists, and a JSON or SVG response is routinely left out of them.
A minimum-size threshold is set higher than the response.
The response is proxied and the proxy strips Accept-Encoding from the request before the origin sees it.
A legacy gzip_disable rule aimed at browsers that have not existed for a decade.

Compressing already-compressed formats — JPEG, PNG, WebP, MP4, woff2 — is wasted CPU for no gain, so this rule only reports genuinely compressible types. Detected server: ‹detected server›.