A fetched HTML response did not advertise a recognized content encoding
ShipReady observed a final HTTP 200 HTML response without a Content-Encoding token it recognizes as compression.
Why it matters
A missing compression signal on an HTML response is a bounded header observation worth checking in deployment configuration.
How ShipReady detects it
What it inspects
ShipReady makes one streamed redirect-following HTTP GET and reads the final status and headers without reading the body.
What triggers a finding
It triggers when the final response is HTTP 200, Content-Type starts with text/html, and Content-Encoding lacks gzip, br, deflate, zstd, or compress.
What the evidence shows
The evidence proves the sampled final HTML response did not advertise a recognized compression encoding during the scan.
Limits of this check
The base response must be successfully fetched with status 200 first. Failures and 408, 429, or 5xx final responses are incomplete rather than findings.
ShipReady does not measure response size, byte savings, browser decoding, all routes, CDN behavior, real-user performance, rankings, or conversion impact.
How to fix it
Review the observed evidence
Review compression configuration at the server, CDN, or host.
How to verify the change
Verify the intended behavior
Inspect final deployed HTML response headers.
Expected: The intended response advertises the chosen compression encoding.