> ## Documentation Index
> Fetch the complete documentation index at: https://docs.37audits.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Content Encoding Auditor
> Checks whether Content-Encoding advertises Gzip, Deflate, Brotli, or Zstandard compression
**Performance Auditor** — checks whether `Content-Encoding` advertises a recommended compression coding.
Gzip, Deflate, Brotli, and Zstandard shrink HTML and other text so pages transfer faster.
Header syntax follows RFC 9110 §8.4; stacked encodings in one field are valid.
This auditor fetches the audited URL with `Accept-Encoding: gzip, deflate, br, zstd` and inspects `Content-Encoding`. It does **not** decompress the body or verify that the bytes match the declared coding.
## How it works
The auditor judges compression readiness from the `Content-Encoding` header:
1. **Parse** — requires a URL with a scheme and hostname. Invalid or empty URLs error.
2. **Fetch** — reads response headers with `HeadersCrawler`, asking for Gzip, Deflate, Brotli, and Zstandard. Every `Content-Encoding` field is collected and split on commas.
3. **Rules** — a missing header is a FAIL. A coding other than `gzip`, `deflate`, `br`, or `zstd` is a WARNING. More than one `Content-Encoding` field is a WARNING.
4. **Aggregate** — `ERROR` wins, then `FAIL`, then `WARNING`; if every rule passes, the audit is `SUCCESS`.
5. **Specification pin** — every run emits `37A-ContentEncodingAuditor-100` (`INFORMATION`) naming HTTP Content-Encoding [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-content-encoding) §8.4 (2022-06). That check does not change overall status.
Success messages use the algorithm name with the coding in parentheses, for example `Gzip (gzip)` or `Brotli (br)`.
## What it audits
Every row maps to one `checkRule*` method and one `CheckCode`. `37A-ContentEncodingAuditor-100` is emitted on every run, including fetch errors. The unknown-coding WARNING (`300`) is skipped when the header itself is missing (`400`). CheckCode suffixes use status ranges: `100` information, `200` success, `300–399` warning, `400–499` fail, `500–599` error.
| CheckCode | Status | When it fires | Recommendation |
| ------------------------------------------------------------------------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| `37A-ContentEncodingAuditor-100` | `INFORMATION` | Every run. Records that this auditor implements RFC 9110 §8.4 Content-Encoding. | — (recommendation is `null`; nothing for the site to change) |
| `37A-ContentEncodingAuditor-400` | `FAIL` | `Content-Encoding` is absent or blank. | Send Content-Encoding: gzip, br, or zstd on `{url}` so clients can receive compressed content. |
| `37A-ContentEncodingAuditor-300` | `WARNING` | At least one token is not `gzip`, `deflate`, `br`, or `zstd` (skipped when `400` applies). | Replace `{token}` on `{url}` with gzip, br, or zstd (current Content-Encoding is `{header}`). |
| `37A-ContentEncodingAuditor-301` | `WARNING` | More than one `Content-Encoding` header field was returned. | Send a single Content-Encoding header on `{url}`; the first value is `{first}`. |
| `37A-ContentEncodingAuditor-500` | `ERROR` | The URL is invalid or response headers could not be read. | Retry the audit of `{url}`; verify the URL is reachable. Last error was `{error}`. |
| `37A-ContentEncodingAuditor-200` | `SUCCESS` | A single header uses only recommended codings. Message is `Content-Encoding on "{url}" is {Algorithm} ({code}).` — Gzip (gzip), Deflate (deflate), Brotli (br), Zstandard (zstd). | — |
## Output documentation
| Status | Description | Test logic |
| --------------- | ---------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **SUCCESS** | The response advertises only recommended compression | Tokens are `gzip`, `deflate`, `br`, and/or `zstd` on a single `Content-Encoding` field (`200`). Message names the algorithm and puts the coding in parentheses. |
| **WARNING** | Compression is declared but should be reviewed | Unknown or obsolete coding such as `compress` or `identity` (`300`); more than one `Content-Encoding` field (`301`). Both warnings can appear together. |
| **FAIL** | The response does not advertise compression | Missing or blank `Content-Encoding` (`400`). |
| **ERROR** | The auditor could not read headers | Empty, blank, or invalid URL; fetch failure (`500`). |
| **INFORMATION** | Specification pin | Always emitted (`100`); does not change overall status. |
## Risks and considerations
### Uncompressed responses cost bandwidth
* HTML, CSS, JavaScript, and JSON shrink substantially under Gzip, Brotli, or Zstandard. Serving them uncompressed increases transfer time and hosting cost.
* Mobile and high-latency clients are hit hardest when `Content-Encoding` is missing.
### Unknown or stacked encodings
* `identity` means no transformation; clients receive uncompressed bytes even though the header is present.
* `compress` is a registered coding but is poorly supported. Prefer Gzip, Brotli, or Zstandard.
* RFC 9110 allows stacked encodings in one comma-separated field (`gzip, br`). Sending the same header twice is ambiguous for intermediaries.
### What this auditor does not check
* The body is not decompressed. A `Content-Encoding: gzip` header on uncompressed bytes will still succeed.
* Transfer-Encoding (`chunked`) is not judged here.
* Image, video, and already-compressed binary assets are often left uncompressed on purpose; this auditor still expects `Content-Encoding` on the audited URL.