Skip to main content
Performance Auditor — checks whether Content-Encoding advertises a recommended compression coding.

Performance

Gzip, Deflate, Brotli, and Zstandard shrink HTML and other text so pages transfer faster.

Compatibility

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 §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.

​
Output documentation

​
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.