https://github.com/whatwg/html/issues/7131
https://github.com/mozilla/standards-positions/issues/608

We need to be careful to not cause some new security/privacy issues by letting the page to block rendering forever. The current PR does let UA to unblock rendering after a timeout.

The might be other kinks in the proposal too.

Also for inline scripts: https://github.com/whatwg/html/pull/10035

Usage is still low, but seems to be increasing: https://chromestatus.com/metrics/feature/timeline/popularity/4183 currently 0.03% of page loads.

Usage is still low, but seems to be increasing: https://chromestatus.com/metrics/feature/timeline/popularity/4183 currently 0.03% of page loads.

I assume the usage is low because it's not cross-browser supported.

Currently, the usage is at ~0.1%. What is the threshold to start developing the feature?

Usage has risen dramatically in recent months:
https://chromestatus.com/metrics/feature/timeline/popularity/4183

It would be great to see this feature prioritized. A clear signal of intent to implement it eventually would be helpful. This is an especially helpful mechanism for prevention of the Flash of Un-styled Content

(In reply to :klebba from comment #4)

Usage has risen dramatically in recent months:
https://chromestatus.com/metrics/feature/timeline/popularity/4183

It would be great to see this feature prioritized. A clear signal of intent to implement it eventually would be helpful. This is an especially helpful mechanism for prevention of the Flash of Un-styled Content

It was still below 1% back then in Februrary.

Chrome Platform Status shows the page loads over time now jumping up to over 10%.

(I'm not sure which of these we should be using:)
https://chromestatus.com/metrics/webfeature/timeline/popularity/12
https://chromestatus.com/metrics/feature/timeline/popularity/4183

So one in ten page loads could benefit from support of this feature today. What other signals are needed to set a priority and signal something to developers? Thanks for considering

https://chromestatus.com/metrics/feature/timeline/popularity/4183 has now jumped to ~11% of page loads, so some big site(s) have probably started to use this. The httparchive usage is at 0.18% of pages.

Probably ads... I looked at the top 4 sites listed on the chrome-stats page and they all looked like marketing landing pages for various never-heard-of-it products.

:dveditz are you referring to the list titled "Sample URLs of the most popular sites using this feature ordered alphabetically"? If so, I recommend taking a closer look because the list is ALPHA sorted, not RANKED.

:zcorpan is correct that the usage has surged from <1% in June 2025 to >11% in October 2025.

If we study all of the 100 "sample URLs" provided, we can see among them:

images.google.com
google.com
google.com.hk
univision.com
walmart.com

It would be really great to see the dev team set a priority for this feature. The only data we have to study continues to provide super compelling evidence that developers want to adopt it. Thank you!

Just wanted to pile on that I would find this very useful as a way to reason about what resources will have been loaded into my application by the time I begin rendering. It is similar to why getting Implement CSS module scripts was so important (thanks!).

As a developer, there are typically a small-but-critical set of resources that I want to be for sure loaded by the time I start trying to render things. Right now, I have to manage those race conditions. It would be amazing to simply indicate this in my markup and offload that complexity.

[Assessing as Medium, though we're assuming of the work here is DOM work, but emilio's also familiar with the relevant code]

This would be a very useful feature to replicate the render-blocking behaviour of classic scripts. One use case is to avoid pop-in effects of web components by loading them in a render-blocking script. Modern bundlers like vite can generally only emit type=module scripts which can only become render-blocking with blocking=render.

I wonder what happens to user input during render blocking.

For render blocking during the VT callback, there is https://drafts.csswg.org/css-view-transitions-1/#document-rendering-suppression-for-view-transitions

While a Document’s rendering suppression for view transitions is true, all pointer hit testing must target its document element, ignoring all other elements.

The changes in bug 2030348 could perhaps be used here too. But if so, the follow-up bug 2032028 becomes more important.

Adds the blocking=render content attribute plumbing (link/script/style),
render-blocking bookkeeping on Document, and the refresh-driver hook that
holds the last rendered frame while a document is render-blocked.

Tests are enabled in the last patch of the stack