Hi, @Tom_Rupsis, here is what I found.
The response in the screenshot was compressed. This is shown with this header:
x-content-encoding-over-network: br
So, the javascript file (not the gzipped version) was served using brotli. I showing the response size (including headers) was 1741649 bytes. This is smaller (even with headers) than the the gzipped bundle which is 1811427 bytes.
Also note, you do not need to pre-compress your assets to have them served compress at Netlify. In fact, the only way to get the gzipped bundle in the deployment is to specifically request it. This site won’t ever use the gzipped bundles in the deploy (without specifying the .gz).
Here is a curl example piped to wc -c to get the byte count (please note this counting method does not include headers):
$ curl -s https://whitewater.dev/index_bundle.js.gz | wc -c
1811427
This is smaller than our gzipped version (using an accept-encoding header without brotli support):
$ curl -s -H 'accept-encoding: gzip, deflate' https://whitewater.dev/index_bundle.js | wc -c
1819759
So, our gzipped is used and is a less optimized compression of the file. However, both Chrome and Firefox will use brotli which is smaller still. (Edge and Safari probably will too but I didn’t test them.)
Again, though, the brotli version (this time without counting headers) is still the smallest:
$ curl -s -H 'accept-encoding: gzip, deflate, br' https://whitewater.dev/index_bundle.js | wc -c
1741210
To clarify, our service won’t use the local gzipped bundles unless the URL requested includes that exact filename. By this I mean the only way to get your gzipped version is to request index_bundle.js.gz not index_bundle.js and the site doesn’t do this.
We will send gzipped or brotli compressed versions of the files automatically and there is no need to pre-compress during the build (because those files won’t get used in most scenarios).
If there are other questions about this, please let us know.