A text response could benefit from compression
In the reportText response served uncompressed
text_compression_missing · Issue
This appears when a crawled page or fetched text file over 1 KiB arrives without Content-Encoding, although a local gzip trial shows it would be smaller. Compression can send the same text in fewer bytes. Enable Brotli or gzip for text types at your server or CDN.
Severity: Medium. This checked response sent more bytes than the gzip trial needed.
Why it matters
Compressed text reaches the browser in fewer bytes, and Lighthouse has long checked for it; since Lighthouse 13 the check is part of its document-latency-insight, which replaced the uses-text-compression audit.
What to do
- Look at the finding: it shows the response, its size and how many bytes the gzip trial saved.
- Turn on compression for HTML, CSS, JavaScript, JSON and SVG in your web server, CDN or hosting panel.
- Check that the reply then carries
Content-Encoding: brorgzip.
What we read
We read each crawled page response and up to 30 selected page files across the audit. A response is judged when it answered 200, was received in full, has a text type such as HTML, CSS, JavaScript, JSON or SVG, and its decoded body exceeds 1,024 bytes.
An unencoded response is reported when the recorded request offered both Brotli and gzip, its measured transfer and decoded byte counts agree, and a local gzip trial at level 6 saves at least one byte. A response with a recognised Content-Encoding is treated as encoded from its header.
A response can remain unchecked when the request did not offer both encodings, the response or body is incomplete, the file exceeds the 1 MiB capture limit, or the page exceeds the 2 MiB retained-body limit.
Example & evidence
Illustrative example — one script's response, not a live audit.
https://bakery.example/js/app.js was sent without Content-Encoding:
received: 184,320 bytes
gzip trial: 52,811 bytes
saving: 131,509 bytesThe script is text, over 1 KiB, and gzip would make it smaller, so it is reported with the pages that use it.
A possible correction: turn on Brotli or gzip for JavaScript on the server.
Confirm & check again
Check for yourself: open your browser’s developer tools on the Network tab, choose the page or file, and check its response Content-Encoding and transferred size.
Check again: Full audit — run a new full audit. A prior finding resolves only when the newly audited, previously affected pages have enough complete evidence to show the condition no longer applies, including evidence for files they still reference. Missing coverage does not prove a fix.
Limits & sources
The result applies to the encoding negotiated by this audit request. The saving comes from a local gzip trial on the captured body, not a second fetch or a measurement of the server’s own compression. A selected-file limit or incomplete page can leave coverage unknown.
Confidence: High because the headers are read and the trial is run locally on the retained decoded response body.
Sources
- Chrome for Developers, Lighthouse is moving to performance insight audits — lists text compression among the audits folded into Lighthouse's document latency insight. Checked 28 September 2026.
Editorial review: 29 September 2026