content-encoding

The "content-encoding" HTTP response header is set by the server to inform the client about the encoding used to transfer the data. To save bandwidth, servers usually compress that data before sending it. Because there are a variety of different ways to compress data, the server needs to tell the client which algorithm it used, so that the data can be correctly decompressed or decoded. Here are the most common values:

• gzip - The gzip compression algorithm is very common and widely used to compress files and data in transit.
• compress - A compression algorithm that is seldom used due to patent issues.
• deflate - A compression algorithm that uses the zlib format.
• br - Uses the Brotli algorithm which is a newer algorithm that provides better compression than the other methods.

The client typically sets an "accept-encoding" request header to let the server know which types of compression it understands. For example: gzip, deflate, br would tell the server that it can pick from any of the three listed methods. The server then picks its preferred method, encodes the data and sets the "content-encoding" response header to tell the client which method it selected.

To save bandwidth and make the page load faster, it is highly recommended to configure your server to compress data before sending it. All web browsers support this, so there is no downside. Keep in mind that compression should only be applied to certain file types, typically text or html files, that will benefit from it. Most images (png, jpg, webp, etc) are already compressed, so compressing it again will be wasted computation and will not provide any benefit.

For more information, please read the documentation on MDN Web Docs.