Intent to Prototype: Full frame rate render blocking attribute

[Chromestatus]

Contact emails

g...@google.com

Explainer

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

Specification

None

Summary

We propose to add a new render blocking token full-frame-rate to the blocking attributes. When the renderer is blocked with the full-frame-rate token, the renderer will work at a lower frame rate so as to reserve more resources for loading. An example use case of the proposed API will be: The web page contains an element <link rel="expect" href="#critical-content" blocking="full-frame-rate"/> in the page head. After parsing this element, the renderer will work at an implementation-specific lower frame rate. After the #critical-content element is parsed, the renderer will restore its frame rate. It is worth noting that the frame rate instructions will be informative. The browser may decide to lower the frame rate before parsing a blocking element. For instance, the frame rate may be lowered at the very beginning of the loading phase. On the other hand, the browser may also decide to restore the frame rate before the frame rate blocking element list gets empty. For instance, the frame rate may be restored after a timeout or certain user interactions.

Blink component

Blink>Compositing

Motivation

The render blocking mechanism may be adopted to throttle the rendering. By adding a <link rel="expect" blocking="render"> element, the webpage can stop rendering until certain critical elements are fully parsed. However this will cause the page to be fully stalled and delay the user interaction. Thus we plan to add new experimental APIs to instruct the renderer to work at a lower priority. The API will be used to proactively lower the frame rate during loading stage so as to improve the loading performance.

Initial public proposal

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

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 about://flags

None

Finch feature name

RenderBlockingFullFrameRate

Requires code in //chrome?

False

Tracking bug

https://crbug.com/397832388

Launch bug

https://launch.corp.google.com/launch/4385256

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5207202081800192?gate=5191537799200768

This intent message was generated by Chrome Platform Status.

[Jake Archibald]

On Wednesday, 5 March 2025 at 05:23:20 UTC Chromestatus wrote:

Contact emails g...@google.com

Explainer https://github.com/whatwg/html/issues/11070

Specification None

Summary

We propose to add a new render blocking token full-frame-rate to the blocking attributes. When the renderer is blocked with the full-frame-rate token, the renderer will work at a lower frame rate so as to reserve more resources for loading. An example use case of the proposed API will be: The web page contains an element <link rel="expect" href="#critical-content" blocking="full-frame-rate"/> in the page head. After parsing this element, the renderer will work at an implementation-specific lower frame rate. After the #critical-content element is parsed, the renderer will restore its frame rate.

Maybe this is already the intent, but this should work in the same way as <link rel="expect" href="#critical-content" blocking="render"/>. As in, detecting #critical-content shouldn't be limited to the HTML parser (but yes, the element must not be in the parser's stack of open elements).

The allows cases where #critical-content is added via JS.

[Jiacheng Guo]

Yes, the design and the implementation allows the critical content elements to be added via JS as well. I'll update the chromestatus and the explainer to include this use case as well.

[Jiacheng Guo]

Sorry I may have some misunderstanding on the current implementation of render-blocking elements when it comes to scripts. I'll discuss further with the team and be back with the conclusion.

[Jiacheng Guo]

I have checked with @Vladimir Levin. Currently chrome is not supporting inserting any kind of render-blocking elements from javascript. Since it is a very practical use case we may work on adding the support.

[Jake Archibald]

Fwiw the spec is already written to allow this.

[Noam Rosenthal]

On Wed, Mar 12, 2025 at 2:35 AM 'Jiacheng Guo' via blink-dev <blin...@chromium.org> wrote:

I have checked with @Vladimir Levin. Currently chrome is not supporting inserting any kind of render-blocking elements from javascript. Since it is a very practical use case we may work on adding the support.

I don't think this is accurate. It's possible to insert render-blocking elements using javascript if the script is run before the parser sees the body element.

Specifically for <link rel=stylesheet> it's the only utility of blocking=render as parser-inserted stylesheets are render-blocking to begin with.

[Jiacheng Guo]

Yes, inserting render-blocking elements in the headers is supported.

I'm not very accurate in the previous message. The current situation is that Chrome cannot fulfill a render-blocking element to unblock the renderer if it is inserted from the script.

For instance, this page will not work:

    <!doctype html>
    <head>
      <link rel="expect" href="#target-id" blocking="render"/>
    </head>
    <body>
      <script>

        var div_element = document.creteElement('div'); 

        div_element.id = 'target-id';

        div_element.textContent = 'test';

        document.body.appendChild(div_element);

      </script>

    </body>

[Jake Archibald]

I guess the result of the above is that rendering is blocked longer than expected, since it renders when the document readiness is no longer "loading"?

Yeah, it'd be nice to follow the spec here and allow #target-id to be decided even if it isn't inserted by the parser.

This is important for "render", but even more important for this "full-frame-rate" proposal, since it's common for JS-heavy SPAs to be network-heavy until their main content loads.

[Noam Rosenthal]

On Wed, Mar 12, 2025 at 9:18 AM Jiacheng Guo <g...@google.com> wrote:

Yes, inserting render-blocking elements in the headers is supported.

I'm not very accurate in the previous message. The current situation is that Chrome cannot fulfill a render-blocking element to unblock the renderer if it is inserted from the script.

For instance, this page will not work:

    <!doctype html>
    <head>
      <link rel="expect" href="#target-id" blocking="render"/>
    </head>
    <body>
      <script>

        var div_element = document.creteElement('div'); 

        div_element.id = 'target-id';

        div_element.textContent = 'test';

        document.body.appendChild(div_element);

      </script>

    </body>

This would work according to spec and if it's not working in implementation it would be a bug.

I'm pretty sure it's working in the implementation as well having implemented some of this myself.