W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] HTML resource packages

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Fri, 6 Aug 2010 17:17:49 -0400
Message-ID: <AANLkTikY5oWZD11+F-Nbm32j72nigVQuyDykh6d8oyfp@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:59 UTC