[whatwg] HTML resource packages

[Justin Lebar]

> So if resource packages don't share caches, you need to either give up
> on caching, [or] 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

I think this is a fair point.  But I'd suggest we consider the following:

* It might be confusing for resources from a resource package to show
up on a page which doesn't "opt-in" to resource packages in general or
to that specific resource package.

* There's no easy way to opt out of this behavior.  That is, if I
explicitly *don't* want to load content cached from a resource
package, I have to name that content differently.

* The avatars-on-a-forum use case is less convincing the more I think
about it.  Certainly you'd want each page which displays many avatars
to package up all the avatars into a single package.  So you wouldn't
benefit from the suggested caching changes on those pages.

You might benefit on a user profile page which just displays one
avatar.  You might try and be clever and leave the avatar out of the
profile page's resource package on the assumption that the UA already
has that avatar in its cache.  But then your page would load slower
for users who visited the profile page without first getting the
avatar from another resource package.

Maybe you'd benefit from the suggested changes if you'd half-deployed
resource packages on your site, so some pages had packages and others
didn't.  But I don't think that's a use case we should design for.

In general, I think we need something like SPDY to really address the
problem of duplicated downloads.  I don't think resource packages can
fix it with any caching policy.

-Justin

On Fri, Aug 6, 2010 at 2:17 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> 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.
>