Add Render Blocking Status to PerformanceResourceTiming

[abinpaul1]

Introducing a render blocking status field. (https://github.com/w3c/resource-timing/issues/262) Fetch changes : https://github.com/whatwg/fetch/pull/1449 HTML changes: https://github.com/whatwg/html/pull/7979

Explainer : https://github.com/abinpaul1/resource-timing/blob/render-blocking-status-explainer/Explainer/Render_Blocking_Status.md

---

Preview | Diff

[yoavweiss]

Thanks @abinpaul1!!

@caribouW3 - What do we need to appease the IPR bots here? Should Abin join the WG as an invited expert?

[caribouW3]

Are we in situation 2. b described here: https://github.com/w3c/Guide/blob/master/process/non-participant-commitment.md I think that if it's a one-time contribution, a non-participant commitment is enough (Contributor needs a W3C public account, link it with the GH account, then it's done by submitting a licensing commitment form).

[yoavweiss]

We discussed this on the WG call yesterday.

@bdekoz @sefeng211 @achristensen07 - I'd love y'all's thoughts on this

[yoavweiss]

Left a relevant comment on the Fetch PR that would impact this PR as well/

[noamr]

Any WPTs for this?

[noamr]

Great idea, though I believe this would be confusing with preloads until we resolve https://github.com/w3c/resource-timing/issues/303. If you preload a stylesheet and then load it as render-blocking, it would currently appear as not render-blocking because currently we don't expose preload-consuming requests in resource timing.

[abinpaul1]

Any WPTs for this?

It's being added over at https://chromium-review.googlesource.com/c/chromium/src/+/3709521 Have added a few cases but its still a WIP

[noamr]

It's probably failing because the Fetch PR is not merged yet. I want that merged first and to get some understanding about https://github.com/w3c/resource-timing/pull/327#issuecomment-1159514743 before proceeding

[yoavweiss]

I agree that this would be confusing initially, but don't know if we want to block this work on solving preloads. @noamr - Would an intermediate state where preload RT enrties are marked as non-blocking be too confusing in your opinion? I believe this is what Chrome is currently doing with traces.

[noamr]

I agree that this would be confusing initially, but don't know if we want to block this work on solving preloads.

@noamr - Would an intermediate state where preload RT enrties are marked as non-blocking be too confusing in your opinion? I believe this is what Chrome is currently doing with traces.

Sounds ok, just wanted to get that conversation started (this PR is blocked on the fetch PR)

[abinpaul1]

Changed the type of render blocking status from string to enum as per TAG suggestion https://github.com/w3ctag/design-reviews/issues/753#issuecomment-1197900871.