#886: Document Render-Blocking

Visit on Github.

Opened Aug 28, 2023

こんにちは 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.

Further details:

  • 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.

Discussions

Comment by @atanassov Aug 30, 2023 (See Github)

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.

Comment by @khushalsagar Aug 30, 2023 (See Github)

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

Comment by @khushalsagar Aug 31, 2023 (See Github)

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.

Discussed Oct 1, 2023 (See Github)

Rossen: first time around the work explained was very similar to efforts worked on by dbaron and emilio that describe what are blocking vs pipeline flushing states in the css subsystem, and ... push to plenary, discuss with Tess. Sounds like there was some tpac session on it. Missing context.

Discussed Oct 1, 2023 (See Github)

Lea: from preliminary state of html results, we had a question on that feature that had a high interest rating: 32% of people who hadn't used it said they were interested

Peter: some authors do delay injecting to try to block rendering. In general afraid of efforst that allow authors to add extra blocking, can mess things up

Lea: are these use cases better served by something less dramatic? eg. on async inserted stylesheets.. but that's not the use case. What's the usecase for an async inserted stylesheet? Is it view transitions?

Peter: looks like it

Lea: understand the idea about exposing web platform primitives, but is this really something we want to expose? Can't the browsers just do this? In general expose all the primitives to authors, but this could be harmful if used improperly. Would it make sense to block rendering on a subtree instead of the whole document? Blocking until a resource loads doesn't justify blocking rendering of the whole document

Peter: their use cases talk about situations where you'd only want to block part of the document

Lea: without view transitions are the rest of the use cases common enough to warrant the additional complexity? Shouldn't it stay browser magic for a while until we figure out the best solution?

Peter: tend to agree, but we've had this for a while. There's a long discussion in their repo. Also a note about how it can be done with computed style. A list of view transition names. Seems to be violating the priority of constituencies. Preference is to keep it automatic

Lea: I agree

Peter: hesitant to jump in without Rossen and Tess

Comment by @vmpstr Dec 15, 2023 (See Github)

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

Comment by @martinthomson Feb 19, 2024 (See Github)

@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">.

Comment by @plinss Feb 19, 2024 (See Github)

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.

Comment by @noamr Feb 19, 2024 (See Github)

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.

Comment by @noamr Feb 19, 2024 (See Github)

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

Comment by @vmpstr Feb 20, 2024 (See Github)

@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

Comment by @khushalsagar Feb 20, 2024 (See Github)

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

Discussed Mar 1, 2024 (See Github)

[Peter & Tess read some linked issues and spec changes for a while]

Discussed Apr 1, 2024 (See Github)

Peter and Tess discussed this feature in the context of view transitions, prefers-reduced-motion, and the priority of constituencies. For plenary: possible TAG finding fodder.

Note for issue comment: Is there a valid use case for this feature besides View Transitions? View Transitions are not primary content (aside: they should be disabled by UAs when prefers-reduced-motion is enabled), and it's a disservice to users to block incremental rendering (a core feature of the web platform) in service of nice-to-have visual effect. Should also note browser competitiveness concern (blocking rendering appears to users as their browser being slow, which will be blamed on the browser, not the site, thus disincentivizing implementation.)

Actions:

  1. Peter: file issue on view transitions re: prefers-reduced-motion, if it isn't already filed. if it already exists, chime in on it.
  2. Tess: draft comment based on the above notes.
  3. Peter and Tess: talk about possible finding in plenary session.