Check whether a response uses gzip compression
Inspect Content-Encoding on an actual GET response, then compare transfer sizes for a stable resource.
Look for Content-Encoding: gzip on the response you want to test. It confirms gzip for that response, not for every resource on the site. Send Accept-Encoding: gzip so the server knows the client accepts it.
Inspect a GET response with curl
curl -sS -H 'Accept-Encoding: gzip' -D - -o /dev/null \
https://example.com/assets/app.js
Check the status code as well as the encoding header. If the response redirects, test the final resource or deliberately follow redirects and inspect the final response. A successful compressed error page is not evidence that the intended asset is compressed.
Curl does not ordinarily advertise compression unless you request it. --compressed negotiates supported encodings and decompresses the returned body automatically; adding a specific request header is useful when testing gzip itself.
For a stable resource, compare downloaded body bytes:
curl -sS -H 'Accept-Encoding: identity' -o /dev/null \
-w '%{http_code} %{size_download}\n' https://example.com/assets/app.js
curl -sS -H 'Accept-Encoding: gzip' -o /dev/null \
-w '%{http_code} %{size_download}\n' https://example.com/assets/app.js
Confirm the response headers for both runs and keep content, authentication, and cache conditions comparable. Counting --compressed output with wc -c measures decompressed bytes, not the compressed body on the wire. HEAD requests can also behave differently from GET, so use GET to verify the transfer users receive.
Check in browser developer tools
Open the Network panel, reload, and select the actual HTML, CSS, JavaScript, or API request. Inspect Response Headers for Content-Encoding. br indicates Brotli rather than gzip; it is also compression, but it does not prove gzip support.
Transferred and decoded resource sizes are useful clues. Cache hits, service workers, header overhead, and browser accounting can affect the displayed difference, so do not treat it as a precise general compression ratio.
Configure compression where it belongs
For Nginx, an example policy is:
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;
gzip_min_length 1k;
gzip_vary on;
Nginx includes text/html in gzip handling already. Its minimum-length check uses the response Content-Length; other response and proxy conditions can also affect compression.
With Apache's mod_deflate loaded:
AddOutputFilterByType DEFLATE text/html text/css application/javascript
Validate and reload the configuration, then test the endpoint. JPEG, PNG, video, and WOFF2 are already compressed and often gain little from another layer; text formats such as JSON and SVG can benefit. Measure size, CPU cost, and latency rather than assuming a fixed saving.
Check origin and CDN responses separately, including Vary: Accept-Encoding handling in shared caches. Apply the application's policy for responses containing secrets and attacker-controlled input, where compression can introduce information leaks.
An HTTP test in Guance can send the chosen header and assert the expected response header for that resource. It verifies a specific request, not a site-wide compression guarantee.
References: curl options, Nginx gzip, and Apache mod_deflate.
Contact us
Join the community
to join the community
Try Guance
Start online and pay only for what you use.
Get startedChoose a Guance plan