Review request on Render Blocking Status in Resource Timing

[abinpaul1]

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: Add Render Blocking Status to PerformanceResourceTiming w3c/resource-timing#327
• Tests: WIP : Add render blocking status to Performance Resource Timing web-platform-tests/wpt#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 : Render blocking status in Resource Timing mozilla/standards-positions#662 (comment)
• 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.

• https://blog.webpagetest.org/posts/new-render-blocking-indicator-in-chrome-and-webpagetest/
• https://twitter.com/tkadlec/status/1417543014705246214

We'd prefer the TAG provide feedback as :

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

[atanassov]

@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?

[abinpaul1]

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.

[ylafon]

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

[abinpaul1]

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.

[torgo]

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