Re: [resource-hints] first spec draft

On Wed, Jul 16, 2014 at 6:56 AM, <bizzbyster@gmail.com> wrote:

>
> But it doesn't matter -- there are many different scenarios where knowing
> the expected size of the resource hint helps the UA make smarter decisions
> and so load the page faster. Flow control could mitigate the impact of this
> yes but it's suboptimal as in many cases flow control is too late -- we
> have already filled the pipe for some period of time unnecessarily with
> data we don't need.
>

Would TCP_NOTSENT_LOWAT (which should help the sender avoid buffering
resources too early) address this issue?

Prefetching objects based on resource hints is speculative, meaning there
> is always the risk that the UA will fetch bytes unnecessarily. For that
> reason we need to provide the UA with information that allow it to make an
> intelligent decision about whether or not it's worth the risk. In the case
> of a bandwidth constrained link, cost will be directly proportional to size
> so the UA needs size to make this decision. The point I'm making is that
> while priority tells the UA the order in which resources should be fetched
> to optimally load the page for best user experience, and it will often be
> related to the probability that the object will be needed, it doesn't tell
> the UA anything about the cost of issuing what could be an unnecessary
> request.
>


Imagine for a second that we're talking about a website that has all
resources on a single origin and is using a single HTTP 2.0 connection. Is
there any reason the UA shouldn't send all requests that it knows about to
the server. The number of bytes required to send all requests it might need
should be relatively small. The server can make ordering decisions based on
a number of heuristics -- file size, file type etc.

You could imagine cases where the size of the resource might not be known
precisely at the time the request is generated. For example, a site with a
large CDN might not be able to quickly access the size of every image it
might serve. A site might use SDCH to better compress it's JS and CSS --
the size of a JS/CSS file would depend on what dictionaries the client had.


> Your comment triggers an idea -- it would be great if we could send a
> boolean flag to indicate that the object will be needed to render the
> portion of the page within the viewport. Thoughts?
>

Keeping with the scenario of a single HTTP 2.0 origin, if we shift the
responsibility of prioritization from the UA to the server, why limit the
information about priority to a predefined flag? What about allowing the
client to pass an opaque priority descriptor to the server?

-b