Re: [whatwg] Prioritizing subresources (Was Script preloading)

On Sep 3, 2013 8:00 PM, "Ryosuke Niwa" <rniwa@apple.com> wrote:
>
> 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">

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.

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.

PS: relative values work fine within defined contexts. I think iframes and
web components may be appropriate contextual boundaries.

>
>
> 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 06:07:21 UTC