Re: resource hints @ tpac

>  *Arvind: *What's preload and preconnect? Are these new?
>
> *Jatinder: *It's unclear if some of these are just renaming prefetch or
> something new.
>

Preconnect not new for UAs, but new as an explicit hint. There are many
cases where the site knows that it will need a resource from host X, but
does not yet know which resource it is (e.g. dynamic third party resources:
ads, web fonts, and so on). This is especially useful for TLS connections,
as it would allow us to perform the DNS+TCP+SSL handshake ahead of time,
potentially saving 1-4 RTTs.

Preload is new and is an attempt to define a "unified prefetch hint": a
hint that can be used to preload resources for the current page
(subresource fails at this), and for future navigation (i.e. current
prefetch), plus address existing prioritization problems with "subresource"
(which is effectively useless as implemented today). More on that below...


>  *Plh: *It might be worthwhile to specify this in the spec so developers
> know what to expect
>
> *Jason: *Depending on environment, like if you're on 3G, you may not want
> to do these optimizations.
>

Agreed. Hints are just that.. hints.


>  *Arvind: *Ilya just asked questions here, there weren't any
> recommendations on the number. As Jason mentioned, the number of
> connections is hard to specify depending on device and environment. I
> recommend we just leave it as is, but if someone can justify having a
> specific number then we can add it to the them.
>

Fair enough, I can see the contradiction here :)


>  *Jatinder: *Prefetch is already defined and so is prerender. Are we
> really trying to define a preconnect
>

Prefetch is intended to fetch resources for future navigation, it doesn't
cover current page. And if we want to cover current page, then we need to
talk about priorities of those requests such that they work with built-in
preloaders and other prioritization logic.

We could keep prefetch / preload as separate hints and distinguish them
based on current vs future page.


>  *Jason: *IE already has an internal database where its checking when to
> do a preconnect. It doesn't make sense to have a developer give this hint.
>
> *Arvind: *in some cases the browser may not get to a resource fast
> enough, with a hint we can do something sooner. If you take an example of
> search engine, it can potentially benefit by specifying a preconnect.
>
> *Jatinder:* But at parse time the browser will encounter the preconnect
> attribute at the same time as it encounters the URL.
>

No, that's the point.. There are many cases where the UA does not know that
it will need to connect to that host until it's too late. For example, I
know that my ads script / social widget will connect to <cdn.provider.com>,
but the actual resource bootstrapping that request (JS file / CSS file) is
coming from a completely different origin -- sadly, this is a common
occurence.

Another example: I have a JS loader script which is served from local
origin, but which will conditionally load different libraries from some CDN
provider. With a preconnect hint I can get the UA to start the handshake
early such that when the JS is executed, there is already a warm connection
waiting.


>  *Jason: *IE supports preconnect on a heuristics base. I believe it’s
> some 80% hit rate of determining which one is going to be preconnected
>
> *Jatinder:* Are we leaning towards defining preconnect?
>
> *Jason: *I would caution because the developer may shoot themselves on
> the foot.
>

Why and how?

>  *<JatinderMann_>* dns-prefetch
> * <Arvind>*
> https://docs.google.com/presentation/d/18zlAdKAxnc51y_kj-6sWLmnjl6TLnaru_WH0LJTjP-o/present#slide=id.g33211238_0_2
>
> *Arvind:* Based on Ilya's slides, there is "dns-prefetch", "prefetch",
> "prerender", "subresource". At least "prerender" and "prefetch" are
> supported everyone. "subresource" is unnecessary
>

subresource is necessary but doesn't work today - we need to fix it!


>  *Arvind: *Looks like we currently have prefetch in the HTML5 spec,
> prerender and dns-prefetch is in the registry.
>
> ...I think it makes sense to bring in preconnect if dns-prefetch is there.
> dns-prefetch is the lowest cost, preconnect is a bit more work where we're
> opening the connection, prefetch will download the resource end to end, and
> prerender navigates to the page. Seems like it makes sense.
>
> *Jatinder: *We should discuss with HTML5 WG to include dns-prefetch and
> prerender.
>
> *Arvind: *We should discuss all four with the HTML WG.
>
> *Jatinder:* ACTION Jatinder include prerender, dns-prefetch in HTML5 spec
> and consider preconnect as well
>

And subresource with proper priority support! That would give us:

- dns-prefetch
- preconnect (TCP + TLS handshake)
- subresource (current page + request priority)
- prefetch (future page)
- prerender (full page)

The only substantial difference between above and what I proposed is that I
collapsed subresource and prefetch into "preload" - that said, there is no
reason why they can be kept as separate hints... Perhaps the only other
thing to add is that each successive hint should implicitly include hints
below it (e.g. subresource can fallback to preconnect and so on), but
that's more of an implementation detail.