@dgrammatiko I have done this method too before my hoster finally enabled mod_deflate for shared hosting, but I did not use extension gz, I used jgz for reasons stated here:

• https://stackoverflow.com/questions/1235116/safari-and-gzip
• http://blog.bigsmoke.us/2012/01/16/safari-ignores-content-type-for-gz-suffix

I suggest that you check the information linked above, and if still relevant consider to use jgz instead of gz.

I don't think any of these apply here:

• safari v4 is outdated
• I'm not proposing to call/use the file.js.gz directly, this is done automagically by either Apache or Nginx.

Some explanation how all this works:

• User makes a request to our site
• Joomla creates the html and sends it back
• Browser parses the page, finds all the assets and starts making requests
• Apache receives the request
• Checks if the header that is send by the browser got the gzip deflate : eg Accept-Encoding: br, gzip, deflate
• If gzip is supported apache through the snippet provided above will switch off the automatic gzipping of the file and serve the already stored one.

The process power released by not having to gzip files in every request is enough to raise the maximum number of concurrent client. Not to mention that this is environmentally friendly programmingⓇ

BTW the provided default snippet by apache will always switch the extensions, I guess this needs an if statement to check if the file actually exists...

I'm not proposing to call/use the file.js.gz directly, this is done automagically by either Apache or Nginx.
I know.

Some explanation how all this works:
I know.

BTW the provided default snippet by apache will always switch the extensions, I guess this needs an if statement to check if the file actually exists...

Yes, there should be a RewriteCond %{REQUEST_FILENAME}.gz -f at the end of the rewrite conditions chain for each of the file types.

Oh, I just see there is already a RewriteCond "%{REQUEST_FILENAME}\.gz" -s. That should do already the job.

Here is my nginx conf:

# gzip
gzip_static  on;
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_types text/plain text/css text/xml application/json application/javascript application/xml+rss application/atom+xml image/svg+xml application/font-woff  application/font-woff2;

The only extra part needed to work is gzip_static on;
Ref: http://nginx.org/en/docs/http/ngx_http_gzip_static_module.html

very nice to see this pr,

i understand how this works,
i have used it myself in some cases

but i want to ask regarding the case of having apache as web server
why this PR does not include the suggested changes inside htaccess.txt too ?
i mean htaccess.txt is used in new installations so why not include the suggested modification ?
are we expecting issues with contents of

<IfModule mod_headers.c>
    # Serve gzip compressed CSS files if they exist 
    # and the client accepts gzip.
...
</IfModule>

why this PR does not include the suggested changes inside htaccess.txt too

This PR only provides the tool for automating the creation of the .gz files. The steps to roll this to production are not part of this PR. As I wrote above the documentation is vital here and obviously tweaking the htaccess.txt and the build script are also required steps.

@dgrammatiko you are a genious!

@wilsonge can we get a decision from the production team on this one?

PS. The drone is failing, probably because the linux is 32bit and the zopfli script exists only for 64bit systems.

By the way, for anyone care to dig into the used technology here that is zopfli. Zopfli is compression scripts from Google, basically an improved gzip: https://github.com/google/zopfli

Redid this using WASM so no further changes required.
Attention this is now based on the new code for the build tools...

is there a reason why we don't create brotli compressed files? gzip is done by the moste webservers/loadbalancers/caches on the fly but brotli support is still very limited.

@HLeithner we could do that as well. The idea here is that these are repeated tasks from the web server which require processor power, so by providing them ready for delivery it's only a case of reading the file and streaming it...

FWIW I like the idea that Joomla will also provide prepared Brotli files

@HLeithner it seems zopfli is able to achieve the same level of compression as brotli:

@dgrammatiko you've accidentally committed the templates compiled css (and minified css) files here

@wilsonge can you try to build (locally) a 4.0-dev release so you can verify that this is actually working?

Processing: /Users/george/Sites/joomla-cms/media/vendor/webcomponentsjs/js/webcomponents-sd.min.js

After this file it hung. I had to command + c to close the task

@wilsonge it didn't hang it just takes very long to make all those .gz files. Try adding a console.log to see the files processing

PS the compression from zopfli is slow but the ratio is the same as brotli:

And for comparison here are the minified, normal gzip from a server, and the zopfli sizes:

56.658 bytes, 21.462 bytes, 17.881 bytes

Seems good to me. Thanks!