Intent to Prototype: Document Render-Blocking

[Khushal Sagar]

Contact emails

khusha...@google.com

Explainer

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

Specification

None

Summary

This feature enables authors to block rendering of a Document until the critical content has been parsed, ensuring a consistent first paint across all browsers. Without this feature, the first paint's state depends on the heuristics for parser yielding which can vary across browsers. This is particularly important for View Transitions where the parsed DOM state on the first frame can drastically change the transition created.

Blink component

Blink>ViewTransitions>MPA

Motivation

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.

Initial public proposal

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

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

None

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Is this feature fully tested by web-platform-tests?

No

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5113053598711808

This intent message was generated by Chrome Platform Status.

[Camille Lamy]

Hi Khushal,

I am reviewing this for security as part of the OWP S&P review process. I had a few questions regarding the API to make sure we're assessing it correctly.

1. Is the render blocking attribute something that only applies to one particular document, and does not block rendering of other documents (e.g. child iframes, parent iframes?)?
2. Can the render blocking attribute only be set by the document that will be render blocked?

Thanks!

Camille

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUzNfD4MRk0bR1yTZ5F6NzcpETrUU3Vy9GmANZRQd7%3DE4A%40mail.gmail.com.

[Khushal Sagar]

Thanks for the review Camille. Excellent questions!

On Wed, Aug 16, 2023 at 8:21 AM Camille Lamy <cl...@chromium.org> wrote:

Hi Khushal,

I am reviewing this for security as part of the OWP S&P review process. I had a few questions regarding the API to make sure we're assessing it correctly.

1. Is the render blocking attribute something that only applies to one particular document, and does not block rendering of other documents (e.g. child iframes, parent iframes?)?

The spec is a bit ambiguous about it because it doesn't explain how rendering opportunities (rAFs) between Documents are intertwined. Implementation wise, we definitely don't allow a child iframe (which is render-blocked) to block rendering of the parent Document.

A local child Document is also render-blocked if the parent is. The case with OOPIFs is tricky. If the parent hasn't drawn a frame yet, the child will be assumed to be invisible. We don't render embedded frames unless they are visible. The flow is similar to an iframe starting offscreen and eventually coming onscreen. I'm a bit uncertain whether the child will see 1 rAF (and then get throttled) or no rAFs at all.

Also note that render-blocking concept shipped in Chrome via this intent. This intent is not changing the behaviour in how this feature affects embedded frames. It's adding parsing to the category of resources which can block rendering.

1. Can the render blocking attribute only be set by the document that will be render blocked?

It's the same as accessing any other attribute on the Document object. If script has access to the Document object, it can set/read this attribute. For example, for a same-origin iframe the embedding Document can access the iframe's Document object so it can set this.