#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

2023-10-23

Minutes

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.

2023-10-30

Minutes

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

2024-03-18

Minutes

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

2024-04-29

Minutes

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.