[whatwg/fetch] Allow updating of render-blocking status (Issue #1875)

tunetheweb created an issue (whatwg/fetch#1875)

### What is the issue with the Fetch Standard?

#1432 (and https://github.com/whatwg/html/pull/7885 the equivalent for HTML) allowed setting of a `render-blocking` flag on Fetch Requests, which is subsequently exposed in Resource Timing.

It's been [noted by developers](https://issues.chromium.org/issues/457303652) that it is not handled as expected when a fetch request is used for multiple HTML elements, only some of which are render-blocking.

For example this would be result in a render-blocking request 

```html
<link rel="stylesheet" href="css/styles.css">
```

but this would not:

```html
<link rel="preload" as="style" href="css/styles.css">
<link rel="stylesheet" href="css/styles.css">
```

This is a fairly common pattern used by developers to try to improve performance. Whether it has any use now or is an anti-pattern is debatable (Chrome will give a preload request a lower priority, but then discover the the second request right away if just after it, and will upgrade the request making it's impact negligible), but regardless this pattern is used.

Either way the resource is blocking the render of the page so to report it as `non-blocking` in Resource Timing is not useful for developers looking to identify requests that are blocking the render of the page.

See also https://github.com/w3c/resource-timing/issues/420

The spec isn't super clear as to how this should be handled, though [it is set in timing-info at the initialisation of the request](https://fetch.spec.whatwg.org/#fetch-controller-report-timing-steps:~:text=Let%20timingInfo%20be%20a%20new%20fetch%20timing%20info%20whose%20start%20time%20and%20post%2Dredirect%20start%20time%20are%20the%20coarsened%20shared%20current%20time%20given%20crossOriginIsolatedCapability%2C%20and%20render%2Dblocking%20is%20set%20to%20request%E2%80%99s%20render%2Dblocking), and then not updated later meaning reporting the initial resource-blocking status is what the spec defines.

Chrome (the only implementer of `renderBlockingStatus` in Resource Timing) is [planning on changing this](https://chromium-review.googlesource.com/c/chromium/src/+/7112285) to match developers expectations so we'd like the spec to align to this. However, I'm struggle to see where in the spec this should be set. And even if this is in the Fetch spec or the HTML spec since it's kinda aligned to both (I think it's here as this deals with resource-timing).

We could add a step to [the fetch response hander section](https://fetch.spec.whatwg.org/#fetch-controller-report-timing-steps:~:text=The%20fetch%20response%20handover%2C%20given%20a%20fetch%20params%20fetchParams%20and%20a%20response%20response%2C%20run%20these%20steps%3A) to take the latest render-blocking attribute but the better way (and what Chrome is planning on doing) is to update this `timingInfo` as new request information is found if they are render-blocking. That leaves the fetch response hander section as is to just take the latest `timingInfo`. But I don't see a section in the Fetch spec about subsequent requests which already match an existing request — though I'm not overly familiar with this spec so could be I've just missed this? Or perhaps that's part of HTML spec (though again I'm struggling to find where)?

Thoughts or pointers as to how to handle this?

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

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