The ‘script’ element currently only allows a single ‘src’ attribute to retrieve Javascript from a remote resource. In order to deliver compressed content, which is recommended by many websites and optimization tools, both the web browser and the server have to be configured in a roundabout way to show that they support compressed content delivery. The web browser has to present to the server an ‘Accept-Encoding’ HTTP header and the web server has to hand the request off to custom-compiled extensions to perform the compression and/or rewrite the request.
Data compression is an expensive, CPU-bound operation. So having the web server itself perform compression potentially multiple times for mostly static content seems rather counter-productive. If the content is pre-cached, a rewrite server module has to get involved. If the content is cached by the web server, that usually involves a memory/disk caching web server module (or even a completely different server like Varnish). In any case, multiple pieces of technology have to come together to support compressed content in the first place.
A better option, if it were available, would be to use a ‘srcset’ attribute on the ‘script’ element that declares a set of URLs and their ‘Content-Encoding’ equivalent for the same resource (gzip, deflate, etc). Then the compressed content could be pre-cached on disk on the server and statically delivered without requiring any custom server modules to be installed and configured. This would be analogous to img srcset but for data compression in the script element.
It might also be a good idea to consider something similar for the ‘link’ element at the same time for delivering pre-cached, compressed CSS. However, Javascript widgets are getting a lot heavier these days (250KB-500KB uncompressed, unminified JS is fast becoming the new “normal”), so the script tag is a much more critical path.
