Re: [resource hints] preconnect, preload, prender

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 
> <mailto: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? :)
>