Compression checker

A request is made advertising support for the compression encodings in common use, which is what any browser sends.

The Content-Encoding header on the response is read. That header, and not the response size, is what says compression was applied.

The same is done for the text resources the page references — stylesheets and scripts — because those are frequently served by a different layer from the HTML.

Binary resources are not expected to be compressed and are not reported. Images and video are already compressed formats, and re-compressing them costs processor time for nothing.

The HTML is usually produced by the application server, and compression there is a framework or web-server setting someone turned on years ago.

Static assets are frequently served by something else entirely — a separate location block, an asset host, a CDN — each with its own configuration.

That second configuration is the one that gets missed, because nothing about the site looks wrong: the page loads, it is simply heavier than it needs to be.

A CDN adds a further wrinkle. Some compress at the edge regardless of the origin, which means the origin can be misconfigured and invisible from outside until the edge is bypassed.

Which is why testing the assets separately from the document is the whole point of this check rather than a refinement of it.

Content-Encoding present on the HTML document and on every text resource referenced by it.

A modern encoding where the client offered one, since the newer algorithms transfer meaningfully fewer bytes than the oldest at comparable cost.

No compression on already-compressed binary formats, which is correct rather than a gap.

Consistency across hostnames: the asset host compressing on the same terms as the document host.

Uncompressed stylesheets or scripts. This is the common finding and usually the largest single transfer saving available on a site, because text compresses well and those files are large.

An uncompressed HTML document, which is rarer and indicates compression was never enabled rather than partially configured.

Compression applied at the edge but not at the origin, which is fine for visitors and becomes a problem the day traffic bypasses the edge.

A response that ignores the client's advertised support entirely, which is usually a proxy stripping the negotiation header on the way through.

`performance.compression` reads whether responses are compressed. `performance.resource_compression` reads Content-Encoding specifically for the text resources — stylesheets and scripts — referenced by the page.

`performance.page_weight` reports the total transfer weight observed, which is the number the compression finding moves.

`performance.scan_limits` states how much of the resource inventory could really be measured, so a clean result is never read as more coverage than it had.

Only resources the scan fetched are reported. A resource outside the measurement budget is not tested, and the coverage statement says so.

The result describes the path from the scanner. A visitor behind a different edge node can receive a different answer.

Compression ratio is not reported per resource; what is established is whether the encoding was applied at all.

Resources loaded by script after the page renders may not be in the inventory, since the inventory is built from what the served HTML references.