Re: [resource-hints] first spec draft

On Tue, Jul 15, 2014 at 9:55 AM, <bizzbyster@gmail.com> wrote:

> "
>>
>>
>>    - In order to make optimal use of a connection pool, it's valuable to
>>    know the size of a resource ahead of time. Is it possible to include an
>>    expected-size attribute?
>>
>> *If* we were to consider introducing this, I don't think its limited to
> hints. As such, I think this is a separate discussion. "
>
> I think expected size is also important because it allows the UA to make
> an informed decision about whether or not it wants to incur the possible
> cost of preloading. For instance, if the UA detects that the network is
> severely bandwidth constrained, it might decide to not issue preload
> requests for very large objects due to the possibility that the resource
> may never be requested. For instance, if the user clicks off the page
> before it is fully loaded.
>

Can you illustrate with more examples? If the user clicks off the page
before it is fully loaded, then the rendering engine cancels the resource
requests, which will cancel the HTTP fetch. This takes a roundtrip to get
origin servers not to send any more data.


> Similar to the argument Ilya made about the UA being in the best position
> to decide the number of pre-connects for a given host, though I don't think
> that is strictly true for pre-connects, it is surely in the best position
> to decide whether or not the potential cost of prefetching outweighs the
> benefit due to last mile bandwidth limitations. And "expected size" gives
> the UA the information needed to make this determination.
>

Can you explain why bandwidth contention is better solved with clients
holding back large requests rather than holding back low priority requests?
jQuery is large, but we download it anyway because it's critical to
rendering.


