[whatwg/fetch] Proposal: add a boolean flag `render-blocking` to the `request` object (Issue #1433)

The HTML spec recently specified a [render-blocking mechanism](https://html.spec.whatwg.org/C/#render-blocking-mechanism), which allows certain elements to be [render-blocking](https://html.spec.whatwg.org/C/#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` object to indicate whether the request is for an `element` that is render-blocking. The technical details are at:
- whatwg/fetch#1432.
- xiaochengh/html#2 (I'll move this to whatwg/html later)

The motivations are:

1. It is a generally useful information to be exposed to web developers to study their page load performance. [Chrome has already been doing that](https://blog.webpagetest.org/posts/new-render-blocking-indicator-in-chrome-and-webpagetest/), and it would be better if this can be standardized.

2. 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](https://gist.github.com/xiaochengh/9404abbecdc3b45c0e9f3d5e99fbc65d#use-cases)).

3. It can be used as a signal to set the fetch [priority](https://fetch.spec.whatwg.org/#concept-request-priority), so that we never fetch a render-blocking resource at the low priority. The [current spec](https://fetch.spec.whatwg.org/#ref-for-concept-request-priority) only uses two signals, which are not enough. See also discussions at https://github.com/WICG/priority-hints/issues/69


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1433
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1433@github.com>