Re: [resource hints] preconnect, preload, prender

>
> Some questions/thoughts on the specifics:
> * Does <link rel="preconnect"> need a new attribute to indicate how
> many connections to open? Or would the author just include the tag
> multiple times if they want multiple connections?
>

I think we should (mostly) defer this to the UA.. Treating multiple <link
preconnect> tags as a hint that the UA should open multiple connections
could work, but that's not guaranteed. Case in point, with HTTP/2 on
horizon, you shouldn't need more than one connection anyway - e.g. if first
preconnect gets an upgrade to HTTP/2 or SPDY, then don't open others..
Alternatively, if you have past knowledge of this origin and number of
connections used, then use that information as well.


> * Does <link rel="preload"> do anything different than the <link
> rel="subresource">[1] that chrome already supports?
>

(1) It's "content aware". subresource has a single priority and that
priority is always below any resource initiated by the preloader or main
parser.
(2) it supports "resource for this page" vs "resource for future page" via
lazyload attribute (merges subresource + prefetch, and adds (1) to prefetch)


> * The part about prerendering things other than HTML is brilliant.
> Could it parse CSS and compile JS as well? If so, does it need a more
> general name?


Personally, calling "JS parse/compile" as "prerender" doesn't bother me
that much.. but yeah, might make sense to use a more generic name.

---

We can collapse dns-prefetch into preconnect. But as Tony mentions, there
> are different semantics associated with both. So we could keep them
> separate. I think it is better to keep all 5 hints (dns, connect, prefetch,
> subresource and prerender) - it gives developers maximum control.
>

We don't need to (can't, really) remove the old hints.. But moving forward,
I'd rather push developers to use pre{connect,load,render} hints instead,
as they would offer a more consistent interop with preloader and other
parser-initiated requests. Under the hood, all of these hints can/should
share a lot of the same code.


> But this is not the challenging part. I think the key issue raised by Ilya
> was to have each one of these hints a well defined behaviour. e.g. he says:
> When/how many prerenders may be triggered and when prerender is aborted


To clarify, I'm not asking for hard guarantees (the whole point is that
these are all hints and hence best effort), but I want to make sure that
the interop between hints and their behavior is specced and consistent
between different browsers.

Trivial example: today, it's possible to construct cases where <link
subresource> would actually hurt your performance - the resource is
downloaded with wrong priority, results in double downloads, etc.

On a similar note... <link prerender> does not work on Chrome mobile today
due to concerns over resource constraints. But, if that's the case, a much
better outcome would be to demote prerender to preload, or at least a
preconnect, then to skip the hint entirely. If multiple prerender hints are
present and there are not enough resources, then demote both to preload...
AFAIK, only Chrome supports dynamic hint add/remove, and so on...

ig


On Thu, Nov 21, 2013 at 1:53 AM, Jonny Rein Eriksen <jonnyr@opera.com>wrote:

>  Nice! Giving web developers access to directly program the speculative
> performance part of a page load should give big boosts for first page load.
> Especially high latency page loads on radio networks.
>
>
> On 21.11.2013 05:28, Arvind Jain wrote:
>
>  We discussed this at the working group meeting last week.
>
> We were trying to get <link rel=prerender> inserted into html5 spec and
> the feedback we got was to take the specification language I put in the
> microformats registry (http://microformats.org/wiki/rel-prerender) into a
> new spec.
>
> We can cover prefetch and dns-prefetch, both of which are also specified
> (prefetch in html5 spec and dns-prefetch in registry) in the same spec.
>
> We can collapse dns-prefetch into preconnect. But as Tony mentions, there
> are different semantics associated with both. So we could keep them
> separate.
>
> We can also collapse prefetch  and subresource hints or again keep them
> separate.
>
> I think it is better to keep all 5 hints (dns, connect, prefetch,
> subresource and prerender) - it gives developers maximum control.
>
>
> On DNS and connect:
>
> We might want to limit number of preconnects if multiple pages are loading
> at the same time or we are connecting through a proxy. So we could easily
> end up in a situation where preconnect would have to fall back to DNS
> preresolve.
>
> Could also be interesting to fall back to DNS preresolve if we are
> limited. Or if we are connecting through a SOCKS proxy DNS preresolve could
> possibly improve connect time in the proxy.
>
>
>  But this is not the challenging part. I think the key issue raised by
> Ilya was to have each one of these hints a well defined behaviour. e.g. he
> says:
>
>    -
>
>    When/how many prerenders may be triggered and when prerender is aborted
>
>
>
>  How would you define this? Take a look at the prerender writeup (
> http://microformats.org/wiki/rel-prerender) and suggest how to specify it
> further
>
> Arvind
>
>
>  I love this proposal and think we should consider it in the group.
> Jatinder, any thoughts from your end?
>
> Some questions/thoughts on the specifics:
> * Does <link rel="preconnect"> need a new attribute to indicate how
> many connections to open? Or would the author just include the tag
> multiple times if they want multiple connections?
> * Does <link rel="preload"> do anything different than the <link
> rel="subresource">[1] that chrome already supports?
> * The part about prerendering things other than HTML is brilliant.
> Could it parse CSS and compile JS as well? If so, does it need a more
> general name?
>
> Does the order of tags indicate importance, or should there be other ways
> of indicating priority? Does that change if injecting hints through js?
> Could the hints also be used on subsequent loads to improve performance?
> Would this be better than hints the browser could generate/store itself?
> Do we need tools for generating/testing the hints?
>
> /Jonny
>
>
>
> -Tony
>
> [1]
> http://www.chromium.org/spdy/link-headers-and-server-hint/link-rel-subresource
>
> On Mon, Nov 11, 2013 at 9:06 AM, Ilya Grigorik <igrigorik@google.com>
> wrote:
> > Unfortunately won't make it to TPAC in person but seeing "prerender"
> topic
> > on the agenda would like to share some thoughts on where I'd love to see
> the
> > effort go in the coming year...
> >
> > Specifically, I think the platform is missing some critical primitives
> that
> > can allow the site/app developers help the browser perform speculative
> > optimization: preconnects, preloads, prerenders. Yes, we do have <link
> > rel={dns-prefetch,prefetch,subresource,prerender}>, but in practice the
> > current implementations of these hints often makes them less than useful
> -
> > missing support, scheduling/prioritization gotchas, bad interop with
> > preloaders, inconsistent implementation between different UAs, and so on.
> >
> > I think we should revisit what we've learned from our current hints and
> > produce a spec around the three core primitives: preconnect, preload,
> > prerender. To that end, drafted a quick doc describing the use cases and
> > motivation for each one:
> >
> https://docs.google.com/document/d/1HeTVglnZHD_mGSaID1gUZPqLAa1lXWObV-Zkx6q_HF4/edit
> >
> > Would love to hear any thoughts and feedback!
> >
> > P.S. Resource Hints spec as a 2014 goal? :)
>
>
>