Webhint - Optimal Compression Hint

[lucaskardo]

http-compression warns against serving resources uncompressed or using an inappropriate encoding.

Why is this important?
One of the fastest and easiest ways one can improve web site/app performance is to reduce the amount of data sent to the client by using HTTP compression. This not only reduces the data used by the user, but can also significantly cut down on the server costs.

Here are a few rules to follow to get the most out of compressing resources:

Only compress resources for which the result of the compression will be smaller than original size.

In general text-based resources (HTML, CSS, JavaScript, SVGs, etc.) compress very well especially if the file is not very small. The same goes for some other file formats (e.g.: ICO files, web fonts such as EOT, OTF, and TTF, etc.)

However, compressing resources that are already compressed (e.g.: images, audio files, PDFs, etc.) not only wastes CPU resources, but usually results in little to no reduction, or in some cases, results in an increase in file size.

The same applies to resources that are very small because of the overhead of compression file formats.

Use the most efficient compression method.

gzip is the most used encoding method currently as it strikes a good balance between compression ratio (as high as 70% especially for larger files) and encoding time and is supported pretty much everywhere.

Better savings can be achieved using Zopfli which can reduce the size on average 3–8% more than gzip. Since Zopfli output (for the gzip option) is valid gzip content, Zopfli works everywhere gzip works. The only down side is that encoding takes more time than gzip, making Zopfli more suitable for static content (i.e. encoding resources as part of a build script, not on the fly).

Things can be improved even further using Brotli. This encoding can achieve 20–26% higher compression ratios over Zopfli. However, this encoding is not compatible with gzip, limiting the support to modern browsers and its usage to only over HTTPS (as proxies misinterpret unknown encodings).

As a rule, for best performance and compatibility, resources should be served compressed with Zopfli over insecure HTTP, and Brotli when sending over HTTPS with a fallback to Zopfli if HTTPS is not supported.

Avoid using deprecated or not widely supported compression formats, and Content-Type values.

Avoid using deprecated Content-Type values such as x-gzip. Some user agents may alias them to the correct, current equivalent value (e.g.: alias x-gzip to gzip), but that is not always true.

Also avoid using encodings that are not widely supported (e.g.: compress, bzip2, sdch, etc.), and/or may not be as efficient, or can create problems (e.g.: deflate).

Avoid potential caching related issues.

When resources are served compressed, they should be served with the Vary header containing the Accept-Encoding value (or with something such as Cache-Control: private that prevents caching in proxy caches and such altogether).

This needs to be done to avoid problems such as an intermediate proxy caching the compressed version of the resource and then sending it to all user agents, whether they support that encoding or even requested the compressed version.

Resources should be served compressed only when requested as such, appropriately encoded, and without relying on user agent sniffing.

The Accept-Encoding request header specified should be respected. Sending a resource encoded with a different encoding than one of the ones accepted can lead to problems.

Here are some examples:

If the user agent makes a request containing the Accept-Encoding: identity header, that means it wants the response to not be transformed in any way, so the server should send the data uncompress.

If the user agent makes a request containing the Accept-Encoding: gzip, br header, that means it wants the response to either be uncompress or compress with one of the specified encodings, namely: gzip (or the gzip compatible Zopfli) or Brotli. In the optimal case, the server sends the data compress with Zopfli over HTTP, and Brotli over HTTPS.

Dealing with special cases.

One such special case is SVGZ files that are SVG files compressed with gzip. Since they are already compressed, they shouldn’t be compressed again. However, sending them without the Content-Encoding: gzip header will create problems as user agents will not know they need to decompress before trying to display them.

What does the hint check?
The hint checks for the use cases previously specified. Namely, it checks that:

Only resources for which the result of the compression is smaller than original size are served compressed.

The most efficient encodings are used (by default the hint check if Zopfli is used over HTTP and Brotli over HTTPS, however that can be changed, see: Can the hint be configured? section).

Deprecated or not widely supported encodings, and Content-Type values are not used.

Potential caching related issues are avoided.

Resources are served compressed only when requested as such, are appropriately encoded, and no user-agent detection is done.

Special cases (such as SVGZ) are handled correctly.

Expected Behavior:

Arjan should recommend you to run arjan optimize to fix this issue.

https://webhint.io/docs/user-guide/hints/hint-http-compression/