[whatwg] Script preloading
bruno at hexanet.net
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
>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
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
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
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
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.
More information about the whatwg