- 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>
- 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