Add Render Blocking Status to PerformanceResourceTiming

[abinpaul1]

Introducing a render blocking status field. (#262)
Fetch changes : whatwg/fetch#1449
HTML changes: whatwg/html#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 #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 #327 (comment) 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 w3ctag/design-reviews#753 (comment).

[noamr]

LGTM

[yoavweiss]

LGTM