Document Render Blocking

khushalsagar commented 1 year ago

WebKittens

@smfr

Title of the spec

HTML

URL to the spec

https://github.com/whatwg/html/issues/9332

URL to the spec's repository

No response

Issue Tracker URL

No response

WebKit Bugzilla URL

No response

Radar URL

No response

Description

The Web is designed with a model for incremental rendering. When a Document is loading, the browser can render its intermediate states before fetching all the requisite sub-resources, executing all script or fetching/parsing the complete Document. While this is great to reduce the time for first paint, there is a tradeoff between showing a jarring flash of intermediate Document state (which could be unstyled or have more CLS) vs blocking rendering on high priority sub-resources within a reasonable timeout.

The render-blocking concept helps browsers in making this tradeoff. It lets authors specify the set of stylesheets and script elements which should block rendering. For example, a stylesheet with the rules necessary to ensure a stable layout. But authors can’t specify which nodes should be added to the DOM before first render. This proposal aims to fill this gap.

vmpstr commented 11 months ago

Hi, please note that we're proposing the following solution: https://github.com/WICG/view-transitions/blob/main/document-render-blocking.md#blocking-element-id

This is in a spec PR here: https://github.com/whatwg/html/pull/9970

vmpstr commented 9 months ago

FYI, Chromium is considering shipping this feature in the near future. Please let me know if there are any concerns with the proposal

nt1m commented 3 months ago

I'm planning to mark this as supportive in a week if there are no objections. The standard is reasonable, and @mattwoodrow is implementing it.

smfr commented 3 months ago

I would like the render blocking spec to describe the behavior of scrolling, playing media and animations while render-blocked. Does requestAnimationFrame proceed as normal? Is blocking detectable from script?

mattwoodrow commented 3 months ago

Render blocking only occurs during the page loading sequence, and starts blocking before the <body> element is created. I don't think there can be any scrolling or playing media.

The spec describing the rendering update loop says to skip Documents entirely (rAF, but also all the other update rendering steps) if the Document is render-blocked.

smfr commented 3 months ago

Isn't this the same render blocking that View Transitions uses though?

mattwoodrow commented 3 months ago

That's rendering suppression, which is somewhat different. Rendering suppression also is defined to skip the update rendering steps, but I agree that the other parts could be defined better.

smfr commented 3 months ago

Do we need both? Are they defined in a layered way?

mattwoodrow commented 3 months ago

They are not, maybe they could be somewhat?

They solve fairly different problems at least.

Render-blocking is there to give the author some control over preventing FOUC. Rather than the UA trying to strike a balance between showing a blank page for too long and FOUC, it lets the author tag which resources are critical to wait on before first-paint.

Rendering suppression is a temporary halt on rendering for same-doc view-transitions, since we capture the old snapshot and then have an async window for the author to make their DOM mutations. We can't let any of those mutations reach the screen, since they'd then be reverted again when the animation starts.

noamr commented 3 months ago

Render-blocking and rendering suppression are different mechanisms.

Render-blocking delays the first rendering opportunity of the page while it's loading
View-transition rendering suppression prevents rendering while the old state of the view transition is captured.

They are both handled here: https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model%3Arendering-suppression-for-view-transitions

I'm personally satisfied with how this is spec'ed but happy for suggestions for improvement.

khushalsagar commented 3 months ago

This spec text is also relevant for rendering suppression: While a Document’s rendering suppression for view transitions is true, all pointer hit testing must target its document element, ignoring all other elements.. It avoids an incorrect hit-test while the visually rendered state shown to the user mismatches the box tree.

I would like the render blocking spec to describe the behavior of scrolling, playing media and animations while render-blocked.

+1 to clarifying these better. Render blocking is pretty old concept, all browsers have had it for stylesheets in the head from a long time. Blink discards input when a Document is render-blocked but I don't think it's spec'd.

That said, I think it's a separate issue from this RFP which is about extending render-blocking to include parsing.

noamr commented 3 months ago

I would like the render blocking spec to describe the behavior of scrolling, playing media and animations while render-blocked.

+1 to clarifying these better. Render blocking is pretty old concept, all browsers have had it for stylesheets in the head from a long time. Blink discards input when a Document is render-blocked but I don't think it's spec'd.

It's all described in the spec rigorously.

There are no render opportunities so there are no animation updates, and no requestAnimationFrame callbacks.
Video elements are not rendered, however autoplay behavior is not guarded by rendering. User-agents may autoplay audio.
It's detectable from script in the sense that you'd only get the first requestAnimationFrame callback once the document is not render-blocked, and you can check for render-blocking elements yourself and whether they're loaded, but there is no particular "is render blocked" call.
Scrolling is a bit redundant because the document wouldn't have a height overflow yet.

All the above is derived from the HTML standard. Happy to clarify any additional details but there are no currently issues in the render-blocking part of the HTML spec that are known to be open, it's been worked on a lot.

WebKit / standards-positions