Why minify when the transport will gzip?

Question

Back in the day (yes I really am this old) you could reference scripts out of a renamed zip file like this

<script archive="path/to.jar" src="some.js"></script>

This was supported on IE4, NS4 and Opera5 with identical mark-up and semantics, but has been consigned to the digital scrapyard. Why?

---

OK for those of you interested in the answer but not interested enough to trawl through an old message thread (see comments below) the long and the short of it is that you get the compression from the transport layer merely by specifying Content-Encoding: gzip so it is inappropriate to support mark-up in the presentation layer and therefore it was removed. This also improves granularity because script files are individually versioned in the cache.

Given the transport layer use of gzip, what is the point of minification? The gzip dictionary tokenising pass will achieve this over the wire without producing a horrible debugger experience.

I agree that concatenation will improve the compression yield. I suppose some server/browser combinations might fail to use gzip, in which case minification would help.

Answer 1

The archive Attribute

For anybody interested in what this attribute was, DevX made mention of it in their Daily Tip on March 23, 1999. The original text is being duplicated here for preservation:

ARCHIVE is a new attribute of the <SCRIPT> tag in Internet Explorer 4 and Netscape Navigator 4 that can speed up download times for sites with large JavaScript files. If you have several JavaScript files and digital signatures to load, it's more efficient to compress them into a single JAR (Java Archive) file. JAR archives are zipped files with self-descriptive information added. Within the JAR file, you still need to specify an external JavaScript file for each instance within an HTML page.

<SCRIPT ARCHIVE="myArchive.jar" SRC="myScript.js"></SCRIPT>

Support in Modern Browsers

This is not in any standards track, nor do modern browsers appear to even support this attribute in a deprecated manner. A simple feature test indicates this:

"archive" in document.createElement( "script" );

The results are pretty consistent:

• Chrome: False
• IExplorer: False
• Firefox: False
• Opera: False

Relevance Today

We don't really need a feature like this today in modern browsers. We now have better encoding options, and a plethora of build tools that concat and minify multiple dependencies. We also have utilities like require.js and r.js that package up multiple files to reduce HTTP requests.

In short, the web blew right past the need for transferring zipped dependencies.

This same question was asked in 2003 on the W3C's www-html mailing list. A few of the arguments made for why an attribute like [archive] is no longer needed are listed below:

• Browsers are now capable of long-term caching to reduce future HTTP requests
• Browsers are now capable of far better content compression
• Browsers are now capable of persistent connections, reducing HTTP requests

Archived Publications

MSDN has a resourced titled Script-based Security that references this still today.

MDN also has an archived resource on the topic titled Signed Scripts in Mozilla.

Response to Author

Given the transport layer use of gzip, what is the point of minification? The gzip dictionary tokenising pass will achieve this over the wire without producing a horrible debugger experience.

It may be the case (not likely, but maybe) that the browser doesn't support gzip. In these instances, a concatenated/minified source would be far better. Modern build processes including minification steps also offer more granular control that gzip may not compete well against. For instance, minification can remove lengthy source comments.

As for the debugging experience, you can always leverage modern browser support for source maps which should eliminate any need to actually debug minified code.