[whatwg] Prioritizing subresources (Was Script preloading)

On Sep 3, 2013, at 5:01 PM, William Chan (陈智昌) <willchan@chromium.org> wrote:

> Hello folks. Sorry for the late response to several comments in this
> mega-thread, I've mostly been traveling/vacationing for the past 2 months.
> A teammate asked me to look at this in case I had comments. I don't know
> web dev issues very well, so I'm going to restrain myself from offering
> many opinions about the new proposals other than wow, all this dependency
> stuff looks complicated, but maybe it's worth it? I'll keep to some
> observations from a networking performance perspective, in case it's
> relevant to the discussion:
> 
> * Any advantages the preloader currently gives is probably only going to be
> magnified with HTTP/2. Browsers today will in key situations hold back
> lower priority resource loads, even after the resource has been discovered
> by the parser/preloader, in order to reduce network contention and
> prioritize resources. But with HTTP/2, the browser almost never has to do
> this since it can express the request priority in the HTTP/2 protocol
> itself, and let the server order responses appropriately.
> * <link rel=subresource> is great for resource discovery. Given the above
> observation, note that it has some deficiencies. Most obviously, it does
> not indicate the resource type. Browsers today can heuristically assign a
> priority based on the resource type (script/image/stylesheet/etc).
> Arguably, browsers could just use the filename extension as a hint to the
> resource type, and that'd get us most of the way there. In any case,
> Chromium, when it encounters <link rel=subresource> is going to assign the
> resource load the lowest priority level, and only when the parser
> encounters the actual resource via a <script> tag or something, will
> another resource load be issued with the "appropriate" priority. Almost all
> modern browsers will hold back low priority resource loads before first
> paint in order to get critical scripts and stylesheets in <head> ASAP
> without contention. Anything marked with <link rel=subresource> will be
> considered low priority and in all likelihood not requested early. Note
> that HTTP/2 currently does not support re-prioritization (and that feature
> is being debated), so that means that when the resource load for <link
> rel=subresource> gets issued over an HTTP/2 connection, it will have the
> lowest priority, which is probably undesirable. FWIW, I think <link
> rel=subresource> was a good initial start, but suffers from key weaknesses
> and should be thrown out and replaced.
> * Given current browser heuristics for resource prioritization based on
> resource type, all <script> resources will have the same priority. Within
> HTTP/1.X, that means you'll get some amount of parallelization based on the
> connection per host limit and what origins the script resources are hosted,
> and then get FIFO. New additions like lazyload attributes (and perhaps
> leveraging the defer attribute) may affect this. With HTTP/2, there is a
> very high (effectively infinite) parallelization limit. With
> prioritization, there's no contention across priority levels. But since
> script resources today generally all have the same priority, they will all
> contend and most naive servers are going to round robin the response bytes,
> which is the worst thing you could do with script resources, since current
> JS VMs do not incrementally process script resources, but process them as a
> whole. So round-robining all the response bytes will just push out start
> time of JS processing for all scripts, which is rather terrible.
> * Obviously, given what I've said above, some level of hinting of
> prioritization/dependency amongst scripts/resources within the web platform
> would be useful to the networking layer since the networking layer can much
> more effectively prioritize resources and thus mitigate network contention.
> If finer grained priority/dependency information isn't provided in the web
> platform, my browser's networking stack is likely going to have to, even
> with HTTP/2, do HTTP/1.X style contention mitigation by restricting
> parallelization within a priority level. Which is a shame since web
> developers probably think that with HTTP/2, they can have as many fine
> grained resources as they want.

Why don't we simply add "priority" content attribute to link element then?

<link rel=subresource href="high-priority-resource.js" priority="high">
<link rel=subresource href="low-priority-resource.js" priority="low">


But can we modify these priorities dynamically?   I have one specific use case that requires this.

Use case D:
A web page wants to load and execute a script widget.js if the script is already cached in the browser.  However, it wants to load other essential assets such as images first if it's not already in the cache except as long as the user had not started interacting with the parts of the page that require widget.js.

i.e. it (loads and) executes the script immediately when and only when the script had already been cached or the user had started interacting with the parts of the page that requires the script.  Otherwise, the script is loaded with a low priority.

- R. Niwa

Received on Wednesday, 4 September 2013 03:01:21 UTC