[webkit-dev] Making browsers faster: Resource Packages

[Peter Kasting]

On Tue, Nov 17, 2009 at 2:19 PM, Alexander Limi <limi at mozilla.com> wrote:

> We'd all like for the web to be faster, and therefore I'd love your
> feedback on my proposal
>

I have read the whole document, but I read it quickly, so please do point
out places where I've overlooked an obvious response.

Reduced parallelism is a big concern of mine.  Lots of sites make heavy use
of resource sharding across many hostnames to take advantage of multiple
connections, which this defeats.  You say in this thread that "you still do
parallel downloads", but it seems to me that you either download this zip in
parallel with anything not in the zip (meaning you run out of parallelism
faster the more the author makes use of this technique), or else you
potentially download in parallel multiple copies of the same resource (one
in the zip, one outside), neither of which is good.

I am concerned about the instruction to prefer the packaged resources to any
separate resources.  This seems to increase the maintenance burden since you
can never incrementally override the contents of a package, but always have
to repackage.

One of your stated goals is to avoid downloading resources you already have,
but even with manifests, I see no way to do this, since the client can't
actually tell the server "only send items x, y, and z".

If an author has resources only used on some pages, then he can either make
multiple packages (more maintenance burden and exacerbates problem above),
or include everything in one package (may result in downloading excessive
resources for pages where clients don't need them).

You note that SPDY has to be implemented by both UAs and web servers, but
conversely this proposal needs to be implemented by UAs and _authors_.  I
would rather burden the guys writing Apache than the guys making webpages,
and I think if a technique is extremely useful, it's easier to get support
into Apache than into, say, 50% of the webpages out there.

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091117/9c9e7528/attachment.html>