Document Render-Blocking

khushalsagar commented 10 months ago

こんにちは TAG-さん!

I'm requesting a TAG review of Document Render-Blocking.

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.

Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/view-transitions/blob/main/document-render-blocking.md
User research: N/A
Security and Privacy self-review²: https://github.com/WICG/view-transitions/blob/main/security-privacy-questionnaire-document-render-blocking.md
GitHub repo (if you prefer feedback filed there): https://github.com/whatwg/html/issues/9332
Primary contacts (and their relationship to the specification):
- Khushal Sagar (@khushalsagar), Google
- Noam Rosenthal (@noamr), Google
- Vladimir Levin (@vmpstr), Google
Organization/project driving the design: Google
External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5113053598711808

Further details:

[X] I have reviewed the TAG's Web Platform Design Principles
The group where the incubation/design work on this is being done (or is intended to be done in the future): HTML
The group where standardization of this work is intended to be done ("unknown" if not known): HTML
Existing major pieces of multi-stakeholder review or discussion of this design: N/A
Major unresolved issues with or opposition to this design: N/A
This work is being funded by: N/A

You should also know that...

This feature is needed for cross-browser compliant implementation of cross-document View Transitions, reviewed at https://github.com/w3ctag/design-reviews/issues/851.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @khushalsagar @noamr.

atanassov commented 10 months ago

We'll review the proposal soon. In the meantime I want to draw your attention to https://github.com/w3ctag/design-reviews/issues/489 and https://github.com/w3c/csswg-drafts/issues/5115 which look like related efforts.

khushalsagar commented 10 months ago

@atanassov thanks for the pointers. I went through those issues and they don't seem related at first glance. This proposal is about when the first rendering opportunity of a Document happens, which is independent of any steps that happen as a part of the rendering opportunity (flushing style/layout).

Let me know if I missed something, might be easier to discuss once you've had a chance to review the proposal.

khushalsagar commented 10 months ago

Just a heads up, please do see the discussion at https://github.com/whatwg/html/issues/9332 when reviewing this proposal. A lot of good insightful points have been brought up on the issue.

vmpstr commented 6 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

martinthomson commented 4 months ago

@vmpstr am I to infer that you no longer intend to include the <html blocking="" attribute? I can't see how an HTML document without any body content could end up being unblocked anyway, so that seemed like it was redundant.

I'm also a little surprised at the use of <link relations for this. It seems like it would be cleaner to add a new element type for this. For one, you could have this be slightly more efficient... <block on="section1 section3">.

plinss commented 4 months ago

Personally I have concerns about adding mechanisms that allow the author to block rendering. Authors will tend to test on faster devices and connections than most users have and are prone to unintentionally making the user's experience worse. (Let's all remember the blank pages people were staring at while fonts downloaded.)

Browsers already make a lot of tradeoffs trying to give the user the best experience, and authors can't predict the user's network conditions or device capabilities. I accept that the browser can't read the author's mind to know which content is more important to the user, so a mechanism that allows the author to set relative priorities rather than forced blocking seems like it would satisfy most of the needs here without the harms.

noamr commented 4 months ago

Personally I have concerns about adding mechanisms that allow the author to block rendering.

Those exists already, and most of them are far more powerful than render-blocking on an element.

Authors will tend to test on faster devices and connections than most users have and are prone to unintentionally making the user's experience worse. (Let's all remember the blank pages people were staring at while fonts downloaded.)

Browsers already make a lot of tradeoffs trying to give the user the best experience, and authors can't predict the user's network conditions or device capabilities. I accept that the browser can't read the author's mind to know which content is more important to the user, so a mechanism that allows the author to set relative priorities rather than forced blocking seems like it would satisfy most of the needs here without the harms.

This wouldn't work for view-transitions, and a lot of this was discussed at length here.

noamr commented 4 months ago

@vmpstr am I to infer that you no longer intend to include the <html blocking="" attribute? I can't see how an HTML document without any body content could end up being unblocked anyway, so that seemed like it was redundant.

I'm also a little surprised at the use of <link relations for this. It seems like it would be cleaner to add a new element type for this. For one, you could have this be slightly more efficient... <block on="section1 section3">.

Please let's discuss this at https://github.com/whatwg/html/issues/9332 and not in the TAG repo. The link element was something that approached consensus after about 9 months of discussions.

vmpstr commented 4 months ago

@vmpstr am I to infer that you no longer intend to include the <html blocking="" attribute? I can't see how an HTML document without any body content could end up being unblocked anyway, so that seemed like it was redundant.

Yes, that's correct. We are only planning to support a single way to enable this, namely the section to which I linked above.

As for link vs another tag name, @noamr is right that we seem to have pretty good consensus with a bunch of that discussion happening on the issue. That being said, I don't feel too strongly about a possibility of a different name here, so it may be a worthwhile point to raise. Is there a specific objection to link?

FWIW, I also agree with @noamr that I prefer we take the conversation to the linked issue to make sure the discussion is visible to other participants there

khushalsagar commented 4 months ago

@plinss more context on the ViewTransition use-case can also be found here.

w3ctag / design-reviews

Document Render-Blocking #886