Proposal: add a boolean flag `render-blocking` to the `request` concept

[xiaochengh]

(Edited: Removed the parts about exposing it via the Request API)

The HTML spec recently specified a render-blocking mechanism, which allows certain elements to be render-blocking, namely, to block rendering until their external resources have been loaded.

In coordination, I'm proposing to add a boolean flag, render-blocking, to the request concept to indicate whether the request is for an element that is render-blocking. For now, the flag is not web-exposed via the Request API.

The technical details are at:

• Add a render-blocking boolean flag to the request concept #1432
• Set requests' render-blocking flag when fetching resources for render-blocking elements html#7885

The motivations are:

1. It can be used as a signal for "chaining" render-blocking resources: render-blocking resource A can have a link header with blocking=render that triggers loading of another render-blocking resource. This is especially useful for eliminating FOIT & layout shifts for 3rd party web fonts (see exact usage).

2. It can be used as a signal to set the fetch priority, so that we never fetch a render-blocking resource at the low priority. The current spec only uses two signals, which are not enough. See also discussions at blocking=render should override fetch priority WICG/priority-hints#69

[xiaochengh]

@annevk @yoavweiss @domenic

[annevk]

These use cases are only applicable when a service worker is in use, right? And when you say Chrome has already been doing it, that's presumably limited to DevTools, which is a somewhat different use case and would not end up standardized by exposing this on Request objects (note that these are somewhat distinct from the underlying request concept, where I agree we need to add it for determining priority and such).

[yoavweiss]

I believe what @xiaochengh meant is that Chromium exposes this to traces, which are used by developer tooling, and found to be useful by developers.

It's a different use case, but e.g. makes me think we should web expose this info in Resource Timing. I agree that an internal flag would be sufficient for that.

I guess that for web-exposing the flag on the Request object itself we'd need a Service-Worker case that e.g. treats scripts and style requests differently when they are render blocking.

[xiaochengh]

Hmm, maybe I didn't realize there's a difference between the request concept and the Request object, and I though they must reflect each other... (@annevk pointed it out in WICG/priority-hints#69 (comment) but I didn't fully understand...)

What I really want to do is to add it to the request concept, which already supports use cases 2 & 3. We don't really have a service worker use case so we don't really need to add it to the Request object.

Is adding it only to the request concept fine to you? If so, I'll revise the proposal and the PRs.

[annevk]

Yeah, that is totally fine. It's in fact preferable as it allows us to evaluate the "private API" for some time before deciding it's worth exposing publicly.

[xiaochengh]

Thanks. I've updated the proposal and the PRs. Please review them at:

• Add a render-blocking boolean flag to the request concept #1432
• Set requests' render-blocking flag when fetching resources for render-blocking elements html#7885

[noamr]

I'm not sure about this.
I don't know if the concepts of render blocking should belong in fetch. It's great if blocking resources give some priority indication to fetch, but perhaps extending the current definition of fetch priority is sufficient for that?

How would it interact with fetchpriority=low for example?
Maybe it should be fetchpriority=render-blocking or so? And then we don't need to set blocking=render on preloads (see whatwg/html#7896) and we can set it solely on the resource use itself, and play with the priority only?

[xiaochengh]

How would it interact with fetchpriority=low for example?

UA should look at both fetchpriority and render-blocking when setting the "real" priority (see discussion WICG/priority-hints#69). In Blink's implementation, I'm planning to bump the priority to at least high if render-blocking (see patch https://chromium-review.googlesource.com/c/chromium/src/+/3627294).

For the remaining questions, I think they all depend on whether we want blocking=render on preloads. I've responded in whatwg/html#7896.