- From: Ilya Grigorik <igrigorik@gmail.com>
- Date: Thu, 7 Aug 2014 14:04:17 -0700
- To: WHATWG <whatwg@whatwg.org>
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