- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 26 Jun 2017 18:08:57 +0200
- To: Yoav Weiss <yoav@yoav.ws>, Kazuho Oku <kazuhooku@gmail.com>
- Cc: ietf@ietf.org, httpbis-chairs@ietf.org, Mark Nottingham <mnot@mnot.net>, draft-ietf-httpbis-early-hints@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>, alexey.melnikov@isode.com, Mike West <mkwst@chromium.org>
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. *How* the client does that is an implementation detail of the client. If I understand the issue correctly, *any* mechanism that would send "early" information would have the same problem, right? Best regards, Julian
Received on Monday, 26 June 2017 16:09:45 UTC