Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explainer for Render Blocking Status #330

Merged
merged 3 commits into from
Sep 26, 2022
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
58 changes: 58 additions & 0 deletions Explainers/Render_Blocking_Status.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
# Render Blocking Status

Proposal to add a new field `render blocking status` to PerformanceResourceTiming which holds a string highlighting the status of stylesheets and scripts.

## Use cases

RUM providers could then easily determine the render blocking resources without having to rely on complex heurestics to determine the same.
This would enable analysis for below scenaarios and possibly more.
abinpaul1 marked this conversation as resolved.
Show resolved Hide resolved
- Determine resources downloaded before FCP but were not render blocking? (and hence, could've been delayed)
- Determine resources that were render blocking, but weren't discovered early enough? (and hence, could've benefited from being preloaded)
(Reference : https://github.com/w3c/resource-timing/issues/262)


## API Changes and Example Code

The PerformanceResourceTiming Interface in <a href="https://w3c.github.io/resource-timing/#sec-performanceresourcetiming">resource-timing</a> would be updated to
```bash
[Exposed=(Window,Worker)]
interface PerformanceResourceTiming : PerformanceEntry {
...
...
readonly attribute DOMString renderBlockingStatus;
...
...
[Default] object toJSON();
};
```

Sample usage:
```javascript
const entry_list = performance.getEntriesByType("resource");
console.log(entry_list[0].renderBlockingStatus);
```


## Render Blocking Status Values

The following values are proposed for the resource blocking status

`blocking` - A potentially render blocking resource

`non-blocking` - Non blocking resource

We primarily reuse the value of the [render blocking](https://fetch.spec.whatwg.org/#request-render-blocking) boolean associated with fetch [request](https://fetch.spec.whatwg.org/#concept-request)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
We primarily reuse the value of the [render blocking](https://fetch.spec.whatwg.org/#request-render-blocking) boolean associated with fetch [request](https://fetch.spec.whatwg.org/#concept-request)
We primarily reuse the value of the [render-blocking](https://fetch.spec.whatwg.org/#request-render-blocking) boolean associated with fetch [request](https://fetch.spec.whatwg.org/#concept-request)

Also the HTML spec uses "render-blocking" rather than "render blocking", even when not explicitly referring to the render-blocking boolean, which seems more correct to me. Should we use that format throughout this doc (which would also avoid errors like this when actually refer to the boolean)?

And, if so, possibly rename the file too to Render-blocking_Status.md - or would that mix of dashes and underscores just be confusing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I've made the changes everywhere in the doc. It does make sense to allign with the existing terminology in the spec.

I also think now I should update it in the spec PR (#327) as well, so that that is also in line with the existing terminology. WDYT?

And, if so, possibly rename the file too to Render-blocking_Status.md - or would that mix of dashes and underscores just be confusing?

This explainer in my repo was linked to various places, so if I change the name those links might become inaccessible. I'll rename it in a follow up PR after this lands?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for that. Updating the spec PR similarly seems sensible to me.



## Potential Spec Changes

Fetch ([whatwg/fetch#1449](https://github.com/whatwg/fetch/pull/1449))
- New boolean field render-blocking added to [fetch timing info](https://fetch.spec.whatwg.org/#fetch-timing-info)
- [Fetching](https://fetch.spec.whatwg.org/#fetching) is modified to set [fetch timing info](https://fetch.spec.whatwg.org/#fetch-timing-info)'s render-blocking field using request's [render-blocking](https://fetch.spec.whatwg.org/#request-render-blocking)

Resource Timing Level 2 ([w3c/resource-timing#327](https://github.com/w3c/resource-timing/pull/327))
- [4.3](https://w3c.github.io/resource-timing/#sec-performanceresourcetiming) : Adding new field to interface : renderBlockingStatus
- Getter steps for `renderBlockingStatus` return `"blocking"` if [timing-info](https://w3c.github.io/resource-timing/#dfn-timing-info)'s newly added render-blocking field is `true`, else `"non-blocking"`

## Changelog
- Update 1 - Spec changes modified to reuse `Request`'s `render-blocking` boolean.