Design Review #753

#753: Review request on Render Blocking Status in Resource Timing

Opened Jul 2, 2022

Wotcher TAG!

I'm requesting a TAG review of Render Blocking Status in Resource Timing.

Adds a field to PerfomanceResourceTiming to indicate the render blocking status of a resource. Currently from a developer perspective, the only way to determine which resources were actually render blocking is to rely on complex heurestics. The new field would instead provide a direct signal regarding the same.

Explainer: https://github.com/abinpaul1/resource-timing/blob/render-blocking-status-explainer/Explainer/Render_Blocking_Status.md
Specification URL: https://github.com/w3c/resource-timing/pull/327
Tests: WIP : https://github.com/web-platform-tests/wpt/pull/34628
User research: None
Security and Privacy self-review: https://gist.github.com/abinpaul1/dbe7e378aaf31cf2bf5308289f8e5712
Primary contacts (and their relationship to the specification):
- Abin K Paul (@abinpaul1), spec author
- Yoav Weiss (@yoavweiss), Google, spec mentor
Organization(s)/project(s) driving the specification: Google
Key pieces of existing multi-stakeholder review or discussion of this specification:
- Discussion in WebPerf WG call : https://docs.google.com/document/d/1VKlWpadbyq2iv35JVVUdxFuB2mshEHP_ArPcij8fpk8/edit#heading=h.9gqz90lre5ux
- Positive reception from Mozilla : https://github.com/mozilla/standards-positions/issues/662#issuecomment-1171568555
External status/issue trackers for this specification: https://chromestatus.com/feature/5166965277589504

Further details:

I have reviewed the TAG's Web Platform Design Principles
Relevant time constraints or deadlines: September 1, 2022
The group where the work on this specification is currently being done: W3C Web Performance WG
Major unresolved issues with or opposition to this specification: None
This work is being funded by: Google

You should also know that...

Reception towards a similar feature introduced in Chromium was very positive. The article and tweet linked below is a good indicator.

We'd prefer the TAG provide feedback as :

💬 leave review feedback as a comment in this issue and @-notify @abinpaul1 @yoavweiss

Discussions

Comment by @atanassov Jul 27, 2022 (See Github)

@ylafon & I reviewed the proposal during our London F2F today. The developer use cases and proposed addition to fetch and Resource Timing all make sense. One question that came up was about the attribute type. Why did you define it as string and not boolean?

Comment by @abinpaul1 Jul 27, 2022 (See Github)

The main reasoning was to keep it open to being extended later on, if we wanted to provide more supporting information regarding render blocking.

Say we have a scenario where a plain script element is present in the head and another plain script element is dynamically added to head. The former is blocking and the latter is non-blocking, so say we had a string value saying dynamically-injected-non-blocking, we could maybe convey more information regarding why it was non-blocking as well. The proposal started out with a couple more such values before deciding to rely on the boolean.

The final value that is exposed was defined as string to keep it open to such extensions or others if they were to be deemed useful later on.

Comment by @ylafon Jul 28, 2022 (See Github)

How about using an enum in that case? That would avoid using strings to be used to carry extra information using micro-syntax, where another value would be better

Discussed Aug 1, 2022 (See Github)

can close?

Dan: they opened a PR that makes the change Yves had suggested.

Peter: looks ready to close.

closed

Comment by @abinpaul1 Aug 1, 2022 (See Github)

Thanks for the suggestion. An enum does seem to be better suited. The explainer and spec have been updated to use an enum field instead of the string type.

Comment by @torgo Aug 25, 2022 (See Github)

Hi @abinpaul1 thanks for that! On that basis, we're happy to close. Thank you for flying TAG.