Intent to Experiment: Full frame rate render blocking attribute

[Jiacheng Guo]

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

TAG review

None

TAG review status

Pending

We plan to run a quick test so as to verify the loading performance impact on certain sites. Field experiments on the beta channel do not show significant loading performance improvement so the feature may not be shipped at all. Thus, we'll delay requesting TAG review and other browser signals until we are more confident in the feature's value.

Risks

Interoperability and Compatibility

None

The API is introducing an informative signal to lower the frame rate during loading. The browsers not implementing the feature will simply ignore the element. The behavior will not change on these browsers. We consider the risk to be minimal.

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

Goals for experimentation

We would like to verify the impact of the frame rate blocking API on the loading performance. The loading performance changed will be measured by the UMA WebVitals.FirstContentfulPaint4 and WebVitals.LargestContentfulPaint3. The developers can also measure the impact by collecting latency data in the page loading process.

Ongoing technical constraints

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

Yes

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

No

Acquiring the frame rate during page loading in javascript turned out to be very difficult and the result is unpredictable on different platforms. Thus it is hard to add a test to verify that the frame rate is really lowered during loading in web tests.

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

Origin trial desktop first	139
Origin trial desktop last	144
Origin trial Android first	139
Origin trial Android last	144
Origin trial WebView first	139
Origin trial WebView last	144

Link to entry on the Chrome Platform Status

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

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67c7dfbb.2b0a0220.1efd8e.0902.GAE%40google.com

[Mike Taylor]

LGTM to experiment from M139 to M144 (inclusive).

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1NxZLiK3FW6ny%2BYuyF%3D%3DJW7WFEeXsLoiOuzeoUXnk171Rg%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

Non-blocking for the experiment, but I think it'd be good to:
* Expand on the use case you're trying to resolve. Do you want to reduce the amount of paints that are happening during the page load? Reduce the amount of scripts running as part of `requestAnimationFrame`? Something else?

It might also be worthwhile to talk with +Kouhei Ueno and folks, as I know they are experimenting with an explicit signal to stop the HTML parser at some point during the page load, to see if it provides benefits. That may or may not be related to your goals here. 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d123c2b6-bacb-4b21-bb45-425e7157ef38%40chromium.org.