- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Fri, 6 Aug 2010 17:17:49 -0400
On Tue, Aug 3, 2010 at 8:31 PM, Justin Lebar <justin.lebar at gmail.com> wrote: > 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/ I have some concerns about caching behavior here, which I've mentioned before. Consider a site that has a landing page that has lots of first-time viewers. To accelerate that page view, you might want to add a resource package containing all the assets on the page, to speed up views in the cold cache case. Some of those assets will be reused on other pages, and some will not. When the user navigates to another page, what's supposed to happen? If you hadn't used resource packages at all, they would have a hot cache, so they'd get all the shared assets on every subsequent page view for free. But now they don't -- instead of the first view being slow, it's the second view, when they leave the landing page. This isn't a big improvement. So if resource packages don't share caches, you need to either give up on caching, put a given file only in one resource package on your whole site. The latter is not practical if pages use small, fairly random subsets of your assets and it's not feasible to package them all on every page view. Think avatars on a web forum: you might have 20 different avatars displayed per page, from a pool of tens of thousands or more. Do you have to decide between not using resource packages and not getting any caching? You've said before that your goal in this requirement is predictability -- if there's an inconsistency between different resource packages or between a resource package and the real file, you don't want users to get different results depending on what order they visit the pages in. This is fair enough, but I'm worried that the caching problems this approach causes will make it more of a hindrance than a benefit for a wide class of use-cases. There's some possible inconsistency anyway whenever caching is permitted at all, because if the page provides incorrect caching headers, the UA might have an out-of-date copy. Also, different browsers will be inconsistent too, until all UAs in common use have implemented resource packages -- some will use the packaged file and some the real file. Is the extra inconsistency from letting the caches mix really too much to ask for the cacheability benefits? I don't think so.
Received on Friday, 6 August 2010 14:17:49 UTC