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.
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.
Explainers: https://github.com/whatwg/html/issues/11070