On Mon, Jun 26, 2017 at 6:09 PM Julian Reschke <julian.reschke@gmx.de> wrote: > On 2017-06-26 17:58, Yoav Weiss wrote: > > An issue <https://github.com/w3c/preload/issues/101> 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