[whatwg] Script preloading

[Bruno Racineux]

On 7/10/13 4:20 AM, "Jake Archibald" <jaffathecake at gmail.com> wrote:

>On 10 July 2013 11:31, Bruno Racineux <bruno at hexanet.net> wrote:
>
>>Anyway, as per your previous email I think we mostly agree that solution
>>#1 is not very practical (or infeasible per your word)
>
>
>Given the suggestions I made to #1 in
>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-July/039968.html,
>do you still think it's impractical (and why)?
I think the very idea of having the concept of 'dependency' attributes and
relying or asking to the browser to handle it through markup is misguided.

This is somehow throwing the entire (or a portion of) dependency
information of your platform, asking the browser to deal with it.
I can already imagine bloated pages with an entire set of script markup,
bigger than that of the page itself. That's not very good for performance.

I think Kyle has given more than enough substantiated arguments in:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-July/039981.html
not to have me repeat them.




>
>>I think that preloading without executing is really what we should are
>>
>after.
>>
>
>*hits usecase button* Why would you want to do that? Are those cases
>already (better) solved by link[rel=subresource] and dynamic script
>insertion?
Again I'll differ to Kyle's extensive list for the use case.
Modular approach, widgets, etc.

As for link [rel=subresource] I am slightly unclear at to its full purpose
really.
Unless I am mistaken, (and if so correct me) it's a priority-prefetch. No
a preload.

While slightly useful. It doesn't really address, the "pre-load that
script and have it waiting, ready at a moment's notice to say "it's ok to
execute, do it now! now! now!". :)


An alternative perhaps ignorant suggestion:


Wouldn't a link[rel=preload] sending cookies would be simpler tool for
basic script-preloading? In that I could dynamically insert a list of
subresources to have them ready. Leaving the loading part to markup. And
the request part to javascript.

In order to address caching caveats (or possible lack of caching headers)
that Kyle mentioned. rel=preload would guarantee a one time cache as well
a pre-parsing the resource according, to its link 'type' if provided (i.e.
css, js, etc).

Now wether a HXR request from there has a cross-browser hurdle when the
script is already in the cache is something I am not familiar with...

And I am unfortunately very confused on the link[prerender] spec for
scripts.