[whatwg] resource hints and separating download from processing

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:05:23 UTC