Have you been frustrated lately by speed of web applications? Typically they have a lot of art, and structured into a nice set of JavaScript and CSS files. They look beautiful, aren’t they? But do you have the patience to wait them load? And proceed from step to step?

Of course, it is possible to prepare a web application to high-demand life: merge all stylesheets, and JavaScript files, and compress the result, structure your GUI in such a way that it is possible to combine all small images in one, and so on. This is very tedious low-level work. There are some tools, which can take care of the problem. For example, Dojo compressor merges JavaScript files and transforms the code to minimize its size. There are some tools to “compress” CSS. But the task of general optimization of your web app is up to you. Otherwise you will have a lot of frustrated users.

If you think about the process outlined above, you will see that it is all about packaging all required files. You package them to reduce total size, and number of downloads.

Today Max of Software Shipwreck blogged about his frustration and proposed a solution:

Say, we have a URL prefix (or a directory) that contains a bunch of HTML forms, images, stylesheets and Javascript files. Also, let’s say that designers of the app contained therein were smart and tried to avoid unnecessary requests to dynamically generated pages (either by using AJAX on the client, or by using some intelligent multi-level caching scheme like the one in Django).

Now, for the app to work the files need to migrate to the client. Normally they would do it one-by-one on the first (and, as is typical, the only) access to the site. However if there was a way for the browser to request the entire tree at once in compressed form and unpack it to local cache, both the overall bandwidth requirement and the total lag time would go way, way down.

Read all details in his post. I think his idea is simple, backward compatible, totally doable, and solves the problem.

At the end Max wonders, if someone is working on it already. Let’s see. There is no standard on packaging web applications. We have W3C, which is supposed to work on it. It does: Web APIs WG was created to develop standard APIs for client-side Web Application development". But I don’t see them defining how to distribute web apps. WHAT-WG is working on Web Applications 1.0 standard, and again I don’t see any packaging mentioned in it. Why? Blind faith in the broadband for masses? It will not solve the network lag problem, which exists because of speed of light limitations.

Over past 12 years we saw a lot of packaging technologies: Microsoft’s ActiveX, Sun’s Java applets, Netscape plug-ins, Mozilla extensions, and so on. They use similar idea of bundling everything together but they are not what we need. We need install-less packaging, which is totally agnostic to underlying technology. Max’s idea of “direct transfer to cache” covers everything.

What do we need to implement it? Max proposes adding a verb to HTTP. I think that the less radical solution is possible too:

• HTML page carries a meta data indicating that it has a package associated with it. Variant: URL link carries an additional parameter, which tells that the resource is a part of package.
• If browser understands this meta information, it downloads the package and unpacks it to browser’s cache. If browser doesn’t understand it, this step is skipped.
• Everything else goes like it did before.

Server side is unchanged but web masters should provide downloadable packages in addition to individual files. In many cases it can be easily automated.

As you can see it is very simple to implement. The only non-trivial step is unpacking the package. Now we have to find a browser willing to implement it. Mozilla Firefox? Opera? Konqueror? Apple Safari? Microsoft Internet Explorer? Do you hear me? Give them a shout, if you can.