A Standard for Greatly Reducing HTTP Connections

I propose that browsers should be able to take a zipfile with a hash (#hash) on the end of the filename, retrieve the corosponding file from the zipfile, and use the file as if it were the type indicated by the filename hash in the context of the element.

The zipfile should be able to include subdirectories so that the zipfiles can be organized.

I might have a zipfile named "ui.zip" that included a handfull of images that would be used for buttons, header backgrounds, and other elements in a webpage UI.

I might use an <img> element, or a CSS background-image to utilize the resource.




I might use a <script> or <link> element to utilize the resource.




This could greatly reduce the number of HTTP connections a browser would make to the server.

Because of the compression, it could be a more effective alternative for CSS sprite image sheets.

Because of the way browsers should retrieve resources from the zipfile as if they were the file themselves, existing sites considering CSS sprites to reduce the number of HTTP connections being made to their servers could instead implement this alternative without needing to redesign the sites style to use complicated background-position CSS rules. A savy administrator could put to work creative use of sed to replace the image URLs in the existing files.

It would utilize an already widespread format that nearly everyone on the Internet is able to use right now.

I invite everyone to point out any Advantages, Drawbacks, or Additions they can think of about such a standard.
My goal is to have this evolve into an open standard that browser makers would seriously consider implementing.

I like the idea, but what are your feelings on a standardized file type? The *nix crowd may reject the notion of using the zip format, even though Win and Mac have included it for some time.

There's also the possibility of creating a new file format specific to optimizing this particular use (save the issues of variable configurations during file creation?)

.nra - Network Resource Archive

But then, why limit it to one file and/or compression type? How about a tag that lets you specify the type and file:



And then reference it by ID everywhere else:




This would also allow a webmaster to place the individual images on the server as well as the archive, so that if the browser doesn't support the archive functionality, or if the image itself is missing from the archive, the browser can fall back to looking for just the filename itself.

Sounds good, where would you place the best practice - one archive per content type? Would you want the same archive to hold your js/css/imgs/etc?

I think it depends how you plan to optimize your content. If you have a relatively small number of resources, then placing them all in the same archive would cut down on the number of HTTP connections pretty dramatically. However, if there are resources that are only used on certain pages, then it wouldn't make sense to include them in the archive for every page, even if the archive is cached, since it will lengthen the download time for other, more important resources such as display elements.

Well, many modern browsers already support gzip compression of pages, what if the standard allowed this to work with "*.tar.gz" or even "*.bz2" files as well ?

I don't really like the idea of using a totally new file format for this because it's essentually just defining a method for browsers to access individual files within a package within the URL without a querystring.

I believe Mozilla already has zipfile support for Firefox extensions and for gzip compression, so for them to implement this would only require changes to the way Firefox works with the URL of an image/etc. Rather than requiring them to implement a whole new format.

Internet Explorer, Opera, Flock, Safa... errr, what kind of compressed file support does Safari/Mac have ?

Come to think of it, a new HTML tag is probably overkill. Why not just use the <link> tag with a different rel attribute, like this:

Files common to all pages might go into one zipfile, and in-page elements might go into other zipfiles.

A browser may use one connection to keep retrieving text content, while it used another connection to retrieve the zipfile referenced by a stylesheet, with the stylesheet in turn referencing the zipfile that contained it instead of being allowed to make a dozen new connections back to the server to fetch 12 images.

This reduced load on the server will allow it to serve these zipfiles at faster rates of speed.

That's a good idea.
It would essentually preload a package full of images and allow elements to reference them as usual right ?

A browser would be required to wait for archives to load before it was able to tell whether it needs to make a request to the server for an element.

Because <link> elements are <head> content, you would be forced to load archives before any content, or after all content has loaded if something such as a "defer" attribute were available. You couldn't for instance, have a <script> archive before the </body>

Exactly. The benefit here is that the elements would first attempt to load the resource from the archive specified, but if that's unsuccessful for any reason (no browser support, file not in archive, etc), the element simply falls back to loading the resource as if no NRA were associated it, essentially ignoring the nra="xxx" attribute.


I suppose you have a point, although I like the idea of being able to defer the loading of the archive until the first time one of the resources is requested from it.

That introduces a big problem with my proposal right there.
No way to work around missing support comes to mind. A lack of support would leave a page completely broken.

How about having the rel tag point not to a file, but to a folder where all the full files are located, plus the archive for them reflecting the same directory structure? If the archive is supported, do it, if a needed file is corrupted, or no support is found at all, use the full files from the same directory.

Unless, (I always hit submit too soon...) it was switched around so that the filename were first and the archive were specified in the hash!

Browsers with no support would just ignore the hash I believe, but browsers with support would know to load and check the archive for the file specified before the hash.

This could be implemented as "value added" functionality to the <link> element proposal. It could serve as a hint to let a browser know it's going to load the resource from the archive, or as a way to specify special-case archives inline.

Actually, quite the opposite. Imagine that you declare your NRA with a <link> tag, like above:

Browsers that don't support this functionality will simply ignore this link tag. So far, so good.

Now suppose we declare an image like this:


If the browser supports the NRA functionality, it will look in the archive images.nra for the file img/logo.png. If found, that file will be used. If the file is not found, or if the browser doesn't support NRA's and has ignored the archive declaration, then the nra="images" attribute is also ignored, and the browser loads the image from img/logo.jpg, a regular image located in the current directory.

The only thing I don't like about using the hash notation is that it seems a bit hackish. Defining an actual structure for this added functionality allows for expansion/modification later on.