[whatwg] Script preloading

Fri Jul 12 02:18:54 PDT 2013

On 7/11/13 6:00 AM, "Jake Archibald" <jaffathecake at 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.