Brotli compression for dynamic responses and automatic GZIP and BROTLI conversion for cached pages

LSWS has added brotli compression support for a while, but it used to be for static files only. Starting with LSWS 5.3, Brotli compression for dynamic responses has been added. Also, LSWS will do automatic GZIP and BROTLI conversion for cached pages.

To test brotli compression, the client (browser) must be Brotli compatible. Google Chrome: Chrome 49+ and Mozilla Firefox: Firefox 44+ are good for brotli testing. Also, you will need to run test over an HTTPS connection, can not be a HTTP connection.

wich 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 HTTP connection for the same domain.

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

You should test a page without ESI on it, such as a https wordpress page as indicated as above. LSWS will use brotli compression as default instead of gzip as far as client supports it(make sure to test HTTPS connection instead of HTTP). However, for ESI pages, gzip compression will be used since LiteSpeed cached ESI pages are optimized for gzip, such as a Magento page.

The following image shows even “accept-encoding: br” sent but still return “content-encoding: gzip” since it is a ESI Magento page.

LSWS 5.3 can cache both br and gzip compressed copy and convert from between them and cache the result. To save on disk space, there is a hit limits to trigger LSWS to save the other compress result. For example, if br version is cached, and client request gzip, it will dynamically decompress br, then compress as gzip, the result is discarded. If there are more than 10 such requests, the gzip version will be cached, next request will be served directly from cache. To avoid misleading benchmark results, LSWS and ADC will immediately cache the result for different compression version if a benchmark tool has been detected via User-Agent, not to dynamically expand when Accept-Encoding request header is not set. Currently, “Apache Bench” is detected.

To test the cache engine, we will use two browsers to make such testing, one(Chrome) uses BR encoding, one(Firefox) use GZIP encoding.

First, use Chrome, you will see “content-encoding: br” on both first visit cache miss and second visit cache hit.

First Visit:

Second Visit:

Second, use Firefox and manipulate Accept-encoding to gzip only “Accept-encoding:gzip”.

First Visit, you will still see “content-encoding: br” since it is default setting. Also it is a cached page.

Use “edit and send” to change to “Accept-encoding:gzip”:

After “send”, you will see the cached page has been auto converted to gzip compression even initial cached version was br compression version.