This is an old revision of the document!


LSWS v5.3 Brotli and gzip Enhancements

LiteSpeed Web Server has included Brotli compression support for a while, but it was only for static files. As of v5.3, Brotli compression has been added for dynamic responses. Additionally, automatic gzip and Brotli conversion has been added for cached pages.

To test Brotli compression, the client (browser) must be Brotli compatible. Google Chrome v49+ and Mozilla Firefox v44+ are both good candidates for Brotli testing. Also, you will need to run tests over an HTTPS connection. It cannot be an HTTP connection.

Negotiation is done via the Accept-Encoding: br request header. Servers can add “br” to Content-Encoding: br to encode a response with Brotli.

The following page header shows Content-Encoding:gzip, since it is only an HTTP connection.

When we test an HTTPS connection for the same domain, the header shows Content-Encoding:br.

Good pages to test include any HTTP WordPress pages without ESI on them, like above. LSWS will use Brotli compression by default, instead of gzip, as long as the client supports it. (Make sure to test an HTTPS connection instead of HTTP.) For ESI pages, however, gzip compression will be used. This is because LiteSpeed-cached ESI pages, such as on a Magento site, are optimized for gzip.

The following image shows Accept-Encoding: br is sent, but Content-Encoding:gzip is returned since it is an ESI Magento page.

LSWS 5.3 can cache both Brotli- and gzip-compressed copy, convert between them, and cache the result.

To save on disk space, there is a hit limit before LSWS is triggered to save the other compression result. For example, if the Brotli version is cached, and the client requests gzip, LSWS will dynamically decompress the Brotli version, re-compress as gzip, serve the resquest, and discard the result. If there are more than 10 such requests, the gzip version will be cached, and the next request will be served directly from cache. To avoid misleading benchmark results, LSWS and ADC will immediately cache the result for a different compression version, if a benchmark tool has been detected via User-Agent. When Accept-Encoding request header is not set, the result will not dynamically expand. Currently, “Apache Bench” is detected.

To test the cache engine, we will use two browsers: Chrome, using Brotli encoding, and Firefoc using gzip encoding.

First, use Chrome. You will see Content-Encoding: br on both the first visit cache miss and the second visit cache hit.

First Visit:

Second Visit:

Next, use Firefox, and manipulate Accept-Encoding to gzip only: Accept-Encoding:gzip.

On the first visit, you will still see Content-Encoding: br since it is the default setting. Also, it is a cached page.

Edit and press Send to change the header to Accept-Encoding:gzip:

After sending, you will see the cached page has been auto converted to gzip compression, even though the initial cached version was Brotli compressed.

  • Admin
  • Last modified: 2018/08/20 14:40
  • by Lisa Clarke