Very interesting, thanks Yoav.
As an aside from the Mike’s issue, reading the W3C spec got me wondering if there is any definition of how non-browsers should handle preload. It seems like there is a guidance gap for non-browsers when, as you’ve identified, there are some clear use cases for preload. If there was some energy for writing up some standards language of this nature, would it belong to the W3C spec or would it be better placed elsewhere?
Regards
Lucas
From: Yoav Weiss [mailto:yoav@yoav.ws]
Sent: 26 June 2017 16:59
To: Julian Reschke <julian.reschke@gmx.de>; 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>
Subject: Re: Last Call: <draft-ietf-httpbis-early-hints-03.txt> (An HTTP Status Code for Indicating Hints) to Experimental RFC
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