[whatwg] Prioritizing subresources (Was Script preloading)

Wed Sep 4 11:55:16 PDT 2013

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

> On Sep 3, 2013 8:00 PM, "Ryosuke Niwa" <rniwa at apple.com> wrote:
> >
> > On Sep 3, 2013, at 5:01 PM, William Chan (陈智昌) <willchan at 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">
> 
> Sorry Ryosuke, I had too much scotch and can't think through your other use case. This specific proposal is a no go from my perspective though because many pages have components from different authors. I trust a single author to use the appropriate relative priority for all the resources he/she controls. Your proposal seems to imply absolute priorities, which I think is a mistake. I don't want a third party ads widget to have high priority even if they request it.
> 
If we're doing this, then priority needs to be relative per origin or per document so that you can't sabotage other websites or be sabotaged by thirdparty ads as you suggested.
e.g. If all resources on a page has the priority "high", then it should behave as if all of them have the medium priority.
> I don't mind giving third parties the ability to "nice" the priority of their resource loads. This is why demoting priority based on defer/a sync/lazyload seems reasonable to me.
> 
Let me think about this more.

- R. Niwa