[webkit-dev] Making browsers faster: Resource Packages

[Steve Tickle]

Hi All,

As a game developer with interests in mobile, I'd like to say overall, I
think the idea sucks.

Incorrectly implemented clients will end up downloading large resources
multiple times, and web masters are sure to start adding every resource to
pages that don't need them.

As I see it, the load time issue only occurs on first load anyway, as
properly implemented clients and servers should use cache directives to
avoid unnecessary connections.

If the first load case is a major concern (as in mobile), web masters should
optimise their pages so that resources are amalgamated wherever possible.

If you truly want better interactive performance from websites, add a
streaming connectionless facility atop UDP, rather than complicating matters
with an ad-hoc application level HTML hack.

Regards,

Steve

2009/11/18 Mike Belshe <mike at belshe.com>

>
>
> 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.
>>
>> Mike
>>
>>
>> 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:
>>>
>>> http://www.stevesouders.com/blog/2009/11/18/fewer-requests-through-resource-packages/
>>>
>>>
>>> --
>>> Alexander Limi · Firefox User Experience · http://limi.net
>>>
>>>
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>


-- 
Steve Tickle
sixteenk - Refined software development for mobile and web

t: +44 151 324 2816
m: +44 7950 052 976
w: sixteenk.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091118/d818486d/attachment.html>