Martin, I understood what you meant, but sadly, doing that least to confusion. Follow your link, it displays fine, and then save the file. At least in Firefox, the default name to save as is "nGzip — A File Compressor.html". This looks appropriate, but the saved file is actually the compressed .gz form, so attempting to display it later, from the default name, displays the compressed gibberish, because the name does not reflect the encoding. Perhaps this should be considered a Firefox bug? Chrome saves the uncompressed version with the same default name. I can't actually figure out how to save the file from Edge, so don't know what it might do.

I'm surprised that Firefox, since it saves the compressed version, didn't offer the name "index.en.html.gz", and that Chrome, for the uncompressed version, didn't offer "index.en.html". Deriving the name from the title feels weird, but maybe only because I create web pages, and know what the real file names are. But this paragraph, other than the lack of ".gz" for Firefox naming, is veery off-topic.

The point I'm trying to make, though, is that the URIs shouldn't contain file extensions that include the compression, because that is confusing. The compression should be an internally negotiated detail between the browser and the web server, and the URI should reflect the content to be displayed, not the form in which it was encoded for transfer (or storage).  When .gz or .br is included in the URI, I would expect the browser to offer to save it to disk as a binary, compressed file, just like .zip. The variant behavior of Firefox and Chrome makes me wonder if there is even a standard that applies in this area... if there is, and if either one of them is following it, it is certainly not what I would expect.