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.

Sign up for GitHub

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

Jump to bottom

Document Render Blocking #245

Open
khushalsagar opened this issue Aug 28, 2023 · 12 comments
Open

Document Render Blocking #245

khushalsagar opened this issue Aug 28, 2023 · 12 comments
Assignees
@mattwoodrow
Labels
from: Google Proposed, edited, or co-edited by Google. topic: html Spec relates to HTML (Hypertext Markup Language) venue: WHATWG HTML Workstream venue: WICG Proposal is incubated in the Web Incubator Community Group

Comments

@khushalsagar
Copy link

WebKittens

@smfr

Title of the spec

HTML

URL to the spec

whatwg/html#9332

URL to the spec's repository

No response

Issue Tracker URL

No response

Explainer URL

https://github.com/WICG/view-transitions/blob/main/document-render-blocking.md

TAG Design Review URL

w3ctag/design-reviews#886

Mozilla standards-positions issue URL

mozilla/standards-positions#875

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.
@lukewarlow lukewarlow added topic: html Spec relates to HTML (Hypertext Markup Language) venue: WHATWG HTML Workstream venue: WICG Proposal is incubated in the Web Incubator Community Group labels Aug 28, 2023
@nt1m nt1m added the from: Google Proposed, edited, or co-edited by Google. label Oct 20, 2023
@vmpstr
Copy link

vmpstr commented Dec 15, 2023

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: whatwg/html#9970

@vmpstr
Copy link

vmpstr commented Feb 6, 2024

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

@nt1m
Copy link
Member

nt1m commented Aug 15, 2024

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
Copy link

smfr commented Aug 16, 2024

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
Copy link

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
Copy link

smfr commented Aug 16, 2024

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

@mattwoodrow
Copy link

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
Copy link

smfr commented Aug 16, 2024

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

@mattwoodrow
Copy link

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
Copy link

noamr commented Aug 16, 2024

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
Copy link
Author

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
Copy link

noamr commented Aug 20, 2024

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.

@hvanops hvanops mentioned this issue Oct 3, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mattwoodrow mattwoodrow

Labels
from: Google Proposed, edited, or co-edited by Google. topic: html Spec relates to HTML (Hypertext Markup Language) venue: WHATWG HTML Workstream venue: WICG Proposal is incubated in the Web Incubator Community Group
Projects
Standards Positions Review Backlog
Status: Position identified
Milestone
No milestone
Development

No branches or pull requests
7 participants
@smfr @noamr @mattwoodrow @nt1m @vmpstr @lukewarlow @khushalsagar