Re: [whatwg] resource hints and separating download from processing

On Fri, Aug 15, 2014 at 9:26 AM, Ian Hickson <ian@hixie.ch> wrote:

> > Two high-level cases:
> > (a) optimizing load sequence of page that's currently being loaded
> > (b) optimizing page load of a (potential) future navigation
> >
> > For (a), we need to expose "preconnect" and "preload", such that the
> > developer and/or server (e.g. CDN accelerator) can tell the browser
> > which hosts it should connect to, which resources it should load (+ with
> > which priority, order), etc. Also, note that "preload" separates
> > download from processing, which is an important feature - e.g. fetch CSS
> > but don't evaluate it.
>
> Preload is straight forward, sure. How much does preconnect within a page
> actually help? Isn't just declaring the URLs enough? I don't really see
> how you expect this to be used or exposed.
>

It's often the case that you don't know the exact URL you want to fetch
(e.g. the URL is generated based on local client context, etc), but you
know that you *will* connect to a certain host - lots of third party
widgets, fonts, etc, fall into this category. As a concrete example:

- <link href='https://fonts.googleapis.com/css?family=Open+Sans'
rel='stylesheet'>
- above stylesheet is "dynamic" and returns a pointer to a UA optimized
font file that lives on https://fonts.gstatic.com

As a result, I know that I'll need a connection to https://fonts.gstatic.com,
but I don't know the exact URL. Also, because we're talking HTTPS, we're
looking at up to 4 RTTs (DNS, TCP, TLS), which can easily translate to 1s+
on mobile connections. Issuing an early preconnect allows us to hide some
or all of this latency.

Another example is improving performance of redirect click trackers, see
example 2:
https://igrigorik.github.io/resource-hints/#preconnect


> > For (b), we're talking about a speculative hint, hence we attach a
> > probability to the hint and let the UA decide if it has enough resources
> > / time / etc, to execute it, and how far it is willing to go with
> > response processing.
>
> The ability to tell a page what subsequent resources will be necessary
> (prerendering) seems pretty straight-forward too, sure. That's mostly a
> solved problem with rel=prerender, no? Anything we add to make fetching
> more powerful will automatically be exposed to that too, presumably.


Solved in the sense that we have the attributed listed in the HTML spec.
Not solved in the sense that current implementations of prerender can (and
need to) be significantly improved - e.g. how they handle different content
types, how they handle resource contention, how the developer can
communicate the context/probability of using the hinted resource, the APIs
available to invoke these actions (dynamic scheduling/canceling, HTTP
headers), and so on. Further, now that we have multiple implementations
(Chrome, IE, and FF has started working on it), we need a common spec such
that we can deliver a consistent API and experience.

That said, I think we're on the same page... I'm just arguing that "X will
subsume resource hints" is not entirely true: we still need to define how
preconnect/preload/prerender need to behave, which APIs they will expose,
what guarantees they will provide, and so on. None of that is currently
spec'ed, which is the gap I'm trying to fill.

ig

Received on Friday, 15 August 2014 22:22:19 UTC