Re: Last Call: <draft-ietf-httpbis-early-hints-03.txt> (An HTTP Status Code for Indicating Hints) to Experimental RFC

On Mon, Jun 26, 2017 at 6:09 PM Julian Reschke <>

> On 2017-06-26 17:58, Yoav Weiss wrote:
> > An issue <> raised by Mike West
> > (CCed) got me thinking if Early Hints are at all implementable at the
> > browser level (rather than just used as early push hints at the CDN
> level).
> >
> > Currently, at least in Chromium and WebKit, requests triggered by
> > preload links are not sent until the document is committed, which means
> > that they are not sent immediately when the browser processes them.
> > That's likely to be a short, internal delay.
> > However, in the context of Early Hints, that delay can be significant,
> > as it can take hundreds of milliseconds for the renderer process to get
> > created. At the same time, a lot of the logic required to send those
> > requests out sits in the rendering engine.
> >
> > I'm not sure what is the solution to bridge that gap, if one exists.
> >
> > Cheers,
> > Yoav
> As the IETF HTTP WG, we can specify the bits on the wire that *allow* a
> client to start fetching things earlier.

I agree. The CDN use case is probably still a viable one, regardless of
this issue.

> *How* the client does that is an implementation detail of the client.

This is not a question of *how* but potentially a question *if* it's at all
possible to do so for a pretty significant set of clients.

> If I understand the issue correctly, *any* mechanism that would send
> "early" information would have the same problem, right?

Indeed. The issue is similar with any API or syntax that would be destined
to trigger requests from the rendering engine before it is created and the
document is committed.

> Best regards, Julian

Received on Monday, 26 June 2017 16:32:11 UTC