https://docs.google.com/document/d/1jSpWc6jkrUoYtGWcxev9Blkkv9RhoO1XtqinBvXqhgY/edit
Would suffice for priority.
Peter
On Aug 29, 2014, at 9:59 AM, bizzbys...@gmail.com wrote:
> We need to bite the bullet and add a priority attribute and an expected-size
> attribute.
>
> Priority:
> The web server will often have information that allows it to know better than
> the UA about the priority of objects. Basing this on type is not super useful
> when we have only a few types and we have lots of objects. The UA can ignore
> it but a priority field allows the web server to give the UA as much
> information as it has about how to download the objects to optimize load
> time. Why not just make it like probability and allow the web server to
> specify a value between 0.0 and 1.0, which 1.0 being a top priority object?
>
> Expected-size:
> I’ve argued this previously
> (https://github.com/igrigorik/resource-hints/issues/12) and Ilya agrees its a
> nice to have. Along with the probability attribute that is in Ilya’s latest
> draft, this provides a simple way to threshold which objects to prefetch at
> the UA.
>
> Sorry to re-raise expected-size but I think it’s relevant again in the
> context of priority. A small device or a UA on a bandwidth challenged link
> could use a simple scheme such as only preload resources above priority X
> with a smaller than a certain probability*expected-size when expected-size is
> available. Regardless the details of the logic, the UA needs all three fields
> (probability, priority, and expected-size) to make a good decision. We know
> this from 15 years experience doing prefetching in the network for satellite.
>
> Thanks,
>
> Peter
>
>
> On Aug 28, 2014, at 5:31 PM, Yoav Weiss wrote:
>
>> On Sat, Aug 23, 2014 at 2:44 AM, Ian Hickson wrote:
>> [snip]
>>
>>> On Wed, 4 Sep 2013, William Chan (陈智昌) wrote:
* Given current browser heuristics for resource prioritization based on
resource type, all 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.
>>>
>>> I'm not sure what to do about this exactly.
>>>
>>
>> Wouldn't that be something that is best handled as part of HTTP? e.g.
>> sending a flag with the request indicating whether the resource can be
>> progressively decoded or not?
>>
>>
>>>
>>>
* 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.
>>>
>>> It's hard to come up with a super fine-grained model that works well with
>>> multiple competing scripts, but we can do better than what we have now,
>>> certainly. It seems we can at least split things into the following
>>> categories, in order of highest priority to lowest:
>>>
>>> 1. resources that are needed and are causing something to block
>>> e.g.