v139 · graphics
Full frame rate render blocking attribute
Chrome 139 experiments with a new blocking="full-frame-rate" token for <link rel="expect" href="#critical-content">. Instead of fully stalling rendering like blocking="render", the browser may lower frame rate during loading to reserve more CPU for parsing and resource work, then restore full frame rate when the expected content parses, after a timeout, or after user interaction.
concepts
-
render-blocking Flag
The blocking attribute gains a full-frame-rate token. Tells the browser the resource needs to be ready before the first full-rate frame, not just first paint — useful for animations and heavy interaction.
-
FPS Visualizer
Simulates the user-visible effect: an animating ball renders at full rate normally, throttles down while a fake "load" runs with the hint on, then snaps back to full rate. Live fps counter included.
-
Blocking Attribute Matrix
Compare
render,full-frame-rate, and the wrong legacy spelling against the liveelement.blockingDOMTokenList. Build arel="expect"snippet and model target-missing, timeout, and user-interaction restore branches. -
Loading Timeline Planner
Add resources with type, size, and blocking attribute — see a proportional timeline with "first paint" and "first full-rate frame" markers. An "Optimize" button analyzes the list and flags misuse: fonts missing
full-frame-rate, images that don't need it, render-blocking JS. Generates the final<link>tags live.
why it shipped
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.