In one paragraph
Gzip compression not enabled means the scanned HTML response did not carry a content encoding recognised as compressed by this check. Enable suitable text compression at the application delivery layer, honour the client's accepted encodings, and verify the final public response. Brotli or another supported encoding can satisfy the goal; the finding does not mean gzip is the only valid option.
Why it matters
HTML, CSS, JavaScript, JSON, and SVG often contain repeated text that compresses well. Sending fewer bytes can reduce transfer time, especially on constrained connections. The actual benefit depends on document size, compression settings, cache state, and the critical path.
HTTP negotiates content encoding through Accept-Encoding, and the response identifies the applied representation encoding through Content-Encoding. This is distinct from the file's MIME type. Do not label already-compressed bytes as plain text without the right encoding header or send a coding a client cannot handle.
Compression saves transfer bytes, not the decompressed work the browser must parse and execute. A huge script or document can remain expensive after the network payload shrinks. Precompressed images and other binary formats usually need a different optimisation strategy.
How WebAuditOS evaluates this finding
The supplied rule requests gzip, deflate, and Brotli and grades responses whose content type contains html. A Content-Encoding containing br, gzip, or zstd passes; absent or other values fail. Non-HTML or unavailable responses are not graded.
The rule treats deflate as a failure even though it is a compression coding. It checks header recognition, not byte savings or negotiation correctness. Its acceptance of a zstd label is not permission to serve it to a request that did not advertise support. CSS and JavaScript require separate inspection.
How to fix it
- Inspect the exact failing response, including status, Content-Type, Cache-Control, and final delivery layer. HTML errors, bypass routes, and uncached responses may come from a different component than the homepage.
- Enable compression in a suitable layer: managed edge, reverse proxy, or application. Understand which component receives uncompressed content and which emits the final representation. Avoid accidental recompression and duplicate header manipulation.
- For nginx, gzip is available through its supported compression module. A minimal illustrative fragment is:
gzip on;
gzip_min_length 1024;
gzip_types text/css application/javascript application/json image/svg+xml;HTML handling is already part of nginx's gzip behaviour; review the exact module documentation and production configuration. Brotli availability depends on your build or platform rather than being a universal built-in switch.
- Choose compression levels suited to the workload. Build-time compression can spend more effort on immutable files, while expensive dynamic compression can add CPU time or latency. Measure rather than assuming the highest level is always fastest.
- Confirm correct negotiation and cache variation. Your edge must distinguish encoded variants appropriately, commonly through Vary: Accept-Encoding or an equivalent documented platform mechanism. Preserve any other existing Vary values.
- Inspect a normal GET with an accepted encoding, for example:
curl -sS -H 'Accept-Encoding: gzip, br' -D - -o /dev/null https://example.com/Replace the URL and compare a request with no compression where useful. Check the actual Content-Encoding and successful browser decoding, not only a configuration checkbox.
- Test streaming routes, APIs, and sensitive responses separately. Buffering can delay server-sent events or streamed rendering. Compression involving reflected input and secrets can need additional analysis for compression side channels; do not disable all compression without assessing the actual context.
- Rescan HTML and inspect representative text assets. Compare transferred size, timing, CPU use, and error rates to confirm a practical improvement.
What the fix can break
Incorrectly transformed encoded responses can produce decoding errors or unusable content. A proxy stripping Content-Encoding without decoding the body is not a valid optimisation.
Streaming can become visibly delayed if a layer buffers to compress. Scope or configure those routes deliberately and test incremental delivery.
A failed header check on a tiny response does not establish a material performance problem. The scanner's rule and your chosen minimum compression size can differ. Document that tradeoff rather than inflating a negligible issue into a guaranteed speed loss.
Questions
Must I use gzip specifically?
No. Use a suitable coding supported by the client and delivery stack. The supplied rule also recognises Brotli and zstd labels.
Is deflate uncompressed?
No. It is a compression coding, but the supplied check does not accept it as a passing value. Distinguish that rule from protocol semantics.
Does this check prove CSS and JavaScript are compressed?
No. The documented grading scope is HTML responses. Inspect assets separately.
What should I review next?
Review HTML size, caching, and the Core Web Vitals guide.