>
> Ilya,
>
> Where do you think it's best to have this discussion? I think it's really
> important.
>
> Thanks,
>
> Peter
>
> On Jul 10, 2014, at 5:41 PM, Ilya Grigorik <igrigorik@google.com> wrote:
>
> Peter, Guy, Mark, thanks for the feedback! Comments inline.
>
> On Tue, Jul 8, 2014 at 8:08 PM, Nottingham, Mark <mnotting@akamai.com>
>  wrote:
>>
>> 2) The "Caching Grace Period" section seems a bit iffy to me... I
>> wouldn't express this as being an override of the caching policy, but
>> rather of it being applied *after* the cache; i.e. the rendering engine
>> itself effectively caches it for next use.
>>
>
> Yep, great point. Will suggested the same and I've took a run at reworking
> that section. Let me know how this looks:
> https://github.com/igrigorik/resource-hints/issues/5
>
>
> On Thu, Jul 10, 2014 at 7:27 AM, <bizzbyster@gmail.com> wrote:
>>
>> On Jul 9, 2014, at 9:20 AM, "Podjarny, Guy" <gpodjarn@akamai.com> wrote:
>>
>> Section 2.1 (preconnect):
>>
>>    - One delta between pre connect and dns-prefetch is cost to the UA.
>>    My understanding is that establishing a connection is more expensive in
>>    resource utilization than DNS prefetch too. Therefore, dns-prefetch may be
>>    used more lightly, and perhaps it's a reason to not think of dns-prefetch
>>    as a preconnect.
>>
>> Fair enough. That said, I think this is something worth experimenting
> with.. All modern browsers are already doing preconnects anyway (without
> the hint and based on own heuristics), so I'm not sure that the
> dns-prefetch upgrade would change the picture by much. I'll see if I can
> get some data from HTTP Archive on how often dns-prefetch is used in the
> wild.
>
>>
>>    - For some domains (e.g. Your CDN domain), it'll actually be helpful
>>    to open multiple connections, not just one (assuming no SPDY/HTTP2).
>>    Specifying a number sounds too wrong, but does it make sense to put a
>>    weight factor on the preconnect? Maybe a "primary" vs "secondary" domain?
>>    Could be getting into the diminishing returns space.
>>
>> I agree that it is helpful to open multiple connections for many domains
>> but don't see a problem with specifying a number. The draft argues that the
>> UA is "is in the best position to determine the optimal number" of
>> connections per domain. But this is not always the case. If the server were
>> able to receive and leverage feedback from browsers ("past request
>> patterns" in the draft) then it could know more about the capabilities of
>> various domains. For instance, we see some servers allow a large number of
>> concurrent connections and others enforce strict low limits. I think it
>> makes sense to include a suggested number of connections in the pre-connect
>> hint. The UA is free to ignore that suggestion.
>>
>
> I understand the motivation, but I still think this exposes knobs that
> should be left to the user agent. The number of connections will vary by
> users connection type, time of day, protocol, and so on, all of which are
> dynamic. Browsers already track this kind of information and adapt their
> logic to take this into account - e.g. chrome://dns/ (see "Expected
> Connects" column). With HTTP/2 this is also unnecessary (and I say that
> with awareness of your recent thread on http-wg on the subject :)).
>
>> Section 2.2 (preload):
>>
>>    - With today's implementations, double downloading of preloaded
>>    resources is a major issue. Would be good to make some explicit definitions
>>    about how to handle a resource that has been requested as a preload
>>    resource already and is now seen on the page. An obvious rule should be to
>>    not double download, but others may be more complex (e.g. What if we
>>    communicated a low prio via SPDY/HTTP2?)
>>
>> - Matching retained responses with requests:
> https://igrigorik.github.io/resource-hints/#matching-request
> - (Re)prioritization: https://github.com/igrigorik/resource-hints/issues/1
>
>
>>
>>    - Content type as text sounds a bit error prone. Would
>>    "text/javascript" cover "x-application/javascript" too? Is there a way to
>>    normalize content types?
>>
>> Jake proposed using "context" instead, which I really like, but need to
> do some more digging on:
> https://github.com/igrigorik/resource-hints/issues/6
>
>>
>>    - Should preload resources delay unload? (my vote is no)
>>
>> Preload hints are for the *current* page. As a result they are cancelled
> as part of onunload. If you need the request to span across navigations,
> you should be using prefetch, which is used to load resources for next
> navigation.
>
>>
>>    - What should preload (and prefetch) do in case the resource request
>>    got a temp error (e.g. 502)
>>    - How should the UA handle cookies set in a response to a preload (or
>>    prefetch)?
>>
>> Hint-initiated requests are not special in any way: think of any request
> initiated by the preload scanner today, all the same behaviors here. If the
> request fails, it fails.. it sends the same cookies, and so on.
>
>
>> A few more to add to this list:
>>
>>    - How to handle the fact that cookies may have changed between the
>>    requesting of the preload resource and the requesting of the resource by
>>    the renderer either due to a Set-Cookie or a locally executed javascript?
>>    Perhaps we could add an attribute that indicates that the resource is
>>    cookie-sensitive or not?
>>
>> We don't. You have the same race condition today with the preload scanner
> sending early fetches for JS/CSS.
>
>>
>>    - The earlier spec discussed preload hints URLs that were generated
>>    via javascript. I think this is very powerful as it allows the browser to
>>    preload dynamically generated URLs. For instance, URLs with sessionID or
>>    Date or rand appended to them.
>>
>> Yes, this is what preconnect covers. We don't know the URL, but if we
> know the origin we can at least complete the handshake:
> https://igrigorik.github.io/resource-hints/#preconnect (example 1)
>
>>
>>    - By viewing past behavior, especially with resource priorities in
>>    HTTP/2, the server can actually know quite a bit more than the browser
>>    about resource priorities. It would be great if the server could provide
>>    the UA with a hint as to the importance of the object. Is it a serializing
>>    resource? Does visual completeness depend on it? This information could be
>>    communicated via a simple low, medium, high type scheme and the spec could
>>    provide description as to what these values mean.
>>
>> That's what type/context is meant to provide. Today we don't have a more
> fine grained mechanism to communicate priorities. Perhaps we should, but I
> think that's a separate discussion.
>
>>
>>    - In order to make optimal use of a connection pool, it's valuable to
>>    know the size of a resource ahead of time. Is it possible to include an
>>    expected-size attribute?
>>
>> *If* we were to consider introducing this, I don't think its limited to
> hints. As such, I think this is a separate discussion.
>
>>
>>    - As per our other email thread, we should include object version
>>    information in the preload hint so as to minimize cache re-validation
>>    requests.
>>
>> I still think that subresource integrity is the right place to discuss
> this: http://www.w3.org/TR/SRI/#caching-optional-1
>
>> Section 3.4 (Caching grace period):
>>
>>    - Since these hints are explicitly added, I think we can be a bit
>>    more strict in what we require.
>>    - My vote would be:
>>       - For preload, do the same thing the preparser does, which I
>>       believe means use the resource regardless of whether it's cacheable, as
>>       long as you're in the midst of loading the current page (may require some
>>       definition of when has the page finished loading, which I suspect the
>>       preloader deals with too). If you go to another page, revert to the cache
>>       instructions on the resource.
>>
>> +1
>>
>
> Yes, this should be covered by the new "matching requests" section.
>
>>
>>    - For prefetch & prerender, use the cache instructions (no grace
>>    period or changes)
>>
>> This would cripple prefetch and prerender because most dynamic content is
> marked as non cacheable. Think of prerender as opening a background tab (or
> middle click, if you prefer), except that the tab is invisible and is then
> instantly swapped-in on navigation as long as it hasn't expired (insert
> reasonable TTL here.. Chrome uses 300 seconds).
>
>> A couple of additional questions:
>>
>>    - How would these hints, and specifically preload, interact with
>>    Client Hints?
>>
>> Assuming CH is implemented, the relevant hints would be advertised on the
> outbound request. Nothing special.
>
>>
>>    - What about srcset and the picture element (e.g. Native conditional
>>    loading mechanisms)?
>>
>> I don't see any concerns here. If you have conditional loading then you
> must evaluate those conditions.. With native <picture> those conditions
> will be executed by the preparser (yay) if the main doc parser is
> blocked... Yes, you may not be able to stick a Link header hint or put a
> <link> hint in the head of the doc, but such is the cost of conditional
> fetches. On the other hand, if you *know* you need a specific file
> regardless, feel free to hint it.
>
> ig
>
>
>