Enable text compression

Text compression on a web server can have several benefits, including:

1. Reduced bandwidth usage: Compressing text data before sending it to the client can significantly reduce the amount of data that needs to be transmitted. This can lead to faster page load times for users, especially for those on slow connections.
2. Reduced server load: By reducing the amount of data that needs to be sent to clients, text compression can also reduce the load on the server. This can help to improve the overall performance of the server and allow it to handle more traffic.
3. Cost savings: By reducing the amount of data that needs to be transmitted, text compression can also help to reduce the cost of data transfer for web hosts and other organizations that pay for bandwidth.
4. Improved security: Text compression can also be used to improve the security of a website by reducing the amount of information that is visible to potential attackers.
5. Improved Caching: When the text is compressed before sending it to the client, it can also increase the cache-ability of the text, which means that the browser will store the compressed text, and will not need to download the text again next time the user visits the website.

The most common text compression method is Gzip, which is supported by most web servers and web browsers. Other methods such as Brotli, which is an open-source data compression library, is also supported by many modern browsers and can provide better compression ratio than Gzip.

Resources should be served with compression to minimize total network bytes.

How Sitefig handles text compression

Sitefig gathers all responses that:

• Have text-based resource types.
• Do not include a content-encoding header set to br, gzip, or deflate.

Sitefig then compresses each of these with GZIP to compute the potential savings.

If the original size of a response is less than 1.4KiB, or if the potential compression savings is less than 10% of the original size, then Sitefig does not flag that response in the results.

potential savings that Sitefig lists are the potential savings when the response is encoded with GZIP. If Brotli is used, even more savings are possible.

How to enable text compression on your server

Enable text compression on the server(s) that served these responses in order to pass this audit.

When a browser requests a resource, it will use the Accept-Encoding HTTP request header to indicate what compression algorithms it supports.

Accept-Encoding: gzip, compress, br

If the browser supports Brotli (br) you should use Brotli because it can reduce the file size of the resources more than the other compression algorithms. Search for how to enable Brotli compression in <X>, where <X> is the name of your server. As of June 2020 Brotli is supported in all major browsers except Internet Explorer, desktop Safari, and Safari on iOS. See Browser compatibility for updates.

Use GZIP as a fallback to Brotli. GZIP is supported in all major browsers, but is less efficient than Brotli. See Server Configs for examples.

Your server should return the Content-Encoding HTTP response header to indicate what compression algorithm it used.

Content-Encoding: br

Check if a response was compressed in Chrome DevTools

To check if a server compressed a response:

1. Press Control+Shift+J (or Command+Option+J on Mac) to open DevTools.
2. Click the Network tab.
3. Click the request that caused the response you're interested in.
4. Click the Headers tab.
5. Check the content-encoding header in the Response Headers section.

To compare the compressed and de-compressed sizes of a response:

1. Press Control+Shift+J (or Command+Option+J on Mac) to open DevTools.
2. Click the Network tab.
3. Enable large request rows. See Use large request rows.
4. Look at the Size column for the response you're interested in. The top value is the compressed size. The bottom value is the de-compressed size.