- From: Justin Lebar <justin.lebar@gmail.com>
- Date: Tue, 3 Aug 2010 17:31:43 -0700
We at Mozilla are hoping to ship HTML resource packages in Firefox 4, and we wanted to get the WhatWG's feedback on the feature. For the impatient, the spec is here: http://people.mozilla.org/~jlebar/respkg/ and the bug (complete with builds you can try and some preliminary performance numbers) is here: https://bugzilla.mozilla.org/show_bug.cgi?id=529208 You can think of resource packages as image spriting 2.0. A page indicates in its <html> element that it uses one or more resource packages (which are just zip files). Then when that page requests a resource (be it an image, a css file, a script, or whatever), the browser first checks whether one of the packages contains the requested resource. If so, the browser uses the resource out of the package instead of making a separate HTTP request for the resource. There's of course more detail than that, of course. Hopefully it's (mostly) clear in the spec. I envision two classes of users of resource packages. I'll call the first "resource-constrained developers". These developers care about how fast their page is (who doesn't?), but can't spend weeks speeding up their page. For these developers, resource packages are an easy way to make their pages faster without going through the pain of spriting their images and packaging their js/css. The other class of users are the resource-unconstrained developers; think Google or Facebook. These developers have already put a huge amount of effort into making their pages fast, and a naive application of resource packages is unlikely to make them any faster. But these developers may be able to use resource packages cleverly to gain speedups. In particular, nobody (to my knowledge) currently sprites content images, such as the results of an image search. A determined set of developers should be able to construct resource packages for image search results on the fly and save some HTTP requests. So we can avoid rehashing here the common objections to resource packages, here's a brief overview of the arguments I've heard against the feature and my responses. * Argument: Packaging isn't the way forward. When you change one resource in a package you have to change the whole package and so the user has to re-download all the bits when most of what was in their cache would have been fine. This is of course correct, but we don't think it eliminates the utility of resource packages. The resource-constrained developer is probably happy with anything which speeds up page loads, even if it's not optimal when one part of the page changes. And the resource-unconstrained developer probably won't find resource packages too useful for non-dynamic content, so caching isn't an issue in that case. * Argument: We can already package things pretty well. Mozilla should instead be focusing on improving caching (or something else). I'd contend that we don't package particularly well in general. The Facebook homepage loads 100 separate resources on a cold cache, and they certainly care about speed. But anyway, this is just one project. We're also looking at caching. :) * Argument: Isn't this subsumed by HTTP pipelining? Mostly. But we can't turn on HTTP pipelining because transparent proxies break it. Resource packages have the further benefit that they allow page authors to explicitly set the order in which the UA will download the resources -- with pipelining, an important resource might get stuck behind a large, unimportant resource, while with resource packages, the UA always downloads resources in the order they appear in the zip file. Last, my understanding is that the HTTP pipeline isn't particularly deep, so perhaps resource packages fill the TCP pipe better on high-latency connections. I haven't looked into this, though. * Argument: What about SPDY? I think SPDY should subsume resource packages. But its deployment will require changes to both web clients and servers, so it will probably take a while after it's released before it's available on all web servers. And we have no idea when to expect SPDY to be ready for production. Resource packages, in contrast, are something we can have Right Now. Additionally, since resource packages are backwards-compatible -- a page which specifies resource packages should display just fine in a browser which doesn't support them -- we should be able to turn off resource packages in the future if we decide we don't want them anymore. We'd love to hear what you think of the specification and our implementation. -Justin
Received on Tuesday, 3 August 2010 17:31:43 UTC