Content-Type application/javascript is being served uncompressed

[brontolosone]

Problem description

Nginx in both production and development setups is not configured to gzip-compress the application/javascript content-type. The config marks the application/x-javascript content-type as a candidate for compression, but that's a deprecated mimetype and is not what the nginx file-to-mimetype mapping, or the OS's file-to-mimetype mapping, will derive for a *.js filename.

Absent any comment as to why application/javascript is not included in the compressible type, and considering the advantages of compressing it, I'm assuming that the current behaviour is not the intended behaviour.

Steps to reproduce the problem

Note: when staging gets upgraded, there may be a new chunk-vendors.*.js file, so the below URL may need to be adjusted if you're trying this in the future.

curl --no-progress-meter -v --compressed https://staging.getodk.cloud/js/chunk-vendors.37e8929b.js | gzip -1 | wc -c 
<snip/>
> GET /js/chunk-vendors.37e8929b.js HTTP/1.1
> Host: staging.getodk.cloud
> Accept: */*
> Accept-Encoding: deflate, gzip, br, zstd
> 
* Request completely sent off
<snip/>
< HTTP/1.1 200 OK
<snip/>
< Content-Type: application/javascript
< Content-Length: 306319
125257

Shown is that a) no transport compression is being applied — no Content-Encoding header is present in the response; and b) the response is large enough to meet the gzip_min_length criterium, and c) the response is in fact quite compressible (ratio 2.5×), thus it would be worthwhile to enable it.

I see the same lack of transport compression in my browser's devtools by the way. CSS gets compressed, JS doesn't.