[webkit-dev] Making browsers faster: Resource Packages
mike at belshe.com
Wed Nov 18 14:48:06 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 meant to say "Overall I like 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.
> 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>wrote:
>>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev