Re: [whatwg] resource hints and separating download from processing

Hey,

Not sure if you've seen this thread:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-July/297257.html.
I had the same basic interest as you (decoupling resource fetching from
execution). I'd be curious to hear your thoughts about that thread.

I really like the concept of a declarative fetch -- being able to specify
arbitrary fetch parameters (eg, headers or a yet-to-be-defined interface to
define HTTP/2 priority) is very powerful. It would be nice if there was a
more declarative relationship between the declarative fetch and the
eventual use of the resource (assuming the resources are on the same page).
For example, in the thread I had suggested fetch.asScript() though it seems
like people preferred using an actual <script> tag to initiate the fetch
(with a parameter saying not to execute).

-b


On Thu, Aug 7, 2014 at 2:04 PM, Ilya Grigorik <igrigorik@gmail.com> wrote:

> I'm working on the "resource hints" spec we've been discussing on
> public-webperf...
>
> "This specification defines preconnect, preload, and prerender hints that
> the developer, or the server generating or delivering the resources, can
> use in an interoperable way to assist the user agent in the decision
> process of which origins it should connect to, which resources it should
> fetch to improve performance, and which resources may be required by the
> next navigation."
>
> Latest draft: https://igrigorik.github.io/resource-hints/
>
> There are still plenty of details to iron out [1] and I'd appreciate any
> thoughts or feedback, but in particular I'm interested on suggestions
> around this discussion:
> https://github.com/igrigorik/resource-hints/issues/6
>
> Some background... Current browsers use resource context and content-type
> as a signal for download priority (e.g. scripts get a higher download
> priority than images). This is an imperfect signal, but it has served us
> well. As a result, in first iteration of the spec I went with "type"
> attribute (on <link>) as a way to communicate same information to the user
> agent. Later (see issue above), it was suggested that "context" is a better
> mechanism to express this and I agree.. except, it opens up a different set
> of questions and challenges:
>
> - There are cases where context is known: image, script, etc.
> - There are cases where context depends on multiple signals: iframe vs.
> iframe+seamless
> - There are cases where context is not known precisely ahead of time - e.g.
> prerender navigation can be triggered via multiple mechanisms (link click,
> window.location, etc).
>
> Long story short, the problem is that "context" is coupling download,
> policy enforcement, and processing. I'm wondering if we should separate
> these into:
>
> (1) a mechanism for downloading resources with right priority, etc.
> (2) a mechanism for processing downloaded resources where security and
> other policies are applied.
>
> Today, CSP blocks requests *before* they are issued. What I'm after here is
> applying CSP (and other relevant policies) on a resource that was already
> downloaded or is currently in flight -- I believe this is a requirement for
> ServiceWorker anyway? I'm sure there are other examples where this is
> relevant also.
>
> Separating downloading from processing would expose an important and very
> useful platform primitive: it'll allow us (regular developers) to compose
> different download behaviors, define when resources are processed and in
> which order, etc.
>
> More concretely, picture something like this (don't pay too much attention
> to syntax, just hand waving):
>
> (1) <link rel="preload" href="//thirdparty.com/script.js"
> execution="required" params="{...}">
> ...
> (2) <script src="//thirdparty.com/script.js"
> (3) <script> xhr = new XMLHttpRequest(); xhr.get("//
> thirdparty.com/script.js
> ");
> ---
> #1: initiates immediate download - effectively, it's a declarative fetch.
> You can also specify execution [2] and other request parameters [via 3, or
> something like it].
> #2: <script> request is matched [4] against the preload request, proper
> policies are applied and if that checks out, it's processed and executed.
> #3: XHR request is matched against preload, proper policies are applied..
> and it may get blocked due to same-origin restrictions, or some such.
>
> Assuming this makes sense, I'd drop "context" and instead rely on
> communicating download priority via [3], or something similar. As an aside,
> I think [3] is not going far enough, but that's a subject for a separate
> thread.
>
> Thoughts?
>
> ig
>
> [1] https://github.com/igrigorik/resource-hints/issues
> [2]
>
> https://igrigorik.github.io/resource-hints/#required-vs-speculative-execution
> [3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26533
> [4]
> https://github.com/igrigorik/resource-hints/issues/5#issuecomment-50809768
>

Received on Thursday, 7 August 2014 21:56:16 UTC