Web pages on the specified URL host text-based assets that are not served with compression activated.
Why is this important?
Enabling compression of text-based assets reduces the size of data transmitted via the network, without compromising user experience. Smaller sized resources like HTML, CSS, and JavaScript are delivered more efficiently when compressed.
What does the Optimization check?
This Optimization becomes active for any internal URL that hosts text-based assets which lack a content-encoding header indicating br, gzip, or deflate compression methods.
Loud Interactive leverages GZIP to estimate potential savings after compression. Resources smaller than 1.4KiB, or those where compression yields less than a 10% reduction in size, are not highlighted as issues.
How do you resolve this issue?
To address this matter, server-side text compression needs to be implemented.
The Accept-Encoding HTTP request header sent by browsers informs the server of the compression formats it can interpret.
Whenever possible, opt for Brotli compression for its superior efficiency in reducing file sizes when compared to other algorithms.
Should Brotli be unsupported, GZIP stands as the alternative. Although not as effective as Brotli, it enjoys widespread support across all major browsers.
It is then the server’s responsibility to reflect the employed compression algorithm via the Content-Encoding HTTP response header.
Further Reading
Enable text compression (Lighthouse documentation)