W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2013

Re: [whatwg] Script preloading

From: Bruno Racineux <bruno@hexanet.net>
Date: Fri, 12 Jul 2013 02:18:54 -0700
To: Jake Archibald <jaffathecake@gmail.com>, Kyle Simpson <getify@gmail.com>
Message-ID: <CE05023C.6B8B6%bruno@hexanet.net>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>


On 7/11/13 6:00 AM, "Jake Archibald" <jaffathecake@gmail.com> wrote:

>>
>>
>>
>><link rel="subresource">Š almost 50% of scripts Š sent without proper
>>caching headers. If the browser is doing what it should do, it won't
>>cache those
>
>This is not how link[rel=subresource] should work, the first request
>for the subresource should pick up from where the link left off. If it
>doesn't do that, let's fix it, then we get the feature working
>properly for more than just scripts.
>>6. Use-case: I want to preload a script which is hosted somewhere that I
>>don't control caching headers, and to my dismay, I discover that they
>>are serving the script with incorrect/busted/missing caching headers. If
>>I use a cache-preload technique, it will fail to work as I had hoped. I
>>will pay the double-download penalty because the browser didn't actually
>>cache it the first time, and my user will pay the extra UX penalty of
>>having to wait longer for the second load, when my whole goal was to
>>remove that UX visible delay.
>
>Use-case: (as above) I should be able to preload scripts served by a
>third party with no cache headers
>
>link[rel=subresource] has you covered and should be fixed if it isn't
>working.

Kyle, on the caching I don't think its legit to cache a file that is not
sent to be cached, as bad or involuntary as it might be from the provider.



Jake, now I that I am more familiarized with link[rel=subresource] it
seems to indeed solve some the "preloading without executing" side of
things. And good for performance especially if they can be provided in the
HEADER.

Is there a benefit from having a 'subresource' in the HEADER with the same
blocking script in the <head>?

I am thinking jQuery and the main css for example. It seems like css and
jQuery could be partially or even already available by the time </head> is
received. Assuming the HEADER is received and processed before the <head>
start downloading (I am mot sure if this is the case).


It'd be useful that a broader scope of link[rel=subresource] be specified,
or pre-formalized. There is little documentation other than the chromium
page right now, and no reference on:
http://wiki.whatwg.org/wiki/RelExtensions, where it has a proposal status.

A couple question I would have right about it, based on its current
implementation are:

Can multiple subresource(s) be specified in the HEADER?


If specified in the HEADER can the Request send 'current' cookies?

Does the Response of a link[rel=subresource] from the HEADER set cookies
normally?

One issue, I am seeing right now in Opera/Blink is that the script seem to
download twice if requested with XHR. That shouldn't be.
 
Received on Friday, 12 July 2013 09:19:20 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:03 UTC