Add new compression algos: ZSTD & BROTLI superior to GZIP

[stevenkain]

Every browser and newer webserver now already has ZSTD and Brotli file compression implemented. They are faster, more efficient and compress better than GZIP, which soon will (is) be obsolete and sunsetted by all.

Proposal to have these new compression algorithms added (or even have them replace) GZIP in the Lucee admin output section, along with compression level (1-9) and a minimal output size option, above which compression will kick in.

Benefits will include faster Lucee output, faster cfm page loading to the client browser as well as possibly more pages to be served within the same buffer/request response. Apparently ZSTD is superior.

Unfortunately this must be done at the Lucee servlet level, even though Java 21 is capable of Brotli compression, its implementation does not work directly with Lucee dynamic file output by tinkering in the server.xml or web.xml settings.

Ref. article (could not make it work):

Compress Files with brotli in Lucee | Compression Algorithms in Programming

Similar topic on this forum: Bug: GZip compression + new request (Brotli) - #5 by stevieosaurus

[Zackster]

Yeah, this has also been on my radar too

That said, but isn’t this something the webserver usually handles?

I think most people deploy Lucee behind a webserver?

[stevenkain]

That was my reasoning so as well, alas webservers and rev.proxys only seem to apply custom compression to static text files (css, js, xml, fonts, etc.) otherwise, in the case of dynamic content, they either deffer said task to the app server - in our case Lucee/Tomcat - or seem to respect, keep & serve those as received.

Even with every file compression setting turned off (Lucee admin, Tomcat connector in the server.xml, webserver setttings) cfm files still get served as gzip, while all others are br as revealed in the response header.