[webkit-dev] Making browsers faster: Resource Packages
dpranke at chromium.org
Wed Nov 18 15:54:56 PST 2009
On Wed, Nov 18, 2009 at 2:47 PM, Mike Belshe <mike at belshe.com> wrote:
> Overall, I think the general idea.
> I'm concerned about the head-of-line blocking that it introduces. If an
> administrator poorly constructs the bundle, he could significantly hurt
> perf. Instead of using gzip, you could use a framer which chunked items
> before gzipping. This might be more trouble than it is worth.
> Inside the browser, the caching is going to be kind of annoying. Example:
> Say foo.zip contains foo.gif and baz.gif, and foo.zip expires in one week.
> When the browser downloads the manifest, it needs to "unfold it" and store
> foo.gif and baz.gif in the cache. Then, a week later, if the browser tries
> to use foo.gif, it will be expired; does the browser fetch foo.zip? or just
> foo.gif? Obviously, either will "work". But now you've got an inconsistent
> cache. If you hit another page which references foo.zip next, you'll
> download the whole zip file when all you needed was bar.gif. This is
> probably a minor problem - I can't see this being very significant in
> practice. Did you consider having the resources for a bundle be addressed
> such as: http://www.foo.com/bundle.zip/foo.gif ? This would eliminate the
> problem of two names for the same resource. Maybe this was your intent -
> the spec was unclear about the identity (URL) of the bundled resources.
> I think it is a good enough idea to warrant an implementation. Once we have
> data about performance, it will be clear whether this should be made
> official or not.
Another caching-related issue involves versioning of the archives. If
version 2 of a zip contains only a few files modified since version 1,
and I have version 1 cached, is there some way to take advantage of
that? Can SDCH be helpful here?
Also, you explicitly note that all the files in the archive should
have the same expiry, but I wonder if there are ways (and if its
useful) to drop that restriction as well.
I think there's a lot of space for research and evaluation here, and I
agree with Mike that this is a good enough idea to warrant an
implementation and experimentation.
> On Wed, Nov 18, 2009 at 11:56 AM, Alexander Limi <limi at mozilla.com> wrote:
>> On Tue, Nov 17, 2009 at 5:56 PM, Alexander Limi <limi at mozilla.com> wrote:
>>> On Tue, Nov 17, 2009 at 5:53 PM, James Robinson <jamesr at google.com>
>>>> Yes, actual numbers would be nice to have.
>>> Steve Souders just emailed me some preliminary numbers from a bunch of
>>> major web sites, so that should be on his blog shortly.
>> Numbers are up:
>> Alexander Limi · Firefox User Experience · http://limi.net
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